Server Name Indication
# Server Name Indication

Server Name Indication (SNI, en español: Indicador del nombre del servidor) es una extensión del protocolo de seguridad TLS. Este indica qué nombre de host el cliente está intentando conectar antes de que el proceso de handshaking se complete. Esta funcionalidad permite a un servidor utilizar múltiples certificados en una misma dirección IP y número de puerto y permitir múltiples sitios cifrados (HTTPS) o cualquier otro servicio sobre TLS pueda ser servido en una misma IP sin que todos los sitios compartan un certificado común. Esto es equivalente al concepto de VirtualHost HTTPS sobre el protocolo HTTP/1.1.

Para hacer uso de SNI prácticamente, es necesario que una gran proporción de los usuarios usen un navegador web que soporte dicha característica. Los usuarios cuyos navegadores no soportan SNI serán presentados con un certificado predeterminado y por lo tanto son propensos a recibir advertencias de certificado, a menos que el servidor está equipado con un certificado comodín que coincide con el nombre de la página web. A partir de noviembre de 2019, las únicas grandes bases de usuarios cuyos navegadores no soportan SNI son de Android 2.x (navegador predeterminado), Internet Explorer en Windows XP y versiones de Java antes de 1.7 en cualquier sistema operativo.

## Antecedentes del problema

Al establecer una conexión TLS el cliente solicita un certificado digital en el servidor web, una vez que el servidor envía el certificado, el cliente examina y compara el nombre que estaba tratando de conectar con el nombre(s) incluido en el certificado. Si se encuentra una coincidencia la conexión procede de forma normal. Si no se encuentra una coincidencia, el usuario puede ser advertido de la discrepancia y la conexión puede ser abortada como la falta de correspondencia puede indicar un intento de ataque man-in-the-middle . Sin embargo, algunas aplicaciones permiten al usuario pasar por alto la advertencia de proceder a la conexión, con el usuario asumiendo la responsabilidad de confiar en el certificado y, por extensión, de la conexión.

Es posible que un certificado cubra múltiples nombres de host. La especificación X.509 v3 introduce el campo subjectAltName que permite un certificado para especificar más de un dominio y el uso de comodines en tanto el nombre común y campos subjectAltName. Sin embargo, puede ser poco práctico o incluso imposible, debido a la falta de una lista completa de todos los nombres de antemano. Como el servidor de tal manera que es responsable de múltiples nombres de host es probable que tenga que presentar un certificado diferente para cada nombre (o un pequeño grupo de nombres). Desde 2005, se ha quedado CAcert experimentos sobre diferentes métodos de uso de TLS en los servidores virtuales. La mayoría de los experimentos son insatisfactorios y poco práctico. Por ejemplo, es posible utilizar subjectAltName para contener múltiples dominios controlados por una sola persona en un único certificado. Llamados "certificados de comunicaciones unificadas" sin embargo los mismos se deben volver a emitir cada vez que la lista de dominios de cambie.

El hosting virtual basado en nombre permite que varios nombres de host DNS ser alojados en un solo servidor (generalmente un servidor web) en la misma dirección IP. Para lograr esto, el servidor utiliza un nombre de host presentado por el cliente como parte del protocolo (HTTP para el nombre se presenta en el encabezado de host). Sin embargo cuando se utiliza HTTPS el clientHello TLS ocurre antes de que el servidor vea cualquiera de las cabeceras HTTP. Por lo tanto no es posible que el servidor utilice la información en el encabezado de host HTTP para decidir cuál es el certificado para presentar y, como tal, solo los nombres incluidos en el mismo certificado se puede servir desde la misma dirección IP.

En la práctica, esto significa que un servidor HTTPS solo puede servir a un dominio (o un pequeño grupo de dominios) por cada dirección IP para la navegación segura. Asignación de una dirección IP diferente para cada sitio aumenta el coste de la acogida ya las peticiones de direcciones IP deben estar justificadas en el registro regional de Internet y las direcciones IPv4 son ahora escasos. El resultado es que muchos sitios web se previenen con eficacia el uso de comunicaciones seguras.

## Implicaciones de seguridad

Cuando el nombre de host deseado no está cifrado, un intruso puede ver qué sitio se está solicitando. Esto ayuda a las empresas de seguridad a proporcionar una característica de filtrado, y a los gobiernos les permite implementar la censura. Si bien el antifaz de dominio (en inglés: domain fronting) se usó como una solución alternativa, ahora tanto Google como AWS han tomado medidas para rechazar esto, y por lo tanto, se está convirtiendo en una alternativa menos.

A mediados de 2018, una actualización llamada SNI cifrada (ESNI) se está implementando en una "fase experimental" para abordar este riesgo de espionaje de dominios.

El 1 de marzo de 2019, Daniel Stenberg declaró que Mozilla Firefox es compatible con ESNI.

### Funcionamiento de ESNI

Se presenta a continuación, de manera didáctica, el esquema de solicitud de un documento web sin y con ESNI. :

* Con el uso del protocolo HTTP toda la información viaja de manera pública:
* Con la utilización del protocolo HTTPS todo está cifrado excepto el dominio solicitado que contienen el documento web:
* Al conectarse con HTTPS y una Indicación de Nombre de Servidor Cifrado (ESNI) también se protege el nombre del sitio:

ESNI no proporciona a estas organizaciones en la cadena de conexión ninguna información sobre la actividad de navegación que de otro modo no poseerían: aún ven partes de su actividad de Internet de la misma manera, ya sea con o sin ESNI. Entonces, la tecnología disminuye estrictamente lo que otras personas saben sobre lo que hace el usuario en línea. Y la ESNI también puede funcionar a través de VPN o Tor, agregando así otra capa de protección a la privacidad.

