Indicación del nombre del servidor

Server Name Indication ( SNI ) es una extensión del protocolo de red informática Transport Layer Security (TLS) mediante el cual un cliente indica a qué nombre de host está intentando conectarse al inicio del proceso de enlace. ^[1] La extensión permite que un servidor presente uno de los múltiples certificados posibles en la misma dirección IP y número de puerto TCP y, por lo tanto, permite que varios sitios web seguros ( HTTPS ) (o cualquier otro servicio sobre TLS) sean atendidos por la misma dirección IP sin requerir que todos esos sitios usen el mismo certificado. Es el equivalente conceptual del alojamiento virtual basado en nombres HTTP/1.1 , pero para HTTPS. Esto también permite que un proxy reenvíe el tráfico del cliente al servidor correcto durante el enlace TLS/SSL. El nombre de host deseado no está cifrado en la extensión SNI original, por lo que un espía puede ver qué sitio se está solicitando. La extensión SNI se especificó en 2003 en RFC  3546

Antes de SNI, al realizar una conexión TLS, el cliente no tenía forma de especificar a qué sitio intentaba conectarse. Por lo tanto, si un servidor aloja varios sitios en un solo receptor, el servidor no tiene forma de saber qué certificado usar en el protocolo TLS. En más detalle, al realizar una conexión TLS, el cliente solicita un certificado digital al servidor web. Una vez que el servidor envía el certificado, el cliente lo examina y compara el nombre al que intentaba conectarse con el nombre o los nombres incluidos en el certificado. Si se produce una coincidencia, la conexión continúa de manera normal. Si no se encuentra una coincidencia, se puede advertir al usuario sobre la discrepancia y la conexión puede interrumpirse, ya que la falta de coincidencia puede indicar un intento de ataque de intermediario. Sin embargo, algunas aplicaciones permiten al usuario omitir la advertencia para continuar con la conexión, y el usuario asume la responsabilidad de confiar en el certificado y, por extensión, en la conexión.

Sin embargo, puede resultar difícil (o incluso imposible debido a la falta de una lista completa de todos los nombres por adelantado) obtener un único certificado que cubra todos los nombres de los que será responsable un servidor. Es probable que un servidor que sea responsable de varios nombres de host deba presentar un certificado diferente para cada nombre (o pequeño grupo de nombres). Es posible utilizar subjectAltName para incluir varios dominios controlados por una persona ^[2] en un único certificado. Estos "certificados de comunicaciones unificadas" deben volver a emitirse cada vez que cambia la lista de dominios.

El alojamiento virtual basado en nombres permite que varios nombres de host DNS sean alojados por un único servidor (normalmente un servidor web) en la misma dirección IP. Para lograrlo, el servidor utiliza un nombre de host presentado por el cliente como parte del protocolo (para HTTP, el nombre se presenta en el encabezado del host). Sin embargo, cuando se utiliza HTTPS, el protocolo de enlace TLS se produce antes de que el servidor vea ningún encabezado HTTP. Por lo tanto, no era posible que el servidor utilizara la información del encabezado del host HTTP para decidir qué certificado presentar y, como tal, solo los nombres cubiertos por el mismo certificado podían servirse desde la misma dirección IP.

En la práctica, esto significaba que un servidor HTTPS solo podía dar servicio a un dominio (o a un pequeño grupo de dominios) por dirección IP para una navegación segura y eficiente. Asignar una dirección IP independiente para cada sitio aumenta el costo del alojamiento, ya que las solicitudes de direcciones IP deben justificarse ante el registro regional de Internet y las direcciones IPv4 ya están agotadas. En el caso de IPv6, aumenta la sobrecarga administrativa al tener varias IP en una sola máquina, aunque el espacio de direcciones no esté agotado. El resultado fue que muchos sitios web se vieron efectivamente limitados para utilizar comunicaciones seguras.

SNI soluciona este problema haciendo que el cliente envíe el nombre del dominio virtual como parte del mensaje ClientHello de la negociación TLS . ^[3] Esto permite que el servidor seleccione el dominio virtual correcto de forma anticipada y presente al navegador el certificado que contiene el nombre correcto. Por lo tanto, con clientes y servidores que implementan SNI, un servidor con una única dirección IP puede servir a un grupo de nombres de dominio para los que no es práctico obtener un certificado común.

La norma SNI se añadió a las RFC de Internet de la IETF en junio de 2003 a través de la RFC 3546, Extensiones de seguridad de la capa de transporte (TLS) . La última versión de la norma es la RFC 6066.

La carga útil de la indicación del nombre del servidor no está cifrada, por lo que el nombre de host del servidor al que el cliente intenta conectarse es visible para un espía pasivo. Esta debilidad del protocolo fue explotada por el software de seguridad para el filtrado y monitoreo de redes ^{[4] [5] [6]} y por los gobiernos para implementar la censura. ^[7]

Actualmente, existen múltiples tecnologías que intentan ocultar la indicación del nombre del servidor:

El dominio fronting es una técnica que consiste en reemplazar el nombre de host deseado en SNI por otro alojado en el mismo servidor o, más frecuentemente, en una red de servidores conocida como red de entrega de contenido . Cuando un cliente utiliza el dominio fronting, reemplaza el dominio del servidor en SNI (sin cifrar), pero lo deja en el encabezado del host HTTP (que está cifrado por TLS) para que el servidor pueda servir el contenido correcto. El dominio fronting viola el estándar que define a SNI en sí, por lo que su compatibilidad es limitada (muchos servicios comprueban que el host de SNI coincida con el host del encabezado HTTP y rechazan las conexiones con SNI con dominio fronting por considerarlas inválidas). Si bien el dominio fronting se utilizó en el pasado para evitar la censura gubernamental, ^[8] su popularidad disminuyó porque los principales proveedores de la nube (Google, AWS de Amazon y CloudFront) lo prohíben explícitamente en sus TOS y tienen restricciones técnicas en su contra. ^[9]

