Resumen

  • SNI incluyó el nombre DNS de destino en el ClientHello, permitiendo que un servidor con una dirección compartida eligiera el certificado y el servicio correctos antes de recibir HTTP cifrado.
  • El nombre orienta una selección, no demuestra identidad ni permiso. Al viajar antes del cifrado quedó expuesto; ECH conserva un nombre exterior público y protege el destino real en un ClientHello interior.

La llave correcta dependía de un mensaje aún cerrado

Un edificio aloja varias oficinas, pero tiene una sola puerta. Antes de dejar entrar al visitante, el recepcionista debe mostrar la credencial de la oficina correcta. El visitante ha escrito el nombre de esa oficina dentro de un mensaje que solo podrá abrirse después de verificar la credencial. Ninguno de los dos pasos puede esperar al otro.

TLS heredó ese dilema al encontrarse con el alojamiento virtual. La RFC 2246 sitúa la autenticación y la creación de claves antes de los datos de aplicación protegidos. El nombre HTTP que diferenciaba los sitios compartidos estaba, por tanto, detrás de la decisión de certificado que debía orientar.

La RFC 3546 introdujo en 2003 Server Name Indication. El cliente declaró el nombre del servidor en su ClientHello y el extremo TLS pudo escoger una configuración adecuada para ese sitio.

No fue solo un campo nuevo. Fue una reordenación de información: sacar el mínimo dato necesario de la petición futura y colocarlo en el momento en que el servidor todavía podía actuar.

De una identidad por dirección a varias identidades por entrada

HTTP podía repartir sitios por nombre una vez leída la petición. HTTPS requería presentar antes una identidad criptográfica. Sin SNI, muchos operadores asignaban una dirección a cada identidad, reunían numerosos nombres en un certificado o entregaban una configuración predeterminada que no siempre coincidía.

Estas salidas mezclaban problemas distintos. La dirección servía para encaminar paquetes; el nombre identificaba un servicio; el certificado respaldaba una identidad. SNI añadió el nombre a la negociación y permitió mantener esas funciones separadas.

Un mismo punto de acceso pudo atender sitios con certificados y políticas diferentes. Ese detalle sostuvo el crecimiento del alojamiento compartido seguro, los CDN y las pasarelas de nube. La dirección seguía llevando al cliente hasta el frente común; el nombre indicaba qué puerta interna debía abrirse.

El nombre exterior no firma el contenido

La RFC 6066 consolidó el mecanismo y definió host_name dentro de server_name. Cuando un servidor no reconoce el nombre, puede abortar con unrecognized_name o continuar según su configuración.

Esa flexibilidad marca el límite semántico. SNI no prueba que el cliente tenga derecho a usar el sitio. Tampoco valida DNS ni convierte en correcto el certificado seleccionado. El cliente aún debe verificar que el certificado corresponde al nombre; la aplicación debe autorizar la acción; la autoridad HTTP posterior debe tratarse con coherencia.

Es una etiqueta de distribución, no una firma. Confundir ambas cosas permite que un certificado por defecto demasiado amplio, una ruta equivocada o un salto entre inquilinos parezcan decisiones de seguridad legítimas.

La pista que también podía leer la red

El ClientHello inicial llega antes de que el apretón de manos produzca las claves. Ocultar el nombre con esas claves y usarlo para elegirlas sería circular. Por eso el SNI original quedó en claro.

La red podía no conocer la página visitada ni su contenido y, sin embargo, aprender el dominio. La RFC 8744 recogió tanto la pérdida de privacidad como los usos operativos construidos sobre el nombre visible: clasificación, filtrado, política y diagnóstico.

TLS 1.3, definido en la RFC 8446, cifró una parte mayor del apretón de manos después del ServerHello. Pero la primera oferta del cliente seguía precediendo esa protección. El problema no era una versión antigua del cifrado, sino el orden de dependencia.

Cuando la observación se convierte en infraestructura

Los campos visibles atraen consumidores. Un CDN enruta por SNI; una herramienta de observabilidad agrega por dominio; un cortafuegos decide; un proveedor registra. Con el tiempo, ocultar el nombre deja de ser un cambio local, porque otros sistemas lo han convertido en entrada.

Ahí aparece un bloqueo tecnológico y político. El frente TLS necesita algún dato público para alcanzar al servicio capaz de descifrar el destino privado. Los intermediarios, a la vez, pueden reclamar la visibilidad histórica para sus controles. Resolver la privacidad exige separar qué información es indispensable de cuál simplemente se volvió cómoda.

ECH mantiene una fachada común y protege la puerta interior

La RFC 9849 define Encrypted ClientHello. El cliente crea un ClientHello interior con el nombre sensible y lo cifra dentro de otro exterior. El exterior usa un nombre público para llegar a una infraestructura que conoce ECH; el nombre de origen queda reservado al interior protegido.

No todo desaparece. La dirección IP sigue a la vista y el nombre público también. La mejora consiste en que ambos pueden describir una fachada compartida en lugar de revelar necesariamente el sitio final.

El protocolo distingue aceptación, rechazo y reintento. El cliente obtiene confirmación protegida de que ECH fue aceptado, y un servidor que no puede descifrar puede ofrecer configuraciones nuevas. El nombre exterior no se convierte por accidente en la autoridad solicitada.

ECH responde al mismo problema de orden con una frontera más fina: la red conoce lo necesario para llegar al protector; el protector conoce lo necesario para seleccionar el destino.

El efecto duradero de colocar un nombre temprano

SNI redujo la necesidad de asociar una dirección a cada identidad HTTPS. Permitió que el modelo económico del alojamiento por nombre conviviera con la secuencia criptográfica de TLS y contribuyó a normalizar HTTPS compartido.

Nunca autenticó al cliente, otorgó permisos ni ocultó el dominio. Su utilidad y su exposición nacieron de la misma ubicación temporal. ECH no borra los metadatos; limita la precisión que debe cruzar la parte pública de la ruta.

La lección histórica es que el orden de un protocolo distribuye poder. Quien necesita un dato antes del cifrado también crea una oportunidad para que otros lo observen. Cambiar esa distribución requiere una ruta pública mínima y una negativa clara a tratarla como destino privado.

Fuentes y límites de la evidencia

La base normativa está en las RFC 2246, RFC 3546, RFC 6066, RFC 8446, RFC 8744 y RFC 9849. Las conclusiones sobre economía de alojamiento, incentivos de inspección y dependencia son inferencias de la secuencia de mensajes, no mediciones de un operador concreto.