Adiós, ESNI, ¡hola, ECH!

La mayor parte de la comunicación a través de la red moderna está encriptada para garantizar que su contenido sea inteligible solo de extremo a extremo, es decir, entre el cliente y el servidor. Sin embargo, la encriptación requiere una clave, por lo que estos puntos de conexión deben acordar una clave de cifrado sin revelarla a posibles atacantes. El protocolo más utilizado para esta tarea, llamada intercambio de claves, es el protocolo de enlace de seguridad de la capa de transporte (TLS).

En este artículo profundizaremos en Encrypted Client Hello (ECH), una nueva extensión para el protocolo TLS que mejora significativamente la privacidad de este importante protocolo de Internet. Hoy en día, hay una serie de parámetros sensibles de carácter privado de la conexión TLS que se gestionan sin cifrar, lo que deja al acceso de los observadores de la red un tesoro de metadatos, tales como las identidades de los puntos de conexión y la forma en la que usan la conexión, entre otros.

ECH encripta el protocolo de enlace completo para que estos metadatos se mantengan en secreto. Sin duda, esto corrige un antiguo fallo de privacidad al proteger la indicación del nombre del servidor (SNI) contra los intrusos de la red. La encriptación de la clave de la SNI es importante porque es la indicación más clara sobre el servidor con el que se está comunicando un cliente determinado. Sin embargo, y tal vez más importante, ECH también sienta las bases para añadir futuras funciones de seguridad y mejoras de rendimiento al protocolo TLS, minimizando al mismo tiempo su impacto en la privacidad de los usuarios finales.

ECH es producto de una estrecha colaboración, facilitada por el IETF (Internet Engineering Task Force), entre académicos y líderes de la industria tecnológica, incluido Cloudflare, nuestros amigos de Fastly y Mozilla (ambas afiliaciones de los coautores de la norma) y muchos otros. Esta función representa una actualización significativa del protocolo TLS, que se basa en tecnologías de vanguardia, como el DNS mediante HTTPS, que solo ahora están empezando a adquirir relevancia. Como tal, el protocolo no está listo aún para su implementación en Internet. El propósito de este artículo es ofrecer una indicación del camino hacia la encriptación total del protocolo de enlace.

La historia del protocolo TLS es la historia de Internet. A medida que ha crecido nuestra dependencia de la red, ha ido evolucionado el protocolo para abordar los requisitos operacionales, los casos de uso y los modelos de amenaza en constante cambio. El cliente y el servidor no se limitan a intercambiar una clave: gestionan una amplia variedad de funciones y parámetros, como el método exacto de intercambio de claves, el algoritmo de cifrado, quién se autentica y cómo, qué protocolo de capa de aplicación utilizar después del protocolo de enlace y muchísimas otras más. Todos estos parámetros afectan a las propiedades de seguridad del canal de comunicación de una manera u otra.

La SNI es un ejemplo perfecto de un parámetro que impacta en la seguridad del canal. El cliente utiliza la extensión de la SNI para indicar al servidor a qué sitio web quiere llegar. Esta función es esencial para la red moderna, ya que hoy en día es común que muchos servidores de origen se encuentren detrás de un único operador TLS. En este escenario, el operador utiliza la SNI para determinar qué servidor de origen autentificará la conexión. Sin él, el operador no tendría forma de saber qué certificado TLS presentar al cliente. El problema es que la SNI identifica el servidor de origen al que el cliente quiere conectarse, lo que permite potencialmente a los intrusos inferir mucha información sobre su comunicación. (Por supuesto, hay otras maneras de que un observador de la red identifique el origen, por ejemplo, la dirección IP del origen. Pero la colocación con otros orígenes en la misma dirección IP dificulta mucho más usar esta métrica para determinar el origen que simplemente inspeccionar la SNI.)

Aunque la protección de la SNI es precisamente el motor de ECH, no es de ninguna manera el único parámetro del protocolo sensible de carácter privado que el cliente y el servidor gestionan. Otro es la extensión ALPN, que se utiliza para decidir qué protocolo de capa de aplicación utilizar una vez que se establece la conexión TLS. El cliente envía la lista de aplicaciones que admite, ya sea HTTPS, correo electrónico, mensajería instantánea o el sinfín de aplicaciones que usan TLS para la seguridad del transporte. Por su parte, el servidor selecciona una de ellas y envía su selección al cliente. Al hacerlo, el cliente y el servidor filtran a la red una clara señal de sus capacidades y el posible uso de la conexión.

