SNI: alojamiento virtual para HTTPS

Introducción

Alojamiento virtual es la práctica de servir múltiples sitios web en el mismo servidor. Aunque es la norma hoy en día, esto no era posible en los primeros días de HTTP (versiones anteriores a 1.1).

Nota: Aunque esto no es técnicamente correcto, a los efectos de este artículo, "mismo servidor" indica que todos los nombres de dominio apuntan al mismo Dirección IP y el número de puerto.

Originalmente, un servidor solo podía alojar múltiples sitios web en la misma máquina (es decir, bajo la misma dirección IP) siempre que a cada sitio web se le asignara un puerto dedicado. Esta no era una solución ideal porque los navegadores tienen el puerto predeterminado 80 para HTTP, a menos que el usuario especifique uno diferente. Como resultado, la mayoría de los propietarios de sitios web optaron por un servidor dedicado para evitar el riesgo de que los usuarios no recuerden el número de puerto correcto y terminen en un sitio web diferente.

Hospedaje de múltiples sitios en múltiples puertos

Sin embargo, a medida que más usuarios se unieron a la Web y más dispositivos de red comenzaron a aparecer en línea, el número de direcciones IP disponibles comenzó a disminuir a un ritmo alarmante. Este agotamiento anticipado, conocido como Agotamiento del rango de direcciones IPv4, ha impulsado a la industria a diseñar e implementar diversas contramedidas, como IPv6 (Sucesor de IPv4), que puede admitir más direcciones de las que necesitaremos. Desafortunadamente, aunque IPv6 es una solución viable, su adopción ha sido bastante lenta. De acuerdo a Estadísticas de IPv6 de Google, en el momento de escribir este artículo, aproximadamente el 25% de los dispositivos de Internet se implementan a través de IPv6.

El alojamiento virtual también se implementó como una mitigación temprana del problema de agotamiento, con la introducción de Host encabezado en HTTP 1.1. Los navegadores que se comunicaban a través de HTTP 1.1 ahora podían conectarse al puerto de un servidor 80 e incluir el nombre de dominio (p. ej. www.ssl.com) del sitio web que querían visitar en el Host encabezamiento. Independientemente de cuántos sitios aloje un servidor en el mismo puerto, podría usar esta información para identificar el sitio web correcto y devolver su contenido.

Alojamiento de varios sitios en un solo puerto: alojamiento virtual

HTTPS y alojamiento virtual

Sin embargo, numerosos informes publicados sobre vulnerabilidades de red y ataques contra usuarios web han motivado a la industria a comience a alejarse de HTTP inseguro, a su alternativa más segura HTTPS. La amplia adopción de HTTPS ha mejorado la seguridad general del usuario. Sin embargo, sus mejoras adicionales también han aumentado la complejidad general de las comunicaciones web.

En principio, HTTPS es bastante similar a HTTP, con la excepción de que las comunicaciones HTTPS entre navegadores y servidores están cifradas. En resumen, HTTPS requiere que los servidores proporcionen a los navegadores un certificado SSL válido emitido por una entidad de confianza pública. Autoridad certificada (CA), como SSL.com. Un navegador puede usar la clave pública contenida en el certificado para establecer un canal de comunicaciones encriptado con el servidor. Además, se emite un certificado para un nombre de dominio específico, que el navegador comprueba si coincide con el dominio que el usuario deseaba visitar. Por lo tanto, no importa cuántos sitios web aloje el servidor, los navegadores esperan encontrar un certificado SSL válido para el sitio web que han solicitado.

Es posible que el lector atento ya sienta el problema: el navegador requiere el certificado del sitio web correcto para establecer el canal cifrado y enviar el Host encabezado, mientras que el servidor necesita el Host encabezado para localizar el certificado del sitio correcto. Este es un problema clásico del huevo y la gallina.

Nota: Aunque el término alojamiento virtual originalmente fue acuñado para sitios HTTP, también se transfirió a HTTPS. Se refiere a la misma práctica de alojar múltiples sitios web en un solo servidor, independientemente del método real de implementación.

Es evidente que el alojamiento virtual tal como fue concebido para HTTP no funciona para HTTPS, porque los controles de seguridad evitan que los navegadores envíen Host información al servidor. No obstante, con el problema del agotamiento de IPv4 aún sin resolver y la adopción cada vez mayor de tecnologías en la nube (que requieren equilibrio de carga y múltiples servidores backend de conmutación por error), el alojamiento virtual sigue siendo una necesidad.

¿Qué pasa con los certificados multidominio?

Una solución propuesta a este problema es el uso de multidominio o Certificados SAN. Un solo certificado SAN puede proteger cientos de nombres de dominio diferentes, y los navegadores no se quejarán si encuentran el nombre de dominio que están intentando visitar dentro de la lista de dominios del certificado SAN. Una vez configurado el canal cifrado, el navegador puede enviar el Host encabezado al servidor y continuar como en cualquier otro caso. Esta es una gran idea que utiliza una tecnología ya presente y disponible, pero los mismos mecanismos que garantizan la seguridad de los certificados SAN también han introducido algunos efectos secundarios potencialmente indeseables:

Los certificados SAN son una buena herramienta para proteger múltiples dominios propiedad de la misma entidad (persona, empresa u organización), pero no son prácticos de usar en el alojamiento compartido; siempre que un nuevo dominio esté listo para agregarse o eliminarse del certificado, la CA debe emitir un nuevo certificado con la última lista de dominios y volver a implementarlo en todos los dominios.

