Google viene ofreciendo desde hace un tiempo una serie de mejoras de seguridad en servicios como Gmail, al incorporar por defecto HTTPS y cifrado de las búsquedas. A esto hay que añadir una nueva funcionalidad anunciada esta semana: la activación por defecto del protocolo «Forward Secrecy».
Cuando se utiliza criptografía de clave pública (por ejemplo en TLS/SSL), se utilizan protocolos de acuerdo de claves de sesión. Estas claves se consensúan entre las dos partes que van a cifrar su conversación (cliente y servidor, por ejemplo) y se intercambian de forma secreta (en un medio «público» como Internet) usando las claves privadas de ambas partes. Básicamente, el cliente (navegador) genera una clave pública de sesión y se la envía al servidor firmada con su clave pública para que solo el servidor pueda descifrarla. Ahora que las dos partes conocen la clave de sesión que van a usar, comienza la comunicación segura.
Si un atacante robase este tráfico cifrado, necesitaría conocer la clave privada del servidor para descifrar la contraseña de sesión. Tendría dos opciones: o bien romper por fuerza bruta la clave privada (no sabemos lo sencillo que puede resultar dentro de unos años), o bien robarla. Con esto descifraría la clave de sesión de ese tráfico y podría observar los datos en claro de cualquier conexión pasada, puesto que todas han sido firmadas con la misma clave pública.La función de FS es impedir esto, evitando que se genere más de una clave a partir de un mismo material criptográfico. Para ello se basa en la generación de «claves efímeras» ECC y en la mejora de seguridad sobre los tickets de sesión.
-
Generalmente, para implementar TLS/SSL, se utiliza la combinación RSA-RC4-SHA en la mayoría de los navegadores. Ahora, en Google se usaría ECDHE-RSA-RC4-SHA. ECDHE es un protocolo de confirmación de clave efímera, basado en Diffie Hellman mediante criptografía de curva elíptica (ECC). Básicamente esto supone que el servidor genera una clave pública Diffie-Hellman para cada sesión y firma. A su vez el cliente también genera una clave pública y mediante Diffie-Hellman se crea una clave mutua final. El hecho de crear en cada sesión una clave pública diferente supone que si en algún momento se consiguiera romper alguna de ellas, el atacante sólo tendría acceso a la sesión asociada a esa clave, haciendo imposible recuperar la comunicación completa de años atrás, por ejemplo.
-
Cuando se establece una nueva sesión, el servidor cifra su estado y lo envía al cliente en forma de ticket. Posteriormente el cliente lo reenvía para continuar con la sesión previa. Debido a que ese ticket contiene información sobre la sesión (las claves de cifrado), con la nueva implementación de clave efímera se consigue que los tickets de sesión nunca permanezcan almacenados y siempre en un estado continuo de rotación.
A efectos prácticos, y como explica la propia Google, si se envía un email cifrado y algún atacante capturase el tráfico con la esperanza de poder romper el cifrado con la tecnología de dentro de 10 años, esto se lo impediría. Tener en sus manos la clave privada del servidor no le serviría.
Google ha confirmado que esta implementación está ya disponible para Chrome y Firefox en servicios como Gmail, SSL Search, Docs y Google+, excepto para Internet Explorer que todavía no soporta ECDHE. Google ha publicado el trabajo realizado sobre la librería OpenSSL necesario para implementar esta funcionalidad.
Más información:
Protecting data for the long term with forward secrecy
Forward secrecy for Google HTTPS
José Mesa Orihuela
Sergio de los Santos
Twitter: @ssantosv
Interesante. Me gustaría saber si Google tiene alguna motivación adicional además de la seguridad para esforzarse en esto. Como motivar el uso de su navegador.
Es curioso que un día como hoy publicaran una noticia muy relacionada:
http://www.hispasec.com/unaaldia/3318