Algunas funciones son tan sensibles a la privacidad que su inclusión en el protocolo de enlace está totalmente descartada. Una idea que se ha planteado es reemplazar el intercambio de claves en el núcleo del protocolo TLS por el intercambio de claves autenticadas por contraseña (PAKE). Esto permitiría que la autenticación por contraseña se utilice junto con (o en lugar de) la autenticación mediante certificado, lo que hace que el protocolo TLS sea más sólido y adecuado para una gama más amplia de aplicaciones. La cuestión de la privacidad en este caso es análoga a la de la SNI: los servidores suelen asociar a cada cliente un identificador único (por ejemplo, un nombre de usuario o una dirección de correo electrónico) que se utiliza para recuperar las credenciales del cliente. El cliente debe, de alguna manera, transmitir esta identidad al servidor durante el transcurso del protocolo. Si se envía sin cifrar, esta información de identificación personal sería fácilmente accesible para cualquier observador de la red.

Un factor necesario para hacer frente a todos estos fallos de privacidad es la encriptación del protocolo de enlace, es decir, el cifrado de los mensajes del protocolo además de los datos de la aplicación. Parece muy sencillo, pero esta solución plantea otro problema: ¿cómo eligen el cliente y el servidor una clave de cifrado si, después de todo, el protocolo es en sí mismo un medio para intercambiar una clave? Sin duda, algunos parámetros deben enviarse cifrados. Por lo tanto, el objetivo de ECH es encriptar todos los parámetros del protocolo de enlace, excepto los que son esenciales para completar el intercambio de claves.

Conocer un poco la historia de la encriptación del protocolo de enlace en TLS te ayudará a entender cómo funciona ECH y las decisiones de diseño que lo sustentan.

TLS no tenía encriptación del protocolo antes de la última versión, TLS 1.3. Tras las revelaciones de Snowden en 2013, la comunidad del IETF comenzó a considerar formas de contrarrestar la amenaza que la vigilancia masiva suponía para la red de Internet pública. Cuando se inició el proceso de estandarización de la versión TLS 1.3 en 2014, uno de sus objetivos de diseño era encriptar el protocolo de enlace lo máximo posible. Desafortunadamente, el estándar final no incluye la encriptación completa del protocolo de enlace, y varios parámetros, incluida la SNI, todavía se envían sin cifrar. Echemos un vistazo al porqué.

La dinámica del protocolo TLS 1.3 se ilustra en el diagrama 1. La encriptación del protocolo comienza tan pronto como el cliente y el servidor generan una nueva clave secreta compartida. Para ello, el cliente envía una clave compartida en su mensaje ClientHello, y el servidor responde en su mensaje ServerHello con su propia clave compartida. Tras el intercambio de estas claves, el cliente y el servidor pueden derivar una clave secreta compartida. Cada mensaje del protocolo posterior se encripta utilizando la clave de tráfico del protocolo que procede de la clave secreta compartida. Los datos de la aplicación se cifran utilizando una clave diferente, llamada clave de tráfico de la aplicación, que también procede del secreto compartido. Estas claves derivadas tienen diferentes propiedades de seguridad. Para resaltarlo, se muestra con diferentes colores.

El primer mensaje del protocolo de enlace que se cifra es el EncryptedExtensions del servidor. El propósito de este mensaje es proteger los parámetros confidenciales del protocolo de enlace del servidor, incluida la extensión ALPN del servidor, que contiene la aplicación seleccionada de la lista ALPN del cliente. Los parámetros de intercambio de claves se envían sin cifrar en los mensajes ClientHello y ServerHello.

Diagrama 1: Protocolo de enlace TLS 1.3.‌‌

Todos los parámetros del protocolo de enlace, confidenciales o no, se envían en el mensaje ClientHello. Si te fijas en el diagrama 1, podrías pensar en formas de reformular el protocolo para que algunos de ellos puedan ser encriptados, tal vez a costa de una mayor latencia (es decir, más recorrido de ida y vuelta por la red). Sin embargo, extensiones como la SNI crean una especie de problema similar al del "huevo y la gallina".

El cliente no encripta nada hasta que ha verificado la identidad del servidor (este trabajo es de los mensajes Certificate y CertificateVerify) y el servidor confirma que conoce la clave secreta compartida (que es responsabilidad del mensaje Finished). Estas medidas garantizan la autenticidad del intercambio de claves, evitando el ataque conocido como moster-in-the-middle (MITM) en el que el atacante engaña al cliente haciéndose pasar por el servidor de manera que este pueda descifrar los mensajes enviados por el cliente. Dado que el servidor necesita la SNI para seleccionar el certificado, es necesario transmitirlo antes de que el intercambio de claves pueda ser autenticado.

