SNI (Indicación de Nombre de Servidor)

SNI (Server Name Indication) es una extensión de TLS que permite a un cliente indicar el nombre de host al que intenta conectarse durante el handshake de TLS, lo que permite a los proxies enrutar o terminar correctamente las conexiones TLS para múltiples dominios alojados en una única dirección IP.

Antes de SNI, un servidor requería una dirección IP única para cada certificado SSL si se alojaban múltiples sitios web seguros en el mismo servidor. Esta limitación surgía porque el handshake de TLS ocurría antes de que se enviara el encabezado HTTP Host, impidiendo que el servidor supiera qué certificado presentar. SNI, especificado en RFC 6066, resuelve esto incluyendo el nombre de host deseado en el mensaje ClientHello, permitiendo al servidor (o proxy) seleccionar el certificado y la configuración correctos.

Cómo funciona SNI

El cliente incluye el nombre de host de destino en el campo extension_data de la extensión server_name dentro del mensaje ClientHello. Esto ocurre antes de que se intercambie cualquier dato cifrado y antes de que el servidor presente su certificado.

ClientHello
  Version: TLS 1.2
  Random: ...
  Session ID: ...
  Cipher Suites: ...
  Extensions:
    ...
    Server Name (SNI)
      Server Name Type: host_name (0)
      Server Name: example.com
    ...

El servidor o un proxy intermediario recibe este ClientHello y puede extraer el nombre de host example.com. Esta información se utiliza luego para determinar qué certificado TLS presentar y cómo enrutar o procesar la conexión subsiguiente.

Gestión de SNI por parte de los Proxies

Los proxies interactúan con SNI de manera diferente según su tipo, modo de operación y si realizan terminación o paso de TLS.

Proxies Transparentes

Un proxy transparente intercepta el tráfico sin que el cliente esté explícitamente configurado para usarlo. Para el tráfico TLS, un proxy transparente a menudo opera en la Capa 4 (TCP). Típicamente, reenvía el flujo TCP sin procesar, incluyendo el mensaje ClientHello con SNI, directamente al servidor de destino.

• Visibilidad de SNI: Un proxy transparente puede inspeccionar el mensaje ClientHello para extraer el nombre de host SNI. Esto permite reglas básicas de enrutamiento, registro o filtrado basadas en el dominio de destino, incluso si la carga útil en sí permanece cifrada.
• Terminación de TLS: Los proxies transparentes generalmente no terminan TLS para el cliente a menos que estén específicamente configurados para inspección profunda de paquetes (DPI) u operaciones de man-in-the-middle (MITM), lo que requiere la confianza del cliente en la CA raíz del proxy. En una configuración transparente estándar, el proxy pasa el ClientHello al servidor de origen, que luego realiza el handshake de TLS directamente con el cliente.

Proxies Adelantados (Forward Proxies)

Un proxy adelantado actúa como intermediario para los clientes que solicitan recursos de servidores externos. Los clientes están explícitamente configurados para usar un proxy adelantado.

Método CONNECT

Para el tráfico HTTPS, los clientes suelen usar el método HTTP CONNECT para instruir al proxy adelantado a establecer un túnel TCP al servidor de destino.

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Connection: Keep-Alive

Después de que la solicitud CONNECT tiene éxito (el proxy responde con HTTP/1.1 200 Connection established), el cliente inicia el handshake de TLS directamente con el servidor de destino a través del túnel establecido.

• Visibilidad de SNI (sin intercepción): En este modo, el proxy adelantado generalmente no procesa el valor SNI del mensaje ClientHello porque simplemente está retransmitiendo el flujo TCP cifrado sin procesar. La solicitud CONNECT proporciona el nombre de host de destino, que el proxy utiliza para el enrutamiento.
• Terminación de TLS: El proxy no termina TLS; el handshake de TLS ocurre de extremo a extremo entre el cliente y el servidor de origen.

Intercepción de TLS (MITM)

Algunos proxies adelantados están configurados para la intercepción de TLS (también conocida como inspección SSL o proxy MITM). Esto implica que el proxy termina la conexión TLS del cliente y establece una nueva conexión TLS con el servidor de origen.

1. El cliente inicia el handshake de TLS con el proxy: El cliente envía un ClientHello al proxy.
2. El proxy extrae SNI: El proxy lee el nombre de host SNI del ClientHello.
3. El proxy genera el certificado: Usando su propio certificado de CA (confiado por el cliente), el proxy genera dinámicamente un certificado de servidor para el nombre de host SNI.
4. El proxy completa el handshake con el cliente: El proxy presenta el certificado generado al cliente.
5. El proxy establece una nueva conexión TLS con el origen: El proxy inicia un nuevo handshake de TLS con el servidor de origen real, utilizando el nombre de host SNI extraído en su ClientHello.
6. El proxy descifra/vuelve a cifrar el tráfico: El proxy descifra el tráfico del cliente, lo inspecciona y luego lo vuelve a cifrar antes de enviarlo al origen, y viceversa.

• Uso de SNI: SNI es crucial para la intercepción de TLS. El proxy utiliza el valor SNI para:
  • Determinar qué nombre de host suplantar para el cliente.
  • Determinar qué nombre de host solicitar al servidor de origen.
• Implicaciones de seguridad: Requiere que el cliente confíe en la CA raíz del proxy. Este modo permite al proxy una visibilidad completa del tráfico cifrado.

Proxies Inversos (Reverse Proxies)

