A estas alturas ya es imposible que no hayáis oído hablar de Heartbleed. Después del descubrimiento de uno de los fallos de seguridad más importantes en la historia de Internet, las empresas y startups han tomado las medidas necesarias para corregirlo y mitigar daños, incluyendo avisar a los usuarios para que cambien sus contraseñas.
Entre las medidas para mitigar los daños se encuentra la revocación y renovación de los certificados SSL. Recordemos que en HTTPS (y demás conexiones SSL/TLS) esos certificados sirven para cifrar las comunicaciones y asegurarte de la identidad del servidor. Si un atacante obtiene la clave privada podría escuchar y descifrar el tráfico que creemos seguro.
Tras la revelación, se generó una discusión sobre si se podían filtrar las claves SSL con este ataque. No había pruebas determinantes de que se pudiese. Cloudflare, una empresa de servicios para sitios web (CDNs, seguridad, estadísticas…) y una de las primeras en conocer el fallo – 12 días antes de su publicación -, argumentó que era extremadamente difícil que esas claves se filtrasen salvo que se hubiese reiniciado el servidor hace poco. En su blog tenéis los detalles técnicos de su teoría.
Sin embargo, se ha demostrado que, al contrario de lo que proponía Cloudflare, sí se pueden filtrar esas claves. De hecho, las pruebas de concepto no son especialmente complicadas ni costosas.
Si antes ya era urgente cambiar los certificados, ahora lo es más. Por desgracia, este proceso está lejos de ser perfecto.
El primer problema es la propia infraestructura. Los procedimientos no están pensados para revocaciones a gran escala de tantos certificados, y se especula que incluso podrían fallar y caerse en algún caso.
Además, los navegadores gestionan mal la revocación de certificados. En el momento en el que Facebook (por ejemplo) dice que su certificado SSL está revocado, se publica su número de serie en las listas CRL y en los servidores OCSP. La teoría es que los navegadores se conecten a estos sitios para comprobar qué certificados han dejado de ser válidos.
En la práctica, sólo Internet Explorer y Opera lo gestionan bien y muestran un aviso al usuario diciendo que el certificado se ha revocado. Chrome y Firefox ignoran en muchos casos esas listas si el sitio web no tiene certificados de validación extendida (EV).
En Chrome se pueden volver a activar las comprobaciones en Ajustes: hay que pulsar el enlace “Ajustes avanzados” y, en la sección HTTPS/SSL, pulsar en “Comprobar certificados revocados”. En Firefox, por desgracia, las listas CRL ya no están soportadas en las últimas versiones y no se pueden volver a activar (o no he encontrado la forma de hacerlo).
Otro problema es que no se están siguiendo los procedimientos todo lo bien que deberían seguirse. Según Netcraft, además de fallos en los nombres u otros detalles en los nuevos certificados, muchos administradores no están revocando sus certificados, sino simplemente renovándolos. Esto abre la puerta a que un atacante siga usando sin problemas un certificado ya comprometido.
En total, sólo unos 30.000 sitios web habrían renovado sus certificados de los 500.000 que estarían afectados según las estimaciones de Netcraft. Habrá que estar atentos a esas revocaciones y ser precavidos a la hora de conectarnos a redes en las que no confiemos del todo. Dicho de otra forma: tenemos Heartbleed para rato.
The post Heartbleed y certificados SSL: por qué hay que renovarlos y por qué no se está haciendo bien appeared first on i-RME.es.
from i-RME.es http://ift.tt/1evqX9m
Este articulo pertenece a sus respectivos autores y se distribuye bajo licencia Creative Commons Reconocimiento 3.0. Algunos articulos pertenecen a BlogdeBlogs quien es el responsable de definir la licencia aplicable.
No hay comentarios:
Publicar un comentario