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
David García
