La "carrera criptográfica" entre Google y Microsoft

Google y Microsoft están dando llamativos pasos adelante para mejorar la seguridad de la criptografía en general y de TLS/SSL en particular, elevando los estándares en los certificados y protocolos. En un mundo tan reactivo como el de la seguridad, sorprenden estos movimientos. Desde luego, no son gestos gratuitos (mejoran su imagen de cara a potenciales clientes, entre otras cosas). Pero en la práctica, ¿son útiles?

Google: qué ha hecho

Google anunció hace meses que iba a elevar la seguridad de sus certificados utilizando claves RSA de 2048 bits como mínimo. Ha terminado de hacerlo antes de lo previsto. Quieren eliminar de la industria los certificados de 1024 bits para el año 2014 y crear todos de 2048 a partir de ahora. Algo bastante optimista, teniendo en cuenta que son muy usados aún. A principios del año que viene, Chrome advertirá a los usuarios de los certificados que no cumplan sus requisitos al visitar una web. Elevar a 2048 los bits de las claves de los certificados implica que intentar romper el cifrado por fuerza bruta se vuelve poco práctico con la tecnología actual.

Además, relacionado con este esfuerzo hacia las comunicaciones cifradas, desde octubre de 2011 Google cifra el tráfico para usuarios presentados en sus dominios. Este septiembre de 2013, comenzó a hacerlo para todas las búsquedas. También ha intentado instaurar poco a poco el "certificate pinning" y el HSTS para intentar que no se interpongan certificados intermedios en la navegación. Por si fuera poco, sigue adelante con su proyecto de certificate transparency.

Parece que Google está muy preocupada por la seguridad de sus usuarios y en concreto (aunque a muchos les pueda resultar irónico) por su privacidad. De hecho, afirman que "eliminar las claves RSA de 1024 bits en los certificados, significa un esfuerzo de la industria que estamos contentos de apoyar, particularmente a la luz de las preocupaciones surgidas por la vigilancia gubernamental y otras formas de intrusión no deseada".

Microsoft: qué ha hecho

En la última actualización de Microsoft, se anunciaron medidas importantes para mejorar la criptografía general del sistema operativo. Para empezar no soportará el cifrado RC4, sobradamente superado (se creó en 1987) y culpable de muchos ataques. Ofrece herramientas para deshabilitarlo en todos sus sistemas y pretende erradicarlo en breve de toda aplicación. De hecho, en la versión 8.1 de su sistema operativo y con Internet Explorer 11, se cambia por defecto la versión de cifrado a TLS 1.2 (que puede usar AES-GCM en vez de RC4). Este protocolo también usa SHA2 normalmente.

Otro cambio en los certificados, es que no permitirá el algoritmo de hash SHA1 ni en certificados para firmar código ni en certificados SSL. SHA1 es un algoritmo que produce un hash de 160 bits, y se utiliza durante la generación de certificados con el protocolo RSA para "hashear" el propio certificado. El hash será lo que firme la autoridad certificadora, demostrando así su confianza. Hace ya tiempo que NIST desaconsejó el uso de SHA1, pero nadie le hizo mucho caso. Resulta un movimiento muy anticipativo para Microsoft, acostumbrados a una reactividad exasperante.

¿Por qué todo esto? ¿Es útil?

Microsoft y Google están decididos a mejorar la criptografía en general, y el TLS/SSL en particular. Con las medidas adoptadas entre los dos, se eleva sustancialmente la seguridad de esta forma fundamental de cifrar el tráfico en la red.

Certificado de 2048 bits, usando SHA2
(SHA256, concretamente).

Los certificados que acreditan claves públicas calculadas según RSA con valores de 512 bits, fueron rotos en la práctica en 2011. En 2010, se factorizó de forma distribuida y con un algoritmo de propósito general un número de 768 bits (212 dígitos), el más alto conocido. Así que en la práctica, el uso de un número representable en 1024 bits es "seguro", aunque se podría discutir si un futuro cercano supondrían un problema. Google se cura en salud.

Pero el foco del problema también es otro. El uso de certificados más robustos en SSL, no es el principal obstáculo para el usuario. De hecho, la introducción de nuevas advertencias (Chrome alertará sobre certificados de 1024 bits) solo puede confundirlo más: "¿Qué significa que usa 1024 bits? ¿Es seguro o no? ¿Esto en el sitio correcto? ¿Qué decisión tomo?". El exceso de alertas solo relaja la seguridad ("¿Qué alerta es la buena cuando se me alerta tanto de sitios seguros como de inseguros?"). El problema del SSL es que está socialmente roto, que no se entiende... y no tanto técnico desde el punto de vista del usuario. Al usuario le alegrará que su navegador utilice criptografía más robusta (porque supuestamente la NSA no podrá espiarle...), pero no servirá de nada si, confundido, acepta un certificado no válido durante la navegación, sin ser consciente de que está introduciendo un hombre en el medio.