En general, la garantía de la confidencialidad de los parámetros del protocolo utilizados para la autenticación solo es posible si el cliente y el servidor ya comparten una clave de cifrado. Pero, ¿de dónde podría proceder esta clave?

Encriptación completa del protocolo de enlace en la primera etapa de TLS 1.3. Curiosamente, la encriptación completa del protocolo de enlace fue propuesta en el pasado como una función esencial de TLS 1.3. En las primeras versiones del protocolo (el borrador n.º 10 , alrededor de 2015), el servidor ofrecía al cliente una clave pública de larga duración durante la fase de negociación, que el cliente utilizaba para el cifrado en posteriores intercambios de comunicación. (El diseño procedía de un protocolo llamado OPTLS, que a su vez se tomó prestado de la propuesta original de QUIC). El propósito principal de esta función, llamada "0-RTT", era permitir que el cliente empezara a enviar los datos de la aplicación antes de completar el protocolo de enlace. Además, permitía al cliente cifrar sus datos iniciales de los mensajes del protocolo tras el mensaje ClientHello, incluidas sus propias EncryptedExtensions, que podrían haber sido utilizadas para proteger los parámetros del protocolo de enlace sensibles del cliente.

En última instancia, esta función no se incluyó en la norma definitiva (RFC 8446, publicada en 2018), principalmente debido a que la complejidad de incluirla superaba su utilidad. En concreto, no protege el intercambio de comunicación inicial, en el que el cliente conoce la clave pública del servidor. Los parámetros que se requieren para la autenticación del servidor, como la SNI, seguían transmitiéndose sin cifrar.

Sin embargo, este modelo es importante como precursor de otros mecanismos de encriptación del protocolo de enlace, como ECH, que utilizan la encriptación de clave pública para proteger los parámetros sensibles del mensaje ClientHello. El principal problema que estos mecanismos deben resolver es la distribución de claves.

El predecesor inmediato de ECH fue la extensión de la SNI cifrada (ESNI). Como su nombre indica, el objetivo de la ESNI era proporcionar la confidencialidad de la SNI. Para ello, el cliente encriptaba la extensión de su SNI bajo la clave pública del servidor y enviaba el texto cifrado al servidor. El servidor intentaba descifrar el texto cifrado utilizando la clave secreta correspondiente a su clave pública. Si se conseguía el descifrado, el servidor procedía a la conexión utilizando la SNI descifrada. De lo contrario, simplemente abortaría el protocolo. El flujo de alto nivel de este sencillo protocolo se ilustra en el diagrama 2.

Diagrama 2: Protocolo de enlace TLS 1.3 con la extensión ESNI. Es idéntico al protocolo de enlace TLS 1.3, excepto que la extensión de la SNI ha sido reemplazada por la ESNI.‌‌

Para la distribución de claves, la ESNI se basaba en otro protocolo crítico: el sistema de nombre de dominio (DNS). Para usar la ESNI para conectarse a un sitio web, el cliente aprovechaba sus consultas estándar A/AAAA y solicitaba un registro TXT, que contenía la clave pública de la ESNI. Por ejemplo, para obtener la clave de crypto.dance, el cliente solicitaba el registro TXT de _esni.crypto.dance:

$ dig _esni.crypto.dance TXT +short
"/wGuNThxACQAHQAgXzyda0XSJRQWzDG7lk/r01r1ZQy+MdNxKg/mAqSnt0EAAhMBAQQAAAAAX67XsAAAAABftsCwAAA="

El blob codificado en base 64 contiene una clave pública de la ESNI y parámetros relacionados, como el algoritmo de cifrado.

¿Pero qué sentido tiene encriptar la SNI si solo vamos a filtrar el nombre del servidor a los observadores de la red a través de una consulta DNS en texto sin formato? La implementación de la ESNI de esta manera se hizo factible con la introducción de DNS mediante HTTPS (DoH), que permite la encriptación de las consultas de DNS a los resolutores que proporcionan el servicio DoH (1.1.1.1 es un ejemplo de este servicio.) Otra función fundamental de DoH es que ofrece un canal cifrado y autenticado para transmitir la clave pública de la ESNI desde el servidor DoH al cliente. Esto evita ataques de envenenamiento de caché que se originan en la red local del cliente. En ausencia de DoH, un atacante local podría evitar que el cliente ofrezca la extensión ESNI devolviendo un registro TXT vacío o coaccionar al cliente para que use la ESNI con una llave que controla.

