Qué es Server Name Indication, SNI; indicación de nombre de servidor.Me encontraba elaborando unos post para la empresa donde laboro sobre Certificados SSL, cuando me encontré con este término, que la verdad, no tenía muy claro.La indicación de nombre del servidor (SNI) le permite al servidor alojar de forma segura varios certificados TLS para múltiples sitios, todo bajo una sola dirección IP. Agrega el nombre de host del servidor (sitio web) en el protocolo de enlace TLS como una extensión en el mensaje CLIENT HELLO. De esta manera, el servidor sabe qué sitio web presentar cuando se usan IP compartidas. Normalmente, las empresas que usan IP compartidas en un servidor son empresas de alojamiento y enfrentan el problema cotidiano: «¿cómo puedo hacer que mi servidor seleccione y presente el certificado correcto?»
Aquí hay una mirada más cercana al problema. En un sitio HTTP, un servidor utiliza encabezados HTTP HOST para determinar qué sitio web HTTP debe presentar. Sin embargo, cuando se usa TLS (el protocolo detrás de HTTPS), la sesión segura debe crearse antes de poder establecer la sesión HTTP y, hasta entonces, no hay ningún encabezado de host disponible.
Así que aquí está el dilema: con HTTPS, el protocolo de enlace TLS en el navegador no se puede completar sin un certificado TLS en primer lugar, pero el servidor no sabe qué certificado presentar, porque no puede acceder al encabezado del host.
¿Qué es SNI y cómo puede ayudar?
La indicación de nombre del servidor (SNI) es una extensión del protocolo TLS. El cliente especifica a qué nombre de host desea conectarse utilizando la extensión SNI en el protocolo de enlace TLS. Esto permite que un servidor (por ejemplo, Apache, Nginx, o un equilibrador de carga como HAProxy) seleccione la clave privada correspondiente y la cadena de certificados que se requieren para establecer la conexión desde una lista o base de datos mientras se alojan todos los certificados en una sola dirección IP.
Cuando se usa SNI, el nombre de host del servidor se incluye en el protocolo de enlace TLS, que permite que los sitios web de HTTPS tengan Certificados TLS únicos, incluso si están en una dirección IP compartida.
Usted puede preguntarse por qué esto es tan importante. ¿Por qué necesitamos una manera de admitir certificados únicos para IP compartidas?
El dilema de la escasez de IPv4
El Protocolo de Internet versión 4 (IPv4) tiene aproximadamente 4 mil millones de direcciones IP . Pero, ya hay más de 4 mil millones de computadoras conectadas a Internet en todo el mundo, por lo que estamos enfrentando una escasez de direcciones IPv4. El Protocolo de Internet versión 6 (IPv6) debería solucionar este problema, ofreciendo trillones de direcciones, pero todavía hay algunos equipos de red existentes que no son compatibles con IPv6. Se estima que el 90% de los sistemas operativos comunes para teléfonos móviles, PC y servidores pueden admitir IPv6 . Por lo tanto, estamos muy cerca de ser totalmente compatibles con IPv6, pero para los pocos sistemas heredados que aún requieren IP compartidas, podría ser necesario adoptar un enfoque dual: SNI para IPv4 para los pocos navegadores heredados y direcciones IP únicas para todos los dominios a través de IPv6 para el resto.
Cómo SNI puede ayudarlo y resolver la escasez de IPv4
Con SNI, el servidor puede alojar de manera segura múltiples Certificados TLS para múltiples sitios, todos bajo una sola dirección IP.
De esa manera, se necesitan y utilizan menos direcciones IP, lo que hace que las direcciones IP estén más disponibles. Aunque eventualmente nos quedaremos sin direcciones IPv4, el proceso se ralentiza y les da a las personas más tiempo para actualizar a los navegadores, enrutadores y servidores compatibles.
SNI también hace que sea mucho más fácil configurar y administrar múltiples sitios web, ya que todos pueden apuntar a la misma dirección IP. Además, tiene la ventaja de que el simple hecho de escanear una dirección IP no revela el certificado, lo que aumenta la seguridad general.
¿Existen desventajas para SNI?
Está claro que SNI es una gran solución para IP compartidas, pero aún queda una pequeña desventaja; solo afecta a una proporción muy pequeña de usuarios de Internet, aquellos que usan navegadores o sistemas operativos heredados.
SNI no es compatible con los navegadores y servidores web heredados. Los navegadores modernos (generalmente de menos de 6 años) pueden manejar bien el SNI, pero los dos navegadores más antiguos que luchan con el SNI son Internet Explorer en Windows XP (o más antiguo, que se estima que se usó para acceder a sitios web en un 3.18% de usuarios en abril de 2018 ) y Android 2.3 y versiones posteriores (utilizado por aproximadamente el 0,3% de los usuarios de Android ). Si el navegador o el sistema operativo no son compatibles con SNI, el protocolo de enlace elegirá el certificado predeterminado, lo que puede provocar un error de coincidencia de nombre común .
El uso de XP y Android pre-2.3 continuará cayendo y, por lo tanto, los problemas de compatibilidad serán cada vez menos importantes. También es bueno recordar que Windows XP no es compatible con TLS 1.1 o TLS 1.2 y con los próximos requisitos de PCI , los usuarios ya no podrán visitar muchos sitios de todos modos.
El uso de estos navegadores está en declive y seguirá siéndolo, pero significa que un porcentaje de usuarios web todavía tendrá dificultades para recibir un sitio web HTTPS, si se entrega a través de SNI.
Una forma de solucionar este problema es usar Multi-Domain TLS como el certificado predeterminado para que pueda enumerar todos los dominios en la IP compartida en un certificado (más sobre esto más adelante).
Otro aspecto a destacar sobre SNI es que la conexión se inicia sin cifrar en TLS 1.2, lo que expone a los clientes a la censura y la vigilancia. TLS 1.3 resolvió este problema, pero aún no está completamente soportado, así que asegúrese de estar listo para saltar a TLS 1.3 tan pronto como se adopte ampliamente .
Estos desafíos no son suficientes para degradar la belleza de SNI. Le recomendamos que utilice SNI siempre que pueda.
Las diferencias entre SNI y SANs
Un certificado de múltiples dominios (a veces denominado certificado SAN) es otra forma de lidiar con el agotamiento de IPv4. Los certificados TLS de varios dominios no tienen las desventajas de la compatibilidad con los navegadores o servidores como SNI. Funcionan como cualquier otro certificado TLS y cubren hasta 200 dominios en un solo certificado. SNI, por otro lado, puede alojar fácilmente millones de dominios en la misma dirección IP.
¿Por qué no usamos certificados de dominio múltiple?
En un certificado de varios dominios, todos los dominios deben agregarse al certificado. Estos dominios se enumeran como Nombres alternativos del sujeto, o SAN. Si es necesario agregar o eliminar una SAN, o si se debe revocar o renovar un certificado, el certificado debe ser reemplazado y redistribuido para todos los dominios. También es visible quien comparte el mismo certificado. Por ejemplo, para las empresas que obtienen sus certificados de una empresa de alojamiento que utiliza Certificados de dominio múltiple para sus clientes, es posible que a esa empresa no le guste más compartir un certificado con su competidor.
También hace que el certificado sea más grande, y mientras más nombres se agreguen, más grande se vuelve el certificado. Si bien solo estamos hablando de kilobytes, esta información debe descargarse antes de poder descargar cualquier otra información en los sitios. Esencialmente, bloquea el sitio para que no se cargue durante uno o más milisegundos, dependiendo de la conexión a Internet, lo que no supone un gran retraso, pero cuando la competencia para clasificar en Google es escasa, unos pocos milisegundos en la velocidad de carga de la página podrían significar mucho.
Otro inconveniente importante es que los certificados de múltiples dominios no pueden admitir SAN OV (organización validada) o EV (validación extendida) cuando se comparten entre organizaciones. Por ejemplo, en el escenario de la empresa de hospedaje mencionado anteriormente con dominios de varias compañías que figuran como SAN en un solo certificado, esos dominios serían de nivel DV (dominio validado). Estos niveles de validación se refieren a la cantidad de información que se verifica antes de que se emita el certificado. DV significa que el propietario del sitio demostró un control administrativo sobre el dominio, mientras que OV y EV también verifican la información sobre la identidad del propietario del sitio (por ejemplo, existencia legal y operativa).
Los usuarios más conocidos de certificados Multi-Domain incluyen Cloudflare y Google. Google solo lo usa para clientes más antiguos que no admiten SNI.
¿Qué haré entonces? ¿Debo usar SNI o certificados de dominio múltiple?
En general, mientras que los Certificados de múltiples dominios y SNI logran lo mismo, es decir, reduciendo la cantidad de direcciones IPv4 necesarias, lo logran de una manera opuesta:
SNI significa que puede tener certificados únicos para cada dominio (es decir, muchos certificados) mientras esos dominios comparten la misma IP. Por otro lado, los certificados de múltiples dominios simplemente usan un certificado para muchos dominios, lo que a su vez también significa una IP para muchos dominios.
Queda claro que hay un lugar para los Certificados tanto de SNI como de dominios múltiples , ya sea solos o en combinación. Con estas soluciones, puede continuar hospedando certificados para clientes sin tener que preocuparse por las direcciones IP dedicadas o la compatibilidad.
Consultar también:Cómo obtener un certificado SSL GRATUITO usando Let’s Encrypt para Apache; Porqué caducan los certificados SSL, cual es la razón para que venzan o tengan fecha de vencimiento; quienes emiten los certificados SSL
This post is also available in:
Español
