[go: up one dir, main page]
Ir al contenido

Server Name Indication

De Wikipedia, la enciclopedia libre

Server Name Indication (SNI, «Indicador del nombre del servidor») es una extensión del protocolo de seguridad en la capa de transporte (TLS).[1]​[2]​[3]​ Este campo indica a qué nombre de host está intentando conectar el cliente antes de que se complete el proceso de handshaking. Esta funcionalidad permite a un servidor utilizar múltiples certificados en una misma dirección IP y número de puerto TCP 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 conceptualmente equivalente al concepto de alojamiento virtual basado en nombres sobre el protocolo HTTP/1.1, pero para HTTPS.

Para hacer uso práctico de SNI, 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 coincida con el nombre de la página web.

Antecedentes del problema

[editar]

Antes de la implantación de SNI, al establecer una conexión TLS, el cliente no tenía ninguna manera de saber a qué sitio trataba de conectarse. Por tanto, si un servidor alojaba varios sitios en un único receptor, el servidor no tenía forma de saber qué certificado utilizar en el protocolo TLS. Es decir, 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, ya que 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 y proceder a la conexión, dejando al usuario asumir 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. Es probable que un servidor responsable de múltiples nombres de host tenga que presentar un certificado diferente para cada nombre (o un pequeño grupo de nombres). Es posible utilizar subjectAltName para contener múltiples dominios controlados por una sola persona en un único certificado. Sin embargo, cada vez que cambie la lista de dominios se deben volver a emitir estos "certificados de comunicaciones unificadas".

El hosting virtual basado en nombre permite el alojamiento de varios nombres de host DNS 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 (en el caso de HTTP, el nombre se presenta en la cabecera de host). Sin embargo, cuando se utiliza HTTPS, se produce el handshake TLS antes de que el servidor vea las cabeceras HTTP. Por lo tanto, no es posible que el servidor utilice la información en la cabecera de host HTTP para decidir qué certificado presenta y, así, 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. Asignar una dirección IP diferente para cada sitio aumenta el coste del alojamiento, ya que se deben justificar las peticiones de direcciones IP en el registro regional de Internet y ya se han agotado las direcciones IPv4. El resultado es que muchos sitios web se previenen con eficacia el uso de comunicaciones seguras. 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 se haya agotado. El resultado fue que muchos sitios web se vieron limitados en la práctica a la hora de utilizar comunicaciones seguras.

Implicaciones de seguridad

[editar]

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

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

Funcionamiento de ESNI

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

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.[13]​

Referencias

[editar]
  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. ↑ 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.» 
  5. ↑ «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. 
  6. ↑ «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. 
  7. ↑ 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. 
  8. ↑ «South Korea is Censoring the Internet by Snooping on SNI Traffic». BleepingComputer (en inglés). Consultado el 17 de mayo de 2019. 
  9. ↑ «Encrypted chat app Signal circumvents government censorship». Engadget. Consultado el 17 de mayo de 2019. 
  10. ↑ «Amazon threatens to suspend Signal's AWS account over censorship circumvention». Signal. Consultado el 17 de mayo de 2019. 
  11. ↑ 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. 
  12. ↑ 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.» 
  13. ↑ a b 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

[editar]

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

Obtenido de «https://es.wikipedia.org/w/index.php?title=Server_Name_Indication&oldid=162804082»