Indicación del nombre del servidor

La Indicación de Nombre de Servidor ( SNI ) es una extensión de Seguridad de la Capa de Transporte (TLS) donde un cliente indica a qué nombre de host está intentando conectarse al inicio del proceso de establecimiento de conexión. ^{[ 1 ]} La extensión permite que un servidor presente uno de varios certificados posibles en la misma dirección IP y número de puerto , lo que permite que varios servicios (incluidos sitios web HTTPS ) sean servidos por la misma dirección IP sin usar un solo certificado. Para HTTPS, es el equivalente conceptual del alojamiento virtual HTTP/1.1 . En la especificación original, el nombre de host no está cifrado; la especificación posterior de Encrypted Client Hello corrige esto. La extensión SNI se especificó en 2003 en RFC 3546 . 

Antes de SNI, al establecer una conexión TLS, el cliente no podía especificar a qué sitio intentaba conectarse. Por lo tanto, si un servidor alojaba varios sitios en un único oyente, no podía saber qué certificado usar en el protocolo TLS. En detalle, al establecer 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 los nombres incluidos en el certificado. Si coinciden, la conexión se establece con normalidad. Si no coinciden, se advierte al usuario de la discrepancia y la conexión puede interrumpirse, ya que la discrepancia podría indicar un intento de ataque de intermediario (man-in-the-middle). Sin embargo, algunas aplicaciones permiten al usuario omitir la advertencia y continuar con la conexión, asumiendo este 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— obtener un único certificado que cubra todos los nombres de los que será responsable un servidor. Un servidor responsable de varios nombres de host probablemente necesitará presentar un certificado diferente para cada nombre (o pequeño grupo de nombres). Es posible utilizar subjectAltName para incluir varios dominios controlados por una misma persona ^{[ 2 ]} en un solo certificado. Dichos «certificados de comunicaciones unificadas» deben reemitirse cada vez que cambie la lista de dominios.

El alojamiento virtual basado en nombres permite que un único servidor (generalmente un servidor web) aloje varios nombres de host DNS en la misma dirección IP. Para ello, el servidor utiliza el nombre de host que el cliente proporciona como parte del protocolo (en HTTP, el nombre se incluye en la cabecera de host). Sin embargo, al usar HTTPS, el protocolo de enlace TLS se ejecuta antes de que el servidor reciba las cabeceras HTTP. Por lo tanto, el servidor no podía utilizar la información de la cabecera de host HTTP para determinar qué certificado presentar, y, en consecuencia, solo se podían servir nombres protegidos por el mismo certificado desde la misma dirección IP.

En la práctica, esto significaba que un servidor HTTPS solo podía servir un dominio (o un pequeño grupo de dominios) por dirección IP para una navegación segura y eficiente. Asignar una dirección IP independiente a cada sitio web 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 carga administrativa al tener varias direcciones IP en una sola máquina, aunque el espacio de direcciones no esté agotado. Como resultado, muchos sitios web se vieron prácticamente impedidos de 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 al servidor seleccionar el dominio virtual correcto con anticipación y presentar al navegador el certificado que contiene el nombre correcto. Por lo tanto, con clientes y servidores que implementan SNI, un servidor con una sola dirección IP puede dar servicio a un grupo de nombres de dominio para los que no es práctico obtener un certificado común.

SNI se incorporó a los RFC de Internet del IETF en junio de 2003 mediante el RFC 3546, Extensiones de seguridad de la capa de transporte (TLS) . La versión más reciente del estándar es el RFC 6066.

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

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

En 2004, el proyecto EdelKey creó un parche para agregar TLS/SNI a OpenSSL . ^{[ 37 ]} En 2006, este parche se adaptó a la rama de desarrollo de OpenSSL, y en 2007 se adaptó a OpenSSL 0.9.8 (lanzado por primera vez en 0.9.8f ^{[ 38 ]} ). 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 una aplicación implemente SNI, la biblioteca TLS que utiliza debe implementarlo y la aplicación debe pasarle el nombre de host. Para complicar aún más las cosas, la biblioteca TLS puede estar incluida en la aplicación o ser un componente del sistema operativo subyacente. Por este motivo, algunos navegadores implementan SNI en cualquier sistema operativo, mientras que otros solo lo hacen en determinados sistemas operativos.

• RFC 6066 (sustituye a RFC 4366 , que a su vez sustituyó a RFC 3546 )   
• Wiki de Mozilla - Saludo de cliente cifrado (ECH)