Hoy anunciamos el soporte para la SNI cifrada, una extensión para el protocolo TLS 1.3 que optimiza la privacidad de los usuarios de internet al impedir que los observadores en la ruta de acceso, lo que incluye los ISP, los propietarios de cafeterías y los firewalls, intercepten la extensión de la indicación de nombre del servidor (SNI) del protocolo de seguridad TLS y la utilicen para determinar qué sitios web están visitando los usuarios.
La SNI cifrada, junto con otras características de seguridad de internet que ya ofrece Cloudflare de forma gratuita, dificultará la censura del contenido y el rastreo a los usuarios en internet. Continúe leyendo para saber cómo funciona.
SNWhy?
La extensión de la indicación de nombre del servidor (SNI) del protocolo de seguridad TSL, originalmente estandarizada en 2003, permite a los servidores alojar varios sitios web con capacidad para TLS en el mismo conjunto de direcciones IP, y para ello, exige que los clientes especifiquen a qué sitio quieren conectarse durante el protocolo de enlace inicial de TLS. Sin la SNI, el servidor no sabría, por ejemplo, qué certificado brindar al cliente o qué configuración se aplicaría a la conexión.
El cliente agrega la extensión SNI que contiene el nombre de host del sitio al que se está conectando al mensaje ClientHello. Envía el mensaje ClientHello al servidor durante el protocolo de enlace TLS. Lamentablemente, el mensaje ClientHello se envía sin cifrar, ya que en ese momento el cliente y el servidor no comparten una clave de cifrado.
TLS 1.3 with Unencrypted SNI
TLS 1.3 con SNI sin cifrado
Esto significa que un observador en la ruta de acceso (por ejemplo, un ISP, el propietario de una cafetería o un firewall) puede interceptar el mensaje ClientHello de texto sin formato y determinar a qué sitio web está intentando conectarse el cliente. Esto permite al observador rastrear qué sitios está visitando un usuario.
Pero con el cifrado SNI, el cliente cifra el SNI aunque el resto del mensaje ClientHello se envíe en texto sin formato.
TLS 1.3 with Encrypted SNI
TLS 1.3 con SNI cifrado
Entonces, ¿por qué el SNI original antes no se podía cifrar y ahora sí? ¿De dónde proviene la clave de cifrado si el cliente y el servidor aún no la han acordado?
Si la gallina existe antes que el huevo, ¿en qué lugar se ubicaría la gallina?
Al igual que con muchas otras características de internet, la respuesta es simplemente el sistema de nombres de dominio “DNS”.
El servidor emite una clave pública en un registro DNS conocido, que el cliente pueda capturar antes de conectarse (como ya lo hace para A, AAAA y otros registros). Luego, el cliente reemplaza la extensión SNI en ClientHello por una extensión “SNI cifrada”, que no es otra que la extensión SNI original, pero cifrada con una clave de cifrado simétrica obtenida mediante la clave pública del servidor, como se describe a continuación. El servidor, que posee la clave privada y también puede obtener la clave de cifrado simétrica, luego puede descifrar la extensión y, por lo tanto, finalizar la conexión (o reenviarla a un servidor backend). Como solo el cliente y el servidor al que se está conectando pueden obtener la clave de cifrado, la SNI cifrada no puede descifrarse y ningún tercero tiene acceso a esta.
Es importante tener en cuenta que esta es una extensión a TLS versión 1.3 y superior, y que no funciona con versiones anteriores del protocolo. La razón es muy simple: uno de los cambios introducidos por TLS 1.3 (no sin problemas) implicaba mover el mensaje de certificado enviado por el servidor a la parte cifrada del protocolo de enlace TLS (antes de 1.3, se enviaba en texto sin formato). Antes de este cambio fundamental en el protocolo, un atacante podía determinar la identidad del servidor con tan solo observar el certificado de texto sin formato durante la transmisión.
El mecanismo criptográfico subyacente implica el uso del algoritmo de intercambio de claves Diffie-Hellman que permite al cliente y al servidor generar una clave de cifrado compartida a través de un canal no confiable. La clave de SNI cifrada la calcula el cliente con la clave pública del servidor (que en realidad es la parte pública de un recurso compartido de claves semiestáticas Diffie-Hellman) y la parte privada de un recurso compartido temporal Diffie-Hellman que el cliente genera sobre la marcha y luego descarta de inmediato una vez que envía el mensaje ClientHello al servidor. Los datos adicionales (como algunos de los parámetros criptográficos que el cliente envía como parte de su mensaje ClientHello) también se mezclan en el proceso criptográfico para optimizar la medida.
La extensión de la indicación de nombre del servidor cifrada (ESNI) del cliente incluirá, no solo los bits SNI cifrados reales, sino también el recurso compartido de clave pública del cliente, el conjunto de cifrado que utilizó para el cifrado y el resumen del registro DNS de ESNI del servidor. Por otro lado, el servidor utiliza su propio recurso compartido de claves privadas y la parte pública del recurso compartido del cliente para generar la clave de cifrado y descifrar la extensión.
Si bien este proceso puede parecer demasiado complicado, garantiza que la clave de cifrado esté vinculada criptográficamente a la sesión de la TLS específica para la que se generó, y no se puede reutilizar en conexiones múltiples. Esto evita que un atacante que ve la extensión cifrada que envía el cliente la capture y la reproduzca en el servidor en una sesión independiente para desenmascarar la identidad del sitio web al que el usuario intentaba conectarse (esto se conoce como ataque de modalidad “cortar y pegar”).
Sin embargo, un compromiso de la clave privada del servidor pondría en riesgo todas las claves simétricas ESNI generadas a partir de este (lo que permitiría a los observadores descifrar los datos encriptados previamente recopilados), razón por la cual la implementación de cifrado de SNI de Cloudflare rota cada hora las claves del servidor para optimizar la confidencialidad. Sin embargo, hace un seguimiento de las claves de las horas previas para permitir el almacenamiento en caché de DNS y retrasos de replicación, de manera que los clientes con claves apenas vencidas aún pueden usar la ESNI sin problemas (pero finalmente todas las claves se desechan y se olvidan).
Pero espera, ¿DNS? ¿De verdad?
Es posible que el lector atento se haya dado cuenta de que el simple uso del DNS (que, por defecto, no está cifrado) haría que todo el concepto de la SNI cifrada no tuviese sentido: un observador en la ruta de acceso podría determinar a qué sitio web se está conectando el cliente con tan solo observar las consultas de DNS de texto sin formato enviadas por el propio cliente, independientemente de si se usó o no la SNI cifrada.
Pero con la introducción de funciones de DNS, como DNS mediante TLS (DoT) y DNS mediante HTTPS (DoH), y de resoluciones de DNS públicos que brindan esas funciones a sus usuarios (como 1.1.1.1 de Cloudflare), las consultas de DNS ahora pueden cifrarse y protegerse de los ojos indiscretos tanto de los censuradores como de los rastreadores.
Sin embargo, si bien se puede confiar en las respuestas de las resoluciones de DoT/DoH de DNS, hasta cierto punto (a pesar de las resoluciones malignas), aún podría ser posible que un atacante determinado contamine la memoria caché de la resolución al interceptar su comunicación con el servidor DNS autorizado e introducir datos maliciosos. Es decir, a menos que tanto el servidor autorizado como la resolución admitan DNSSEC[1] . Por cierto, los servidores de DNS autorizados de Cloudflare pueden firmar respuestas devueltas a las resoluciones y la resolución 1.1.1.1 puede verificarlas.
¿Qué sucede con la dirección IP?
Si bien ahora las consultas de DNS y las extensiones SNI de TSL están protegidas de los atacantes en la ruta de acceso, es posible que aún se pueda determinar qué sitios web visitan los usuarios con solo mirar las direcciones IP de destino en el tráfico que se origina desde los dispositivos de los usuarios. Algunos de nuestros clientes están protegidos hasta cierto punto, ya que muchos dominios de Cloudflare comparten los mismos conjuntos de direcciones, pero esto no es suficiente y es necesario trabajar más para brindar más protección a los usuarios finales. Manténgase atento para obtener más actualizaciones de Cloudflare sobre el tema.
¿Dónde me inscribo?
La SNI cifrada ahora está habilitada de forma gratuita en todas las zonas de Cloudflare que utilizan nuestros servidores de nombres, por lo tanto, no es necesario hacer nada para habilitarla en su sitio web de Cloudflare. En cuanto al navegador, nuestros amigos de Firefox nos dicen que esta semana agregarán soporte de SNI cifrada a Firefox Nightly (tenga en cuenta que la especificación de SNI cifrada todavía está en una etapa de desarrollo, por lo tanto, aún no es estable).
Visite encryptedsni.com para comprobar la seguridad de su experiencia de navegación. ¿Está utilizando un DNS seguro? ¿Su resolución está validando las firmas de DNSSEC? ¿Su navegador es compatible con TLS 1.3? ¿Su navegador cifró la SNI? Si la respuesta a todas esas preguntas es afirmativa, entonces usted puede quedarse tranquilo al saber que su navegación está protegida de las miradas indiscretas.
Conclusión
La SNI cifrada, junto con TLS 1.3, DNSSEC y DoT/DoH, soluciona una de las pocas vulnerabilidades restantes que permiten la vigilancia y la censura en internet. Aún es necesario trabajar más para tener una internet sin vigilancia, pero estamos (lentamente) llegando a ese punto.
[1]: Es importante mencionar que la DNSSEC podría ser inhabilitada por el secuestro de la ruta del BGP entre una resolución de DNS y el servidor de TLD. La semana pasada anunciamos nuestro compromiso con RPKI, y si las resoluciones de DNS y TLD también implementan la infraestructura de clave pública de recursos (RPKI), este tipo de secuestro será mucho más difícil.
Suscríbete al blog para recibir actualizaciones diarias sobre todos nuestros anuncios de la Semana del Aniversario.