Si bien la ESNI ha supuesto un gran avance, se queda corta en nuestro objetivo de lograr una encriptación completa del protocolo. Además de ser incompleta, ya que solo protege la extensión SNI, es vulnerable a algunos ataques sofisticados, que, aunque difíciles de llevar a cabo, denotan deficiencias teóricas en el diseño del protocolo que deben ser abordadas.

La ESNI fue implementada por Cloudflare y habilitada por Firefox, con carácter opcional, en 2018, una experiencia que puso al descubierto algunos de los retos que plantea el confiar en el DNS para la distribución de claves. Cloudflare rota su clave de la ESNI cada hora para minimizar los daños colaterales en caso de que una clave se vea comprometida. Los objetos del DNS se almacenan a veces en la memoria caché por mucho más tiempo, lo que se traduce en una buena posibilidad de que un cliente tenga una clave pública caducada. Mientras que el servicio de la ESNI de Cloudflare lo tolera hasta cierto punto, cada clave debe expirar con el tiempo. La pregunta que el protocolo de la ESNI dejó abierta es cómo el cliente debe proceder si el descifrado falla y no puede acceder a la clave pública actual a través del DNS o de otra manera.

Otro problema que plantea confiar en el DNS para la distribución de claves es que varios dispositivos conectados entre sí pueden ser autoritativos para el mismo servidor de origen, pero tienen capacidades diferentes. Por ejemplo, una solicitud de registro A de "ejemplo.com" podría devolver una de dos direcciones IP diferentes, cada una de ellas operada por una CDN diferente. El registro TXT de "_esni.ejemplo.com" contendría la clave pública de una de esas CDN, pero desde luego no de ambas. El protocolo DNS no ofrece una forma de vincular de forma atómica los registros de recursos que corresponden al mismo dispositivo. En particular, es posible que un cliente ofrezca inadvertidamente la extensión ESNI a un dispositivo que no la admita causando que el protocolo de enlace falle. La solución de este problema requiere cambios en el protocolo DNS. (Más información a continuación.)

El futuro de la ESNI. En la siguiente sección, describiremos la especificación de ECH y cómo aborda las deficiencias de la ESNI. Sin embargo, a pesar de sus limitaciones, el beneficio práctico de la privacidad que proporciona la ESNI es significativo. Cloudflare tiene la intención de seguir contribuyendo a la ESNI hasta que la presentación de ECH esté lista.

El objetivo de ECH es encriptar todo el mensaje ClientHello, cerrando así la brecha de TLS 1.3 y la ESNI, con el fin de proteger todos los parámetros del protocolo sensibles a la privacidad. Al igual que la ESNI, el protocolo utiliza una clave pública distribuida a través del DNS y obtenida a través del DoH para la encriptación de los datos iniciales del cliente. Pero ECH ostenta mejoras en la distribución de la clave que hacen que el protocolo sea más sólido a las inconsistencias del caché del DNS. Mientras que el servidor de la ESNI aborta la conexión si falla el descifrado, el servidor ECH intenta completar el protocolo de enlace y suministrar al cliente una clave pública que puede usar para volver a intentar la conexión.

Pero, ¿cómo puede el servidor completar la fase de negociación si no puede descifrar el mensaje ClientHello? Como se ilustra en el diagrama 3, el protocolo ECH en realidad involucra dos mensajes ClientHello: el ClientHelloOuter, que se envía sin cifrar, como de costumbre, y el mensaje ClientHelloInner, que se encripta y se envía como una extensión del ClientHelloOuter. El servidor completa el protocolo de enlace con uno de estos mensajes ClientHello. Si se consigue el descifrado, entonces procede con el mensaje ClientHelloInner, de lo contrario, procede con el mensaje ClientHelloOuter.

Diagrama 3: Protocolo de enlace TLS 1.3 con la extensión ECH