Si adoptamos la teoría de que la NSA puede romper las comunicaciones porque dispone ya de la tecnología necesaria para aplicar la fuerza bruta contra certificados de 1024 bits, esto sí es útil. El problema sería que no fuese necesario romper ni aplicar fuerza bruta sobre nada, sino que las compañías ya colaborasen para entregarle a la NSA el tráfico descifrado... También podríamos descartar que la NSA cuente ya con sistemas propios para romper cifrado de claves de 2048 bits y por eso ahora se permita su estandarización... ¿o no? No hay que remontarse mucho en la historia (apenas 10 años) para oír historias "conspiranoicas" como estas en el mundo del SSL.

Certificado autofirmado creado en Windows 8 que usa
MD5 y 1024 bits.

En el caso de Microsoft también es curioso. Obviamente, este movimiento en los certificados está motivado por TheFlame. Utilizar MD5 con RSA les jugó una mala pasada, permitiendo que los atacantes firmaran código en su nombre. Y no puede volver a ocurrir. Esto pone a Microsoft al frente de la retirada del uso de SHA1 para certificados, puesto que la industria le seguirá. Pero en realidad, si bien RC4 sí está roto, SHA1 no tiene tan mala salud. Apenas nos hemos desecho de MD5 en ciertos certificados cuando ya Microsoft adelanta la muerte de SHA1. Esto nos deja solo con la posibilidad de usar SHA2 (sha256RSA o sha256withRSAEncryption normalmente en los certificados, aunque SHA2 permite el uso de salidas de 224 hasta 512 bits). Curiosamente, es el momento oportuno porque XP se retira, y ni siquiera soportaba nativamente SHA2 (lo hizo a partir del service pack 3). Todavía tiene trabajo que hacer, porque el SHA1 está muy arraigado (Windows 7 firma la mayoría de sus binarios con SHA1, Windows 8, con SHA2), por eso se ha puesto como fecha de retirada definitiva 2016 en certificados para firmar y 2017 en certificados para su uso en SSL. Queda por saber cómo reaccionarán las autoridades certificadoras.

Por otro lado, con respecto al uso de TLS 1.2 obligatorio (relacionado, porque es el protocolo que soporta SHA2), tenemos que conocer qué ataques se han publicado recientemente contra SSL para saber qué soluciona realmente. Muy sucintamente:

BEAST, en 2011. El error se fundamentaba en CBC y RC4. Efectivamente se soluciona con TLS 1.1 y 1.2. Pero debemos tener en cuenta que ambas partes (servidor y navegador) deben soportarlo.
CRIME: Es un ataque que permite recuperar cookies si se usa compresión en TLS. Deshabilitando la compresión TLS, es posible eludirlo.
BREACH: Permite también recuperar cookies. Pero se basa en la compresión HTTP, no TLS, por tanto no se puede "deshabilitar" desde el navegador. Se es vulnerable se use la versión TLS que se use.
Lucky 13: Solucionado en software principalmente. También en TLS 1.2.
TIME: Una evolución de CRIME. No requiere que un atacante haga de man-in-the-middle, sino que solo necesita JavaScript. Un problema más en los navegadores que en el TLS.

Certificado todavía muy común, que usa
SHA1withRSAEncryption y claves de 1024

De ninguno de estos ataques se tiene constancia de que estén siendo usados por atacantes. La imposición de 1.2 sin RC4 es un movimiento necesario, pero aún arriesgado. Internet Explorer (hasta el 10) soporta TLS 1.2 aunque deshablitado (solo Safari lo activa por defecto y los demás, lo implementan desde muy recientemente). La versión 11 lo hará por defecto.Queda por saber cómo reaccionarán los servidores, que también deben dar soporte a TLS 1.2.

En resumen, parece que estas medidas aportan seguridad técnica (al menos a largo plazo). Aunque lógicamente detrás se encuentren tanto intereses propios de la empresa (evitar problemas que ya han sufrido) como de imagen (liderar la "carrera de la criptografía"), cualquier mejora es bienvenida y esta "guerra" para liderar la criptografía, que fundamentalmente significa ser el más proactivo "frente a la competencia", elevará sustancialmente el listón.

Sergio de los Santos

ssantos@11paths.com