Buenas,
Me gustaría empezar un hilo explicativo sobre el protocolo SSL y a la vez dejar varios puntos en el aire para que podamos participar todos.
Esto lo pongo aquí. Si finalmente se abre temática de Criptografía, lo moveis allí, y sino pues a donde corresponda.
Empezaré haciendo un resumen sin entrar mucho en detalles del protocolo SSL (Secure Socket Layer) para la gente que quiera participar y no lo tenga del todo claro.
SSL.Secure Socket Layer es un sistema de protocolos de caracter general diseñado por Nestcape Communcations, con el propósito de conseguir un canal seguro de comunicación a través de Internet. Está basado en la aplicación conjunta de Criptografía Simétrica (por su rapidez, para el cifrado de datos), Criptografía Asimétrica (de llave pública, para el intercambio de la clave simétrica), certificados digitales y firmas digitales.
La identidad del servidor web seguro (y a veces también del usuario cliente) se consigue mediante el Certificado Digital correspondiente, comprobando su validez, y de la integridad de los datos intercambiados se encarga la Firma Digital mediante funciones hash y su comprobación.
Estableciendo la comunicación.Lo primero es que el cliente y el servidor realicen un proceso de reconocimiento mutuo y de petición de conexión, conocido como Handshake.
El protocolo comienza con el saludo del cliente al servidor,
Client Hello, por el que se informa al servidor de que se deséa establecer una comunicación segura con él.
Junto con este saludo inicial, el cliente envía al servidor información de la versión de SSL que tiene implementada, de los algoritmos de cifrado que soporta, las longitudes de clave máximas que admite para cada uno de ellos y las funciones hash que puede utilizar. También se le solicita al servidor el envío de su Certificado Digital X.509, con objeto de verificar el cliente la identidad del mismo y recoger su clave pública. En este momento se asigna un identificador a la sesión y se hace constar la hora y fecha de la misma.
A continuación, el servidor SSL responde al cliente,
Server Hello, enviándole su Certificado Digital (con su llave pública) e informándole de su versión de SSL, de los algoritmos y longitudes de clave que soporta. Generalmente se obtiene el conjunto de algoritmos, longitudes de clave y funciones hash soportados por ambos, eligiéndose entonces los más fuertes. Si no hay acuerdo con los algoritmos a usar se envía un mensaje de error.
Como medida adicional de seguridad, el cliente genera una clave aleatoria temporal y se la envía al servidor, que debe devolvérsela cifrada con su clave privada. El cliente la descifra con la llave pública y comprueba la coincidencia, con lo que está totalmente seguro de que el servidor es quién dice ser.
Si todo está correcto el cliente genera un número aleatorio que va a servir para calcular una clave de sesión correspondiente al algoritmo de cifrado simétrico negociado antes, conocida con el nombre de clave maestra, que es enviada al servidor de forma segura cifrándola asimétricamente con la llave pública de su Certificado Digital. Esta clave maestra se usará para generar todas las claves y números secretos utilizados en SSL. Con esto servidor y cliente se han identificado y tienen en su poder todos los componentes necesarios para empezar a transmitir información cifrada simétricamente.
Así y todo, para que empiecen las transmisiones de datos protegidos se requiere otra verificación previa, denominada
Finished, consistente en que cliente y servidor se envían uno al otro una copia de todas las transacciones llevadas a cabo hasta el momento, cifrándola con la llave simétrica común. Al recibir esta copia, cada host la descifra y la compara con el registro propio de las transacciones. Si las transacciones de los dos host coinciden significa que los datos enviados y recibidos durante todo el proceso no han sido modificados por un tercero. Se termina entonces la fase Handshake.
Luego vienen otras operaciones como determinar el modo de encapsulamiento de los datos en las que no me voy a meter, y ya por fín se establece la comunicación.
Ataque a SSL.Como vemos, toda la información que capturemos está cifrada. Si todo está en orden y usamos algoritmos de cifrado simétrico sin errores de implementación, lo único que nos queda es la fuerza bruta (no consideraremos inyecciones SQL, ni robos de cookies, etc, porque no sería un ataque contra SSL).
Aquí es dónde empezaremos la disertación e intentaremos concretar mitos y realidades.
Pero primero apunto dos consideraciones a tener en cuenta.
1.-
Cifrar al doble de 64 bits no es cifrar a 128, es cifrar a 65.
2^64 * 2^1 = 2^(64+1) = 2^65.
Por esta razón, si miramos en
www.distributed.net, comprenderemos porque para romper un RC5 de 56 bits tardaron 250 días y para la de 64 casi tres años. Con la de 72 lleván ya un par y lo que les queda.
1.- Tiempo de ruptura de cifrado a 128 bits.Vamos a poner todo a favor del atacante al cifrado haciéndo suposiciones inverosímiles, para simplificar cáculos.
* Supongamos que tenemos un Earth Simulator/5120 Nec con una potencia teórica (nunca a llegado a tanto) de 40960 billones de operaciones por segundo.
* Supongamos que en cada operación es capaz de áplicar un número al algoritmo de cifrado y ver si es el bueno (serían cientos de operaciones).
Cifrando solo a 128 bits, que es el cifrado máximo de SSL existen:
2^128 = 340.282.366.920.938.592.532.472.206.020.233.786.982 claves posibles.
340.282.366.920.938.592.532.472.206.020.233.786.982 / 40.960.000.000.000.000 = 8.307.674.973.655.724.205.649 Segundos.
8.307.674.973.655.724.205.649 /60 = 138.461.249.560.928.736.761 Minutos
138.461.249.560.928.736.761 / 60 = 2.307.687.492.682.145.612 Horas
2.307.687.492.682.145.612 / 24 = 96.153.645.528.422.734 Días
96.153.645.528.422.734 / 365 = 263.434.645.283.350 Años.
Ahora que ya sabemos un poco de la teoría, me gustaría abrir un debate sobre los cientos de noticias que podemos leer en cualquier sitio, del estilo, por ejemplo, esta:
http://www.galeon.com/maty/nautopia_old/nautopiaX.htm "Hablando de cifrado, recordemos la debilidad intrínseca del sistema implementado por MICROSOFT en sus productos (IE sin ir más lejos).
En su día aumentaron de 56 -cifrado débil- a 128 bits ¿cifrado fuerte?. Pues no, ya que realmente utiliza 80 y pocos bits. Y con los restantes, la NSA y otras agencias norteamericanas pueden romperlo fácilmente."
Pregunta:
Antes de leer este post, daríais como buena esta afirmación?
Y después de leerlo?
No digo que no sea cierto, vete a saber las diabluras que pueden hacer estos americanos, y el potencial tanto en recursos como en conocimiento que tienen, pero a mí así sin pensarlo mucho se me ocurre que:
Esos "y pocos" cuántos son? como hemos visto cada bit adicional de esos "y pocos" está duplicándo el tiempo de ruptura del cifrado.
Con 80 y pocos bits de cifrado, qué quieren decir cuando dicen "facilmente".?
La información que se supone que se guarda en los bits restantes hasta el 128, cual es? como acceden a ella estando solo en el cliente y en el servidor (el intercambio se realiza con el cifrado asimétrico)?
Si os he hecho dudar, algo hemos avanzado. De cualquier forma, espero que alguien exponga su opinión y posibles formas de hacer lo que en la noticia dicen.
Salu2.
Autor
).
En línea
