Server Name Indication

Server Name Indication (SNI, en español: Indicador del nombre del servidor) es una extensión del protocolo de seguridad TLS.[1][2][3] 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.[cita requerida]

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.[cita requerida] 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.[4]

Implicaciones de seguridad

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

A mediados de 2018, una actualización llamada SNI cifrada (ESNI)[12] 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.[13]

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

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.[14]

Referencias
  1. Server Name Indication, p. 8. sec. 3.1. RFC 3546.
  2. Server Name Indication, p. 8. sec. 3.1. RFC 4366.
  3. Server Name Indication, p. 9. sec. 3.1. RFC 6066.
  4. "CAcert VHostTaskForce" Archivado el 22 de agosto de 2009 en Wayback Machine., CAcert Wik.
  5. Ghedini, Alessandro (24 de septiembre de 2018). «Encrypt it or lose it: how encrypted SNI works» (html). Cloudflare blog (en inglés). Archivado desde el original el 24 de septiembre de 2018. Consultado el 12 de junio de 2019. «This means that an on-path observer (say, an ISP, coffee shop owner, or a firewall) can intercept the plaintext ClientHello message, and determine which website the client is trying to connect to. That allows the observer to track which sites a user is visiting. »
  6. «Web Filter: SNI extension feature and HTTPS blocking». www3.trustwave.com (en inglés). Archivado desde el original el 8 de mayo de 2019. Consultado el 17 de mayo de 2019.
  7. «Sophos UTM: Understanding Sophos Web Filtering». Sophos Community (en inglés). Archivado desde el original el 8 de mayo de 2019. Consultado el 17 de mayo de 2019.
  8. Chrisment, Isabelle; Goichot, Antoine; Cholez, Thibault; Shbair, Wazen (11 de mayo de 2015). Efficiently Bypassing SNI-based HTTPS Filtering (en inglés). pp. 990-995. doi:10.1109/INM.2015.7140423. Consultado el 17 de mayo de 2019.
  9. «South Korea is Censoring the Internet by Snooping on SNI Traffic». BleepingComputer (en inglés). Consultado el 17 de mayo de 2019.
  10. «Encrypted chat app Signal circumvents government censorship». Engadget. Consultado el 17 de mayo de 2019.
  11. «Amazon threatens to suspend Signal's AWS account over censorship circumvention». Signal. Consultado el 17 de mayo de 2019.
  12. E. Rescorla; K. Oku; N. Sullivan; C. Wood (11 de marzo de 2019). «Encrypted Server Name Indication for TLS 1.3 draft-ietf-tls-esni-03» (html). IETF (en inglés). Archivado desde el original el 21 de marzo de 2019. Consultado el 17 de mayo de 2019.
  13. Stenberg, Daniel (1 de marzo de 2019). «Re: Support of Encrypted SNI» (html). curl haxx (en inglés). Archivado desde el original el 21 de abril de 2019. Consultado el 17 de mayo de 2019. «ESNI basically requires some DNS records to be able to encrypt the SNI field in the TLS handshake. In order to get to those records, we need to query a resolver and for that we either need DOH support (just like Firefox) since then we can fiddle with DNS packet directly and they are encrypted over the wire - or possibly we need a build using c-ares that also offer the necessary DNS functions. »
  14. Schoen, Seth (24 de septiembre de 2018). «ESNI: A Privacy-Protecting Upgrade to HTTPS» (html). EFF (en inglés). Archivado desde el original el 18 de mayo de 2019. Consultado el 7 de junio de 2019.

Enlaces externos

ESNI: A Privacy-Protecting Upgrade to HTTPS en Wayback Machine (archivado el 9 de mayo de 2019).(en inglés).

Este artículo ha sido escrito por Wikipedia. El texto está disponible bajo la licencia Creative Commons - Atribución - CompartirIgual. Pueden aplicarse cláusulas adicionales a los archivos multimedia.