Además, los certificados SAN solo pueden emitirse como Organización validada (OV) o validada extendida (EV) if todos los dominios pertenecen a la misma organización. Estos niveles de validación se refieren a cantidad y tipos de información del posible propietario del certificado verificada por la CA antes de emitirles el certificado. Se ha demostrado que cuanto mayor es el nivel de validación, más confianza depositan los usuarios en el sitio web y la confianza del usuario puede afectar el reconocimiento de marca y las tasas de conversión.

Finalmente, es bastante común en entornos de alojamiento web compartido que una empresa comparta un servidor con otras empresas u organizaciones (incluso con sus competidores). Dado que los dominios en los certificados SAN se enumeran públicamente, los propietarios de negocios pueden ser reacios a compartir el mismo certificado con compañías de terceros.

Aunque los certificados SAN son herramientas poderosas y versátiles con innumerables aplicaciones, estos problemas han motivado a IETF, el organismo rector de los estándares de Internet, a buscar enfoques mejor adaptados al problema específico de los sitios web HTTPS alojados virtualmente.

Indicación del nombre del servidor al rescate

La solución se implementó en forma de Indicación del nombre del servidor (SNI) extensión de la TLS protocolo (la parte de HTTPS que se ocupa del cifrado).

SNI permite a los navegadores especificar el nombre de dominio al que desean conectarse durante el TLS apretón de manos (la negociación inicial del certificado con el servidor). Como consecuencia, los sitios web pueden usar sus propios certificados SSL mientras aún están alojados en una dirección IP y un puerto compartidos, porque los servidores HTTPS pueden usar la información SNI para identificar la cadena de certificados adecuada requerida para establecer la conexión.

Posteriormente, cuando se ha configurado el canal de comunicaciones encriptado, el navegador puede proceder a incluir el nombre de dominio del sitio web en el Host encabezado y continuar como lo haría normalmente. Esencialmente, SNI realiza la misma función que HTTP Host encabezado durante la creación de la conexión cifrada.

Alojamiento virtual de sitios web HTTPS con SNI

Este sencillo truco finalmente permitió a los servidores alojar varios sitios web HTTPS en el mismo puerto. Sin embargo, como ocurre con la mayoría de las tecnologías de Internet, SNI tiene algunas limitaciones.

Problemas de soporte de SNI

Aunque SNI está bastante maduro desde que se redactó por primera vez en 1999, todavía hay algunos navegadores heredados (IE en Windows XP) y sistemas operativos (versiones de Android <= 2.3) que no lo admiten. Para obtener una lista completa de los navegadores y sistemas operativos que admiten SNI, consulte Esta mesa.

Si bien las cuotas de mercado de los navegadores que no admiten SNI (y, por extensión, las ocurrencias de esto) son minúsculas en comparación con los navegadores modernos, si un navegador no reconoce SNI, recurrirá al certificado SSL predeterminado y potencialmente error de falta de coincidencia de nombre común.

Muchas compañías, como Google, implementan SNI para los clientes que lo admiten y recurren a los certificados SAN para los casos excepcionales que no lo hacen. Naturalmente, se espera que este problema disminuya a medida que más y más usuarios y propietarios de negocios actualicen sus sistemas a tecnologías modernas.

SNI Preocupaciones de privacidad

La versión estable actual de TLS (versión 1.2) transmite la parte inicial del protocolo de enlace y, por extensión, la información SNI, sin cifrar. En consecuencia, un atacante de red puede descubrir el historial web de un usuario, a pesar de que las propias comunicaciones web estén completamente encriptadas.

Varios proveedores de servicios en la nube, como Amazon o Google, han permitido una solución (sucia) conocida como frente de dominio. El frente de dominio puede evitar la divulgación del historial web porque oculta la información de SNI al usar el nombre de host del proveedor de la nube en el TLS negociación y el sitio de destino en el encabezado HTTP. Sin embargo, este método ya no es viable, ya que Google y Amazon han declarado públicamente que soporte deshabilitado para el frente de dominio en sus servicios a partir de abril de 2018.

Afortunadamente, se ha propuesto una solución más sistémica como borrador experimental detallando el SNI cifrado (ESNI) extensión para el más nuevo TLS versión 1.3. ESNI cifra la información de SNI, mitigando así todas las preocupaciones de privacidad. Desafortunadamente, TLS 1.3 aún no está ampliamente adoptado por la industria, aunque TLS 1.3 se está convirtiendo lentamente en el protocolo de seguridad de red de facto. Esté atento a futuros artículos sobre el estado de ESNI y la privacidad de HTTPS y TLS.

Conclusión

En resumen, con SNI puede alojar millones de sitios web HTTPS en un solo servidor. Sin embargo, dependiendo de su caso individual, un certificado SAN podría funcionar mejor para usted. Las preocupaciones de privacidad sobre SNI aún existen, aunque también existe una posible solución con ESNI. En cualquier caso, utilizando uno o una combinación de estos dos métodos, puede implementar fácilmente alojamiento virtual para todos sus sitios web con un mínimo esfuerzo.


Si tiene más preguntas sobre SNI o no sabe cómo elegir entre SAN y SNI, siempre estaremos encantados de responder a todas las preguntas de nuestros clientes sobre sus PKI necesidades. Solo envíenos un correo electrónico a support@ssl.com Y un experto te ayudará.

Suscríbase al boletín de SSL.com

No te pierdas los nuevos artículos y actualizaciones de SSL.com

Manténgase informado y seguro

SSL.com es líder mundial en ciberseguridad, PKI y certificados digitales. Regístrese para recibir las últimas noticias, consejos y anuncios de productos de la industria de SSL.com.

Nos encantaría recibir tus comentarios

Responda nuestra encuesta y háganos saber lo que piensa sobre su compra reciente.