El mensaje ClientHelloInner se compone de los parámetros del protocolo de enlace que el cliente quiere usar para la conexión. Entre ellos se incluyen valores sensibles, como la SNI del servidor de origen al que quiere llegar (llamado servidor backend en lenguaje ECH), la lista ALPN, etc. El mensaje ClientHelloOuter, aunque también es un mensaje ClientHello completo, no se utiliza para la conexión prevista. En cambio, el protocolo de enlace es completado por el propio proveedor de servicios ECH (llamado servidor orientado al cliente), que indica al cliente que se pudo alcanzar su destino final debido a un fallo de descifrado. En este caso, el proveedor de servicios también envía la clave pública ECH correcta con la que el cliente puede volver a intentar la negociación, "corrigiendo" de este modo la configuración del cliente. (Este mecanismo es similar a la forma en que el servidor distribuyó su clave pública para la función 0-RTT en los orígenes de TLS 1.3.)

Como mínimo, ambos mensajes ClientHellos deben contener los parámetros del protocolo de enlace que se requieren para un intercambio de claves autenticadas por el servidor. En concreto, aunque el mensaje ClientHelloInner contiene la SNI real, el mensaje ClientHelloOuter también contiene un valor de la SNI, que el cliente espera verificar en caso de fallo en el descifrado ECH (es decir, el servidor orientado al cliente). Si la conexión se establece usando el mensaje ClientHelloOuter, entonces se espera que el cliente aborte inmediatamente la conexión y vuelva a intentar la negociación con la clave pública proporcionada por el servidor. No es necesario que el cliente especifique una lista ALPN en el mensaje ClientHelloOuter, ni ninguna otra extensión usada para guiar el comportamiento posterior del enlace. Todos estos parámetros están encapsulados por el mensaje encriptado de ClientHelloInner.

Este diseño resuelve, en mi opinión, de forma bastante elegante, la mayoría de los retos para implementar de forma segura el cifrado del protocolo de enlace que han planteado anteriores mecanismos. Lo que es más importante, este diseño no se inventó de forma aislada. El protocolo refleja las diversas perspectivas de la comunidad del IETF, y su desarrollo encaja con otras normas del IETF que son fundamentales para el éxito del ECH.

El primero es una nueva e importante función de DNS conocida como el tipo de registro de recursos HTTPS. A un alto nivel, este tipo de registro está destinado a permitir múltiples puntos de conexión HTTPS que son autoritativos para el mismo nombre de dominio para anunciar diferentes capacidades para el TLS. Esto hace posible confiar en el DNS para la distribución de claves, resolviendo uno de los retos de implementación descubiertos por la implementación inicial de la ESNI. Si deseas más información de este nuevo tipo de registro y lo que significa para Internet en general, echa un vistazo a la publicación de Alessandro Ghedini sobre el tema.

La segunda es la norma de encriptación de clave pública híbrida (HPKE) del CFRG (Crypto Forum Research Group) que especifica un marco extensible para la elaboración de planes de cifrado de clave pública adecuados para una amplia variedad de aplicaciones. En particular, ECH delega todos los detalles de su mecanismo de encriptación del protocolo de enlace a HPKE, lo que da como resultado una especificación mucho más simple y fácil de analizar. (Por cierto, HPKE es también el principal componente de Oblivious DNS mediante HTTPS.)

La actual especificación de ECH es la culminación de una colaboración de varios años. En este momento el diseño general del protocolo es bastante estable. De hecho, el siguiente borrador de la especificación será la primera de las implementaciones sobre la que se realizarán las pruebas de interoperación. Aun así, quedan varios detalles que se deben resolver. Vamos a concluir esta publicación con un breve resumen del camino a seguir.

En última instancia, el objetivo de ECH es asegurar que las conexiones TLS realizadas a diferentes servidores de origen detrás del mismo proveedor de servicios ECH no se distingan entre sí. En otras palabras, cuando te conectas a un servidor de origen con Cloudflare, nadie en la red entre tú y Cloudflare debería ser capaz de discernir a qué origen llegaste, o qué parámetros del protocolo de enlace confidenciales acordaste con el servidor de origen. Aparte del beneficio inmediato de privacidad, esta propiedad, de lograrse, prepara el camino para la implementación de nuevas funciones para TLS sin comprometer la privacidad.