Un proxy inverso se sitúa delante de uno o más servidores web, dirigiendo las solicitudes del cliente al servidor backend apropiado. Los clientes se conectan al proxy inverso, sin ser conscientes de la arquitectura del backend.

• Uso de SNI: Cuando un cliente inicia un handshake de TLS con el proxy inverso, el proxy recibe el mensaje ClientHello que contiene el nombre de host SNI. El proxy inverso utiliza este valor SNI para:
  • Seleccionar el certificado de servidor correcto para presentar al cliente si aloja múltiples dominios.
  • Enrutar la solicitud al servidor backend o pool de aplicaciones apropiado.
  • Aplicar políticas específicas del dominio (por ejemplo, reglas WAF, almacenamiento en caché, equilibrio de carga).
• Terminación de TLS: Los proxies inversos casi siempre terminan las conexiones TLS de los clientes. Descifran el tráfico, lo procesan y luego pueden volver a cifrarlo para la comunicación con los servidores backend (re-cifrado o TLS de backend).

Ejemplo: Proxy Inverso Nginx con SNI

http {
    # Servidor predeterminado para solicitudes sin SNI o para SNI desconocido
    server {
        listen 443 ssl default_server;
        server_name _; # Catch-all
        ssl_certificate /etc/nginx/ssl/default.crt;
        ssl_certificate_key /etc/nginx/ssl/default.key;
        return 404;
    }

    # Backend para example.com
    server {
        listen 443 ssl;
        server_name example.com;
        ssl_certificate /etc/nginx/ssl/example.com.crt;
        ssl_certificate_key /etc/nginx/ssl/example.com.key;
        location / {
            proxy_pass https://backend_example_com;
            proxy_ssl_server_name on; # Pasar SNI al backend
        }
    }

    # Backend para api.example.com
    server {
        listen 443 ssl;
        server_name api.example.com;
        ssl_certificate /etc/nginx/ssl/api.example.com.crt;
        ssl_certificate_key /etc/nginx/ssl/api.example.com.key;
        location / {
            proxy_pass https://backend_api_example_com;
            proxy_ssl_server_name on; # Pasar SNI al backend
        }
    }
}

En esta configuración de Nginx, la directiva server_name coincide con el SNI presentado por el cliente. Nginx luego usa el ssl_certificate correspondiente y enruta la solicitud al backend proxy_pass especificado. proxy_ssl_server_name on asegura que Nginx incluya el nombre de host SNI al establecer una nueva conexión TLS con el backend.

SNI y Proxies de Capa 4 vs. Capa 7

La distinción entre proxies de Capa 4 (TCP) y Capa 7 (Aplicación) también influye en el manejo de SNI.

• Proxies de Capa 4: Operan a nivel TCP. Pueden inspeccionar el paquete ClientHello para extraer SNI sin descifrar todo el flujo TLS. Esto permite el enrutamiento o filtrado basado en SNI antes de que se complete el handshake de TLS, sin necesidad de terminar TLS. HAProxy en modo TCP puede realizar esto.

  listen https_frontend bind *:443 mode tcp tcp-request inspect-delay 5s tcp-request content accept if { req_ssl_hello_type 1 } tcp-request content track-sc0 src # Enrutar basado en SNI use_backend backend_example_com if { req_ssl_sni -i example.com } use_backend backend_api_example_com if { req_ssl_sni -i api.example.com } default_backend backend_default
  Esta configuración de HAProxy utiliza req_ssl_sni para inspeccionar el SNI del ClientHello y enrutar la conexión TCP en consecuencia, sin terminar TLS por sí mismo.

• Proxies de Capa 7: Operan en la capa de aplicación (por ejemplo, HTTP/HTTPS). Deben terminar TLS para acceder a los encabezados de la capa de aplicación (como HTTP Host, ruta URL, etc.). Al terminar TLS, utilizan el SNI del ClientHello inicial para seleccionar el certificado de servidor correcto y luego proceden a procesar la solicitud HTTP descifrada. Los proxies inversos son típicamente proxies L7. Los proxies adelantados que realizan intercepción de TLS también son L7.

Comparación: Modos de Manejo de SNI por Proxy

Consideraciones de Seguridad y Privacidad

SNI, por diseño, se transmite en texto claro dentro del mensaje ClientHello. Esto significa que los intermediarios de red, incluidos los proxies y los ISP, pueden observar a qué nombre de host un cliente intenta conectarse, incluso si el resto de la comunicación TLS está cifrada.

Esta exposición en texto claro tiene implicaciones de privacidad. Para abordar esto, el IETF ha desarrollado Encrypted SNI (ESNI), que está evolucionando hacia Encrypted Client Hello (ECH). ESNI/ECH cifra la extensión Server Name dentro del mensaje ClientHello, haciéndola opaca para los observadores pasivos.

• Impacto en los Proxies: ESNI/ECH cambia significativamente la forma en que operan los proxies (especialmente los proxies L4 o aquellos que realizan enrutamiento basado en SNI sin terminación TLS completa). Si el SNI está cifrado, el proxy no puede usarlo para decisiones de enrutamiento en texto claro. Los proxies capaces de soportar ESNI/ECH necesitarían participar en el intercambio de claves o depender de otros mecanismos (por ejemplo, dirección IP, DNS) para el enrutamiento inicial, o descifrar ECH si son el punto final ECH previsto. Para los proxies que terminan TLS (como los proxies inversos o los proxies adelantados MITM), aún necesitarían descifrar el ECH para conocer el nombre de host previsto para la selección y el enrutamiento del certificado.