Se trata de una vulnerabilidad bastante seria en SSL. Resumidamente, se trata de un clásico man-in-the-middle que podría explotar la renegociación de SSL para inyectar un prefijo arbitrario en cualquier sesión SSL, lo que pasaría inadvertido a ambos lados de la conexión. Se han demostrado ataques prácticos contra la autenticación por certificados en el cliente contra versiones recientes de los servidores Apache y Microsoft IIS en varias plataformas y clientes. También se han demostrado casos que no necesitan de certificados en el cliente.via /.
Comentarios
El blog de Marsh Ray, el descubridor del fallo de seguridad y que lleva meses trabajando en secreto con la industria y grupos de estandarización: http://extendedsubset.com/?p=8
Pues hombre, romper no lo han hecho, lo han engañado.
El ataque consiste en hacer un mitm durante la renegociación de la sesión ya establecida, en ese momento cambian el tipo de cifrado (cosa que según tengas el servidor configurado para que no acepte otro tipo de cifrado esto fallaría ya) y consiguen que el server tome como válida este cambio.
Esto no es romper la criptografía del SSL, es engañar al protocolo.
además ya hay un patch http://www.links.org/files/no-renegotiation-2.patch
#4 Se habla de una vulnerabilidad no de la rotura del mismo. Pero coincido contigo con que la manera que se utiliza es inyectando un código arbitrario en el proceso renegociado de sesión.
Eso sí, afecta a muchos servidores en la red
Veamos #4, SSL es un protocolo, si el protocolo no funciona está roto. Nadie ha dicho que rompieron AES o DES, dicen que rompieron SSL, es decir el protocolo. Lo que hace el patch es eliminar la funcionalidad defectuosa, no corregirla.
#14, en realidad mi comentario de #4 era una respuesta a #3.
Lo que quería decir es que la criptografía seguirá siendo muy robusta, que debido a una "alegalidad" en el protocolo se permite inyectar en condicciones especiales una clave nueva basado en un cifrado nuevo.
Es decir, no me preocupa demasiado, que las PKI seguirán siendo un sistema seguro, lo que no es seguro es el intercambio de esas claves en determinadas circunstancias.
BAh, a mí no me preocupa, los certificados SSL de las webs de la Administración Pública que utilizo están caducados
#7 instalate el certificado raiz de la FNMT. La inmensa mayoría de los certificados de las administraciones públicas son válidos después de eso. Hay unos tipos en el Ministerio de Presidencia que se ocupan de esas cosas en el proyecto@Firma.
Respecto a la vulnerabilidad, solo se da cuando se autentifica al cliente mediante certificado, lo que descarta a la mayoría de los bancos. ¿Cuantos de vosotros usais un certificado de cliente para logearos en servidores de Internet? Fuera de esas circunstancias, TLS sigue siendo seguro.
Y para los casos donde si se usa un certificado de cliente, como el eDNI o la firma electrónica (mayoritariamente Seguridad Social o Hacienda), no preocuparse, que parchearán openssl y los navegadores se actualizarán dentro de poco por las vias normales, resolviendo la vulnerabilidad.
Pero que nadie se crea que mañana se va a conectar a su banco, a amazon o a paypal y el vecino le va a sacar magicamente la pasta. Para la mayoría de los casos que cuentan, TLS/SSL funciona.
Ningún sistema es 100% seguro, ssl no lo es y es normal que con el tiempo acaben pasando estas cosas.
Ahora lo importante es evitar que alguien se pueda aprovechar de la vulnerabilidad
Rectifico, parece que, a pesar de que afecta a las implementaciones, y se puede solucionar, es eliminando cierta funcionalidad (renegociación), por lo que sí afectaría al protocolo, pero a una parte que no se suele utilizar.
Sea como fuere, aunque puede que a nivel de usuario no sea importante, es muy grave.
#9 Que a nivel de usuario no es importante???? Pocos protocolos/cifrados me parecen más importantes para el usuario que un fiable funcionamiento de SSL a traves del cual pasamos a diario nuestras tarjetas de crédito y nuestras transacciones bancarias. Con la cantidad de wifis que hay por ahi... con claves web rompibles en 5 minutos unido a esta técnica puede causar una catastrofe... Espero que reaccionen rápido...
desde hace tiempo que estoy deseando que revienten el ssl, no es nada personal... pero en breve dependeremos totalmente de él
o los certificados...
Pues espero que lo arreglen prontitud, por que el server de mi empresa tiene FTPES.
Por lo que veo, no afecta al protocolo, sino, a las implementaciones. En este caso, son vulnerable la mayoría, pero el protocolo sigue limpio.
Ostras!!!!!
Una vulnerabilidad tras otra... es que alguien es tan ingenuo como para creer que queda algo 100% seguro?
joer, pues si, leyendo el enlace a slashdot.org parece que la cosa tiene mala pinta.
A ver si lo arreglan prontito.
ay q ver q pasa