La encriptación del mensaje ClientHello es un paso importante para lograr este objetivo, pero tenemos que seguir mejorando. Un importante vector de ataque del que aún no hemos hablado es el análisis del tráfico. Esto se refiere a la recogida y análisis de las propiedades del canal de comunicación que descifran parte de los contenidos del texto cifrado, sin romper el esquema de cifrado subyacente. Por ejemplo, la longitud del mensaje ClientHello cifrado podría filtrar suficiente información sobre la SNI para que el atacante haga una suposición fundamentada sobre su valor (este riesgo es especialmente alto para los nombres de dominio que son particularmente cortos o particularmente largos). Por lo tanto, es fundamental que la longitud de cada texto cifrado sea independiente de los valores de los parámetros sensibles a la privacidad. La especificación actual de ECH proporciona algunas mitigaciones, pero su cobertura es incompleta. Por lo tanto, mejorar la resistencia de ECH al análisis del tráfico es una dirección importante para el trabajo futuro.

Una cuestión importante que sigue abierta sobre ECH es el impacto que tendrá en las operaciones de la red.

Una de las lecciones aprendidas de la implementación de TLS 1.3 es que la actualización de un protocolo central de Internet puede desencadenar un comportamiento inesperado de la red. Cloudflare fue uno de los primeros operadores importantes de TLS en implementar TLS 1.3 a escala. Cuando navegadores como Firefox y Chrome comenzaron a habilitarlo de forma experimental, observaron una tasa significativamente mayor de fallos de conexión en comparación con TLS 1.2. La causa fundamental de estos fallos fue la osificación de la red, es decir, la tendencia de las cajas intermedias, aplicaciones de red entre clientes y servidores que supervisan y a veces interceptan el tráfico, a escribir software que espera que el tráfico tenga un aspecto y un comportamiento determinados. El cambio de protocolo antes de que las cajas intermedias tuvieran la oportunidad de actualizar su software llevó a que éstas trataran de analizar paquetes que no reconocían, lo que provocó errores de software que, en algunos casos, hicieron que las conexiones se interrumpieran por completo.

Este problema estaba tan extendido que, en lugar de esperar a que los operadores de red actualizaran su software, se modificó el diseño de TLS 1.3 para mitigar el impacto de la osificación de la red. La ingeniosa solución fue hacer que TLS 1.3 "se pareciera" a otro protocolo que se sabe tolera las cajas intermedias. Específicamente, el formato de la conexión e incluso el contenido de los mensajes del protocolo de enlace se hicieron para que se asemejaran al TLS 1.2. Evidentemente, estos dos protocolos no son idénticos, un observador de red curioso aún puede distinguirlos, pero son y se comportan de manera suficientemente parecida como para asegurar que la mayoría de las cajas intermedias existentes no los traten de manera diferente. En la práctica, se comprobó que esta estrategia reducía significativamente la tasa de fallos de conexión, lo suficiente como para hacer viable la implementación de TLS 1.3.

Una vez más, ECH representa una mejora significativa para el protocolo TLS para el cual el espectro de la osificación de la red es de suma importancia. El mensaje ClientHello contiene parámetros, como la SNI, que han existido en el protocolo de enlace durante mucho tiempo, y aún no sabemos cuál será el impacto de su encriptación. En previsión de los problemas de implementación que la osificación podría causar, el protocolo ECH ha sido diseñado para parecerse tanto como sea posible a un protocolo de enlace TLS 1.3 estándar. La diferencia más notable es la propia extensión ECH: si las cajas intermedias la ignoran, como deberían hacer, si cumplen con el estándar TLS 1.3, entonces el resto del protocolo de enlace se parecerá y se comportará como de costumbre.

Queda por ver si esta estrategia será suficiente para asegurar la implementación a gran escala de ECH. En caso afirmativo, cabe destacar que esta nueva función ayudará a mitigar el impacto de las futuras actualizaciones del protocolo TLS en las operaciones de la red. La encriptación del protocolo completo reduce el riesgo de osificación, ya que significa que hay características de protocolo menos visibles para que el software se osifique. Creemos que este enfoque será bueno para el rendimiento de Internet en general.

El antiguo protocolo de enlace TLS presenta (involuntariamente) fallos. Los requisitos operativos tanto del cliente como del servidor han llevado a que parámetros sensibles de carácter privado, como la SNI, se gestionen sin cifrar completamente, dejándolos al acceso de los observadores de la red. La extensión del ECH tiene como objetivo cerrar esta brecha permitiendo el cifrado del protocolo de enlace completo. Esto representa una mejora significativa del protocolo TLS, que ayudará a preservar la privacidad del usuario final a medida que el protocolo siga evolucionando.

El trabajo de la norma ECH continúa y mientras sigue su desarrollo, Cloudflare se compromete a asumir su parte para asegurar que esta importante actualización de TLS se implemente en Internet.