¿Por qué las solicitudes HTTPS incluyen el nombre del host en texto simple?

El nombre de host se incluye en el protocolo de enlace SSL inicial para admitir servidores que tienen varios nombres de host (con certificados diferentes) en la misma dirección IP (SNI: Indicación del nombre del servidor). Esto es similar al encabezado de host en las solicitudes HTTP simples. El nombre se incluye en el primer mensaje del cliente (ClientHello), es decir, antes de que se realice cualquier identificación e intercambio de claves, de modo que el servidor pueda ofrecer el certificado correcto para la identificación.

Si bien el cifrado del nombre de host sería bueno, la pregunta sería qué clave utilizar para el cifrado. El intercambio de claves se realiza solo después de la identificación del sitio mediante un certificado, ya que de lo contrario podría intercambiar claves con un intermediario. Pero la identificación con certificados ya necesita el nombre de host para que el servidor pueda ofrecer el certificado correspondiente. Por lo tanto, el cifrado del nombre de host debe realizarse con una clave basada en algún otro tipo de identificación o de una manera que no sea segura contra el hombre en el medio.

Podría haber formas de proteger el nombre de host en el protocolo de enlace de SSL, pero al costo de una sobrecarga adicional en el protocolo de enlace y la infraestructura. Hay una discusión continua sobre si y cómo incluir SNI cifrado en TLS 1.3. Le sugiero que eche un vistazo a esta presentación y la lista de correo IETF TLS .

Aparte de eso, la filtración del nombre de host también puede ocurrir por otros medios, como la búsqueda de DNS anterior para el nombre. Y, por supuesto, el certificado enviado en la respuesta del servidor no está cifrado también (el mismo problema, aún no hay clave) y, por lo tanto, se puede extraer el destino solicitado de la respuesta del servidor.

Hay una gran cantidad de sitios que no funcionarán sin SNI, como toda la oferta gratuita de SSL de Cloudflares. Si un cliente que no es compatible con SNI (como IE8 en Windows XP) accedió a esto, se producirá un certificado incorrecto o un error de reconocimiento SSL como 'unknown_name'.

SNI existe para el alojamiento virtual (varios servidores, con nombres distintos, en la misma dirección IP). Cuando un cliente SSL se conecta a un servidor SSL, quiere saber si está hablando con el servidor correcto. Para ello, busca el nombre del servidor deseado en el certificado. Cada pirata informático malvado puede comprar un certificado para su propio servidor (llamado evilhacker.com ), pero no podrá usarlo para un servidor falso que se presenta como honest-bank-inc.com porque el navegador del cliente intenta conectarse a https://honest-bank-inc.com/ . será bastante inflexible al encontrar en el supuesto certificado de servidor la cadena honest-bank-inc.com , y ciertamente no evilhacker.com .

Hasta ahora todo bien. Entonces se convierte en la parte técnica. En "HTTPS", tiene HTTP encapsulado en SSL. Esto significa que el túnel SSL se establece primero (el procedimiento de "handshake") y luego, solo entonces, el cliente envía la solicitud HTTP dentro de ese túnel. Durante el protocolo de enlace, el servidor debe enviar su certificado al cliente. Pero, en ese momento , el cliente aún no le ha dicho al servidor con quién está tratando de hablar. El servidor puede suponer que, desde que recibió la conexión, el nombre que el cliente quiere alcanzar es probablemente uno de los nombres de sitio que el servidor aloja. Pero eso es acertijo y falla si el servidor aloja varios sitios con nombres distintos.

Hay casi tres formas de salir de este enigma:

• Una IP por sitio. Dado que el servidor conoce la dirección IP de destino desde el principio de la conexión, el servidor puede usar esa dirección IP para saber qué servidor es el verdadero destino. Por supuesto, la escasez relativa de direcciones IP hace que la solución tradicional sea menos atractiva hoy en día.

• Varios nombres en el certificado del servidor. Esto es perfectamente válido. Los propios Google tienden a poner más de 70 nombres en su certificado. Una variante es "nombres de comodín" que contienen '*', que coinciden con muchos nombres. Sin embargo, esto funciona solo mientras se conozcan todos los nombres cuando se emita el certificado. Para un servicio de alojamiento de sitios web, esto significaría comprar un nuevo certificado cada vez que un cliente se registre.

• SNI. Con SNI, el cliente envía el nombre previsto al principio del protocolo de enlace, antes de que el servidor envíe su certificado. Esta es la solución moderna, y ahora que Windows XP ha ido más allá del límite, finalmente se puede usar ampliamente (IE en Windows XP fue el último navegador que no admitía SNI).

Obviamente, el hecho de que se esté comunicando con algún servidor no puede ocultarse de la IP. Los paquetes deben salir de su máquina, ingresar a la red, enrutarse al destino y entregarse. No es un secreto que estás contactando con un servidor que entrega páginas desde enlace .

Sin embargo, la URL no contiene la IP. En su lugar, contiene más de una pieza de información. No solo contiene el nombre de host (que debe resolverse en una dirección IP), sino que también contiene detalles sobre la solicitud específica: diríjalo a un servidor en esa dirección denominada www, buscar, correo, etc., y en esta ruta de directorio nombre.

Los servicios de alojamiento han explotado esta dirección indirecta para admitir múltiples sitios en un único servidor web a través de la Indicación del nombre del servidor. Entonces, tanto enlace como enlace se pueden alojar en un servidor en 127.0.0.1, y solo el nombre distingue cómo el servidor enrutará ese mensaje internamente. Es posible que, por razones de seguridad, deba ser enrutado a un servidor separado, donde se almacenarán las claves reales. Es posible que las claves para descifrar ese mensaje no existan en ese servidor de aplicaciones para el usuario, por lo que no se puede descifrar hasta que llegue a la máquina que aloja el sitio de fred.

Además de la necesidad de incluir el nombre de host para resolver el certificado, hay una práctica común relacionada con el uso de SNI, que es importante saber: permite implementar enlace sobre SSL / TLS.

Todos los servidores web populares utilizan SNI:

• lighttpd: enlace
• Apache: enlace
• Nginx: enlace