Hoy despedimos a SSL. El último clavo necesario para la tapa de su ataúd fue amartillado por tres investigadores a nómina de Google. No tuvo una existencia fácil. Ya desde su nacimiento demostró una debilidad que le auguraba un porvenir lleno de complicaciones.
La primera versión ni siquiera vio la luz, se quedó en la morgue de Netscape. Sus creadores, que al poco presentaron la versión 2.0 al público, vieron como el escrutinio de la comunidad dejó en evidencia al protocolo con una lista de errores de seguridad que desmoronaba la confianza en su criatura. En 1996 se publicaba la versión definitiva de SSL, la tercera. A la tercera va la vencida. Y vencida fue.
En realidad, SSL ha sobrevivido a nuestros días como un reducto del pasado. En 1999 se publicaba la versión 1.0 de TLS. No era un protocolo que se diferenciase técnicamente de SSL. Si leemos el RFC correspondiente, vemos que incluso se refleja en su justificación "Las diferencias entre TLS 1.0 y SSL 3.0 no son dramáticas, pero lo suficientemente razonables para que no interoperen entre ellos". El mensaje era que TLS no iba a ser un SSL 4.0.
SSL ha ido soportando los distintos golpes en forma de BEAST, CRIME, etc. Pero con este último golpe, POODLE (¿GOOGLE?), ya no hay remedio posible, contramedida o unguentum armarium sobre el que prolongar la vida de SSL. Se acabaron las excusas.
POODLE ("Padding Oracle On Downgraded Legacy Encryption") basa su ataque sobre el modo CBC (Cifrado por bloques) lo que hace que este modo sea vulnerable a un ataque variante de Padding Oracle. La alternativa a CBC es usar un cifrado por flujo, RC4, pero este último ya fue condenado al destierro. En marzo de 2013 se publicó un ataque que permitía recuperar componentes de un mensaje cifrado con RC4 si estos componentes se repetían con cierta frecuencia. Pensemos en una cookie de sesión dentro de un mensaje HTTP.
¿Entonces va a destruir Poodle a Internet?
No, al igual que Heartbleed, Shellshock u otros tampoco va suceder nada extraordinario. Simplemente se ha de deshabilitar, siempre que se pueda, SSL y si se usa TLS impedir que se efectúe una renegociación hacia SSL si ambas partes, cliente y servidor, soportan TLS.
A día de hoy, en realidad casi todas las conexiones a sitios "conocidos" o la gran mayoría de servidores y clientes se efectúan en TLS. Ahora depende de los actuales sistemas o software soportar una versión u otra de TLS. SSL, en porcentajes, no es un protocolo muy usado, pero está ahí, latente, soportado y preparado para actuar cuando ambas partes no se ponen de acuerdo con TLS. Y ese es el problema que los investigadores proponen como caso de uso de la vulnerabilidad.
En la práctica
Imaginemos una red local, una víctima, sus secretos más codiciados y un atacante. La víctima se conecta a su banco, el atacante efectúa un hombre en el medio, se mete en la conversación del cliente con el banco y decide "estorbar" lo suficiente como para que el navegador de la víctima y el servidor del banco se cansen de negociar que versión de TLS y con el lio terminen usando SSL.
Ahora que se está usando CBC como cifrado, debido entre otras cosas porque en una auditoría al banco le dijeron que se abstuviese de soportar RC4, el atacante solo tiene que capturar una buena cantidad de paquetes para que mediante un análisis comience a obtener "piezas" de esa conversación privada y haga trizas la privacidad.
¿Dejamos de soportar SSL ya?
Sin duda lo haremos. Pero va a ser una despedida agónica. No podemos cortar las amarras y dar la voz de avante a máquinas hoy mismo. Aun hay un número nada despreciable de servidores y clientes obsoletos que se arrastran por los oscuros callejones de Internet que no conocen otro protocolo que SSL.
Como medida, lo único que podemos hacer es evitar que TLS se manche las manos y permita verse degradado a un apestado SSL. Es decir, evitar el escenario que comentábamos anteriormente. Para ello disponemos de una opción que evita que innecesariamente, a clientes y servidores que soporten TLS, se use SSL en su lugar. De esta forma aunque un tercero esté interceptando las comunicaciones y metiendo ruido en el canal no se termine usando SSL.
La opción en cuestión se denomina TLS_FALLBACK_SCSV documentada aquí (
https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00). En principio
evitaría que en las negociaciones y renegociaciones de sesión segura se cambie de TLS a SSL. Eso para los servidores que tengamos funcionando, de los clientes ya se están encargando los fabricantes
(se puede verificar en esta web si el navegador es vulnerable). Por ejemplo Chrome implementa esta opción desde febrero de este año. Al menos algo es algo.
¿Y tú TLS, como andas de clavos?
Más información:
This POODLE Bites: Exploiting The SSL3.0 Fallback
This POODLE bites: exploiting the SSL 3.0 fallback
POODLE Test
Tomado de:
http://unaaldia.hispasec.com/2014/10/ssl-tocado-y-hundido.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+hispasec%2FzCAd+%28%40unaaldia%29
