¿Es el protocolo seguro HTTPS realmente seguro? Lecciones que nos deja Snowden, la NSA y Lavabit

A estas alturas la gente anda ya un poco saturada de las filtraciones que nos va facilitando The Guardian sobre los papeles que Edward Snowden sacó de la NSA.

Aunque hay muchos y diversos temas sobre los que hablar a partir de estos papeles, me gustaría centrarme en este post en el tema del cifrado de las comunicaciones por Internet, principalmente en el protocolo de comunicación seguro para la web HTTPS, el que nos debería proteger cuando hacemos transacciones con nuestro banco, leemos el correo en Gmail, etc. cifrando desde nuestro usuario y contraseña, a los datos que enviamos o recibimos.

Desde el punto de vista del usuario medio, el HTTPS es eso que hace que aparezca un candado de color verde al lado de la dirección de la web en nuestro navegador.

ssl-gmail

ssl-santander

Algún usuario más avispado se habrá fijado que en algunas webs, además de aparecer el candado en verde indicando una presunta conexión segura, también pueden ver una pastilla con información de verificación del nombre de la empresa que ha solicitado el certificado de seguridad para esa web.

ssl-fastenal
ssl-deutschebank

 

Básicamente, esta pastilla con información sirve para verificar que estás realmente entrando a Deutsche Bank y no a una falsificación.

¿Es más segura la web de Fastenal (una cadena de cientos de ferreterías en EE.UU) que el Gmail de Google?

¿Es más segura la de Deutsch Bank que la del Santander que no dispone de esa información?

No necesariamente.

Más allá de la seguridad del servidor que almacena estos certificados, tema que daría para unos cuantos posts, vamos a centrarnos en la parte de la seguridad de las comunicaciones.

Confiar en que el candado verde significa que nuestras comunicaciones son seguras es un error que poca gente sabe que está cometiendo.

Ese candado tan solo nos informa de que el sitio web al que nos estamos conectando usa un protocolo de cifrado de datos y que el certificado que usa es correcto, ni ha caducado, ni está revocado y lo firma una autoridad certificadora de confianza.

Como se esté empleando luego el certificado seguro para cifrar el tráfico HTTPS es otra cosa bien diferente.

En la parte menos visible nos encontramos con que existen varios protocolos sobre los que se sustenta HTTPS: SSL versión 2, SSL versión 3, TLS versión 1.0, TLS versión 1.1, TLS versión 1.2

Dentro de estos protocolos tenemos diferentes métodos de cifrado, de establecer la comunicación segura entre el servidor y tu navegador, opciones para comprimir o no el tráfico HTTPS.

Aquí es donde verdaderamente reside la seguridad, en los protocolos y métodos de cifrado que se le han configurado al servidor para poder abarcar todos o la mayoría de los navegadores web del mercado ofreciendo la máxima seguridad posible.

Una de las enseñanza de Snowden es que la NSA y otros organismos afines almacenan durante un tiempo indeterminado la información cifrada con vistas a poder descifrarla en el futuro.

Esto puede suceder de varias formas, que el sistema de cifrado sea antiguo o débil, que se encuentre un nuevo fallo que permita adivinar la clave de cifrado o romperla, o que el FBI pida una orden judicial para que el propietario del servidor entregue el certificado y llave de cifrado.

Esto le ha sucedido al dueño de Lavabit, donde Snowden tenía su dirección de correo electrónico. Aunque el certificado se revocó en cuanto la información salió a la luz, el daño ya estaba hecho, gran parte de la información que pudiera tener el FBI almacenada, podría ser descifrada con facilidad gracias a esa orden del juez y a que Levison tuvo mal configurados los métodos de cifrado de las comunicaciones del servidor bastante tiempo.

¿Se podría haber evitado? Sí, utilizando una propiedad de los sistemas de cifrado llamada Forward Secrecy, que he visto por ahí traducida como «secreto hacia adelante», a mi me suena mejor «confidencialidad futura».

Forward Secrecy es lo que anunciaba hace poco Google como novedad en su sistema de cifrado HTTPS que ya funciona para las comunicaciones con Gmail.

Para no liarnos demasiado con que es Forward Secrecy, la diferencia fundamental de usarla o no en las comunicaciones radica en que con FS, cada sesión que tengamos con el servidor, genera una clave nueva que se destruye al terminar la sesión, es decir, que no hay manera de que pase lo que ha pasado con Lavabit.

Sin FS el cifrado recae en el certificado y la llave del servidor, que son datos registrados en el sistema de almacenamiento de la máquina y que pueden ser solicitados por el juez.

Cierto es que si el juez está bien asesorado puede pedir al dueño del servidor que guarde una copia de todas las claves de sesión, pero todo el tráfico de datos HTTPS anterior no se podría descifrar teniéndolo almacenado como hizo el FBI en el caso Lavabit.

Con esta información estamos en disposición de responder a la primera pregunta:

¿Es más segura la web de Fastenal (una cadena de cientos de ferreterías en EE.UU) que el Gmail de Google?

La respuesta es un estrepitoso NO aunque visualmente la de Fastenal nos parezca más válida.

La realidad es que aunque ambos usan certificados de seguridad de confianza, Gmail implementa mejor los protocolos, así como las combinaciones de cifrado y negociado de claves entre el servidor y el cliente.

De hecho Fastenal sólo es capaz de ofrecer una combinación de cifrado sobre un servidor muy mal configurado que permite realizar ataques Man-In-the_Middle de tal manera que un atacante puede inyectar información en el contenido cifrado de la transmisión sin demasiada dificultad; aunque limitado a no poder recibir la respuesta, el atacante puede enviar peticiones con las credenciales de la víctima.

Gmail en cambio no solo no es vulnerable a este fallo (ya un poco viejo) sino que implementa Forward Secrecy en las comunicaciones cifradas, una capa más de seguridad para ponerle las cosas difíciles a los «amigos de lo ajeno», lo cual incluye a la NSA y demás sucedáneos nacionales e internacionales.

Con los bancos mencionados pasa lo contrario, Deutsche Bank, además del certificado con validación de empresa, cuenta con mejor cifrado que el Santander, aunque ambos cumplen con los requisitos mínimos para obtener el certificado PCI que viene a ser una garantía sobre la seguridad de las transacciones realizadas en esa web.

Por si todo esto de los diferentes tipos de cifrados no fuese suficiente, de vez en cuando aparecen noticias como esta en la que el servicio secreto francés ha usado a la entidad certificadora del Departamento del Tesoro para falsificar los certificados de varios dominios de Google y que los navegadores web no alertasen al usuario sobre el uso de una entidad certificadora no reconocida.

Que si era para vigilar a sus empleados, que si fue por un error, un descuido, el perro se comió mi clave privada… La cascada de excusas es la habitual cuando se pilla a todo un gobierno haciendo un ataque MitM empleando recursos que deberían ser confiables.

Google ya revocó esos certificados en su navegador Chrome, y ya hay en marcha varios proyectos para tratar de evitar que esto se repita, de momento sólo nos queda tener los ojos abiertos, ya que no sólo podemos ser víctimas de este ataque por parte de un gobierno junto con su entidad certificadora reconocida, también es posible que un desconocido ataque nuestra máquina y nos imstale un certificado propio como de confianza para poder descifrar nuestras comunicaciones basadas en SSL.