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" cono 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
http://www.imperialviolet.org/2011/11/22/forwardsecret.html
No hay comentarios.:
Publicar un comentario
Déjanos tu comentario, nos permitirá mejorar.
¿Qué opinas de este tema?
¿Tienes alguna duda o sugerencia?
¿Te parece adecuado y completo este tema?
¿Falta información? ¿Cual?