09 marzo 2009

Con la llegada primero de Ceres-FNMT y posteriormente con el impulso del DNI-E, la administración Española ha ido lanzando una serie de servicios-online que permiten realizar todo tipo de trámites, desde presentar la declaración de la renta hasta consultar el informe de vida laboral de la seguridad social.

Obviamente todos estos trámites van protegidos por sesiones SSL lo que a priori puede parecer un entorno totalmente confiable.

Lo que no todo el mundo sabe es que SSL como tal, no es un protocolo único, mas bien es una enorme familia de protocolos, empezando por que existen 4 versiones (SSL v1, SSL v2, SSL v3 y TLS) además en cada versión se pueden negociar diferentes algoritmos con sus correspondientes longitudes.

Podriamos decir que el mundo SSL es como el mundo de las hipotecas, existen algoritmos AAA fiables y algoritmos subprime inseguros y poco aconsejables.

En concreto, el objeto de este estudio es la parte de los algoritmos simétricos que a la postre, son los que cifran los datos en tránsito.

Unanimemente la comunidad criptográfica considera los algoritmos de cifrado simétrico por debajo de 128 bits como inseguros. No olvidemos que, en la época que EEUU aplicaba fuertes restricciones criptográficas, el limite estaba en 40-bits.

Haciendo uso de la herramienta 'manyssl' (herramienta que permite interrogar que algoritmos acepta en una negociación ssl un servidor) he auditado unos cuantos de los servidores que aparecen listados en el portal del dni-e.

¿El resultado? La totalidad de ellos permiten un mínimo de 2 algoritmos inseguros, pero lo normal es ver disponibles bastantes mas:

Como se puede apreciar en el gráfico, la CMT, el INEM y la Agencia de Protección de Datos, son los menos vulnerables (2 algoritmos) y destaca NIC por sus desnhorrosos 15.

Que un servidor web permita negociar algoritmos SSL inseguros no significa que las transacciones con ellos sean inseguras, ya que lo normal es que tu navegador, cuando se conecte al servidor, negocie algoritmos óptimos.

El problema es que potencialmente esos servidores, que gestionan transacciones importantes, son susceptibles de que alguien se conecte a ellos de forma insegura. En muchos casos soportan incluso SSL v2 que tiene en su haber un horrible bug de tipo 'downgrade' que permite tomar el control de una sesión SSL.

¿Solución? Deshabilitar los algoritmos inseguros y en caso de que alguien intente conectar y no soporte las versiones seguras, advertírselo para que se actualice

El documento completo del estudio con los algoritmos, se puede descargar desde aquí y está en formato OpenOffice

5 comments :

Aebeda dijo...

Increíble lo de nic. Contraseñas en posits, dejar abiertos protocolos que no se debe... Al final todo es lo mismo.

Tenéis un lector más.
¡ Enhorabuena por el blog !

Yago Jesus dijo...

Muchas gracias compañero, y por cierto, que FRIO dan las fotos que tienes colgadas en tu blog!

AcIDsNaZz dijo...

Y tanto frio, increible lo de la administracion, cyo con el certificado ya he dado algunas vueltas (alguien se confundio al escribir mis apellidos, funcionaba en todos lados menos en la SS)

Jota dijo...
Este comentario ha sido eliminado por el autor.
Yago Jesus dijo...

@Jota, entiendo perfectamente lo que expones, pero en este caso no se trata de complejas configuraciones o inversión en nuevos elementos. Deshabilitar algoritmos SSL en un Apache / WebSphere o en general, cualquier servidor web, es cosa de muy muy poco tiempo