Encrypted Client Hello ( ECH ) es una extensión del protocolo TLS 1.3 que permite el cifrado de todo el mensaje Client Hello, que se envía durante la etapa inicial de la negociación TLS 1.3. ^[10] ECH cifra la carga útil con una clave pública que la parte confiada (un navegador web) necesita conocer de antemano, lo que significa que ECH es más eficaz con CDN grandes que los proveedores de navegadores conocen de antemano.

La versión inicial de 2018 de esta extensión se llamó Encrypted SNI (ESNI) ^[11] y sus implementaciones se implementaron de manera "experimental" para abordar este riesgo de escuchas ilegales de dominio. ^{[12] [13] [14]} Firefox 85 eliminó la compatibilidad con ESNI. ^[15] A diferencia de ECH, Encrypted SNI encriptó solo el SNI en lugar de todo el Client Hello. ^[16] La compatibilidad con opt-in para esta versión se incorporó a Firefox en octubre de 2018 ^[17] y requirió habilitar DNS sobre HTTPS (DoH). ^[18]

En marzo de 2020, ESNI se modificó para convertirla en la extensión ECH, después de que un análisis demostrara que cifrar solo la SNI no es suficiente. Por ejemplo, las especificaciones permiten que la extensión de clave precompartida contenga cualquier dato para facilitar la reanudación de la sesión, incluso la transmisión de una copia en texto sin formato de exactamente el mismo nombre de servidor cifrado por ESNI. Además, cifrar las extensiones una por una requeriría una variante cifrada de cada extensión, cada una con posibles implicaciones de privacidad, e incluso eso expone el conjunto de extensiones anunciadas. Por último, la implementación en el mundo real de ESNI ha expuesto limitaciones de interoperabilidad. ^[19] El nombre corto era ECHO en marzo de 2020 ^[16] y cambió a ECH en mayo de 2020. ^[20]

Tanto ESNI como ECH son compatibles únicamente con TLS 1.3 porque se basan en KeyShareEntry, que se definió por primera vez en TLS 1.3. ^{[21] [22]} Además, para utilizar ECH, el cliente no debe proponer versiones de TLS inferiores a 1.3. ^[23]

Otro borrador de Internet incorpora un parámetro para transmitir las claves públicas ECH a través de los tipos de registros DNS HTTPS y SVCB , acortando el proceso de protocolo de enlace. ^{[24] [25]}

En agosto de 2020, el Gran Cortafuegos de China comenzó a bloquear el tráfico ESNI, aunque todavía permite el tráfico ECH. ^[26]

En octubre de 2020, el proveedor de servicios de Internet ruso Rostelecom y su operador móvil Tele2 comenzaron a bloquear el tráfico ESNI. ^[27] En septiembre del mismo año, el Ministerio de Censura ruso Roscomnadzor planeó prohibir una serie de protocolos de cifrado, entre los que se encontraban TLS 1.3 y ESNI, que obstaculizaban la censura del acceso a los sitios web. ^{[28] [29] [30]}

En julio de 2023, en la reunión IETF117 , los miembros que trabajan en ECH informaron que Chrome y Firefox estaban realizando una prueba de muestra del 1% y que el equipo espera que el borrador final se envíe a la evaluación del IESG en enero de 2024. ^{[31] [32]}

En septiembre de 2023, Cloudflare comenzó a admitir ECH para dominios alojados. ^[33]

En octubre de 2023, Mozilla habilitó ECH de forma predeterminada en Firefox v118, siempre que DNS sobre HTTPS (DoH) también esté habilitado ^{[34] [35]} para mantener las solicitudes DNS para registros de recursos HTTPS protegidas de escuchas en la red informática. ^[36] En septiembre de 2023, la versión 117 de Chromium (usada en Google Chrome , Microsoft Edge , Samsung Internet y Opera ) lo habilitó de forma predeterminada, requiriendo también que las claves se implementen en registros de recursos HTTPS en DNS. ^{[37] [38]}

En 2004, el proyecto EdelKey creó un parche para añadir TLS/SNI a OpenSSL . ^[39] En 2006, este parche se trasladó a la rama de desarrollo de OpenSSL y, en 2007, se trasladó a OpenSSL 0.9.8 (publicado por primera vez en 0.9.8f ^[40] ). Los primeros navegadores web con soporte para SNI aparecieron en 2006 (Mozilla Firefox 2.0, Internet Explorer 7), y los servidores web más tarde (Apache HTTP Server en 2009, Microsoft IIS en 2012).

Para que un programa de aplicación implemente SNI, la biblioteca TLS que utiliza debe implementarla y la aplicación debe pasar el nombre de host a la biblioteca TLS. Para complicar aún más las cosas, la biblioteca TLS puede estar incluida en el programa de aplicación o ser un componente del sistema operativo subyacente. Debido a esto, algunos navegadores implementan SNI cuando se ejecutan en cualquier sistema operativo, mientras que otros lo implementan solo cuando se ejecutan en ciertos sistemas operativos. ^{[ cita requerida ]}

• RFC 6066 (deja obsoleto el RFC 4366, que dejó obsoleto el RFC 3546)
• Wiki de Mozilla - Cliente de saludo cifrado (ECH)