Encrypted ClientHello (ECH)

Podcast de Redes de Eduardo Collado

Imaginad que estáis en casa tranquilamente, ha sido un día duro y es el momento de ponerte a descansar. Ahora os ponéis a leer algo que no necesite quemar neuronas y desconectar.

Entonces te encuentras que mi compañero en Tecnocrática Javier va y pone el siguiente enlace Good-bye ESNI, hello ECH!, y claro empiezas a leer y una cosa lleva a la otra y la tarde se te va sin querer.

Hoy voy a contaros lo que he podido averiguar sobre el ECH y que tiene de novedoso respecto a tecnologías como ESNI.

SNI ya sabemos los problemas que tiene y es voz populi, incluso se habla de ello en bandaancha. (Visto también en el grupo de Telegram), pero todavía podemos hacer algo.

Por otro lado ECH realmente sale por primera vez en un draft de la IETF de Octubre de 2020, así que está calentito todavía y recién salido del horno, si es que podemos considerarlo como ya salido del horno.

Si nos leemos el Draft todo es más o menos normal hasta que llegamos a la siguiente frase

ECH permite al cliente cifrar extensiones ClientHello sensibles,p. ej., SNI, ALPN, etc., bajo la clave pública del cliente servidor.

draft-ietf-tls-esni-08 – https://tools.ietf.org/html/draft-ietf-tls-esni-08

Y claro, aquí el interés se dispara.

La comunicación en Internet puede ir cifrada, es lo ideal, y para que ese cifrado pueda establecerse se requiere de claves, una pareja de claves que no puedan ser averiguadas por alguien que esté en medio.

El protocolo utilizado para realizar esta función es TLS.

TLS por otro lado es un protocolo maravilloso y que hace de maravilla su trabajo. El problema de TLS es que hay partes de la negociación que se realizan en claro, sin encriptar.

La información que se puede ver sin encriptar incluye información como el origen y el destino y claro, eso a ojos de alguien que esté viendo todos y cada uno de los paquetes que viajan por la red es una autentica mina.

Los bloqueos de SNI son precisamente por esto, alguien que está en medio decide viendo los parámetros no encriptados en la negociación en claro del handshake bloquear el destino que se puede ver porque no va encriptado.

Esto a nivel técnico es lo que es, pero a nivel social pues imaginad lo que puede representar el tener la capacidad de bloquear tráfico https contra webs que no nos interese que vean nuestros usuarios/clientes. Páginas de descargas de música, páginas de empresas de la competencia, páginas de partidos políticos, en fin … las posibilidades a nivel técnico son muchísimas, censura al fin y al cabo.

Pero podemos hacer algo para que no se negocie nada en plano y que esté todo encriptado y por tanto que nuestra información no pueda ser inspeccionada por elementos intermedios.

La opción del ESNI está ahí, pero ahora estamos en el desarrollo de algo, que a mis ojos, es muchísimo mejor, y es el ECH (Encrypted ClientHello).

El ECH hace que el handshake del TLS se mantenga secreto, y esto solucionaría el problema del SNI, pero no se queda en solucionar el problema del SNI, sino que soluciona todos los problemas generados por la negociación en plano del handshake del TLS.

La extensión de TLS ALPN que decide qué protocolo superior se usará una vez realizado el handshake de TLS también se solucionaría con el ECH pues ya no se podrá ver en los paquetes al ir encriptada.

Buscar una opción al problema del SNI y a los bloqueos indiscriminados que estamos sufriendo por parte de algunas de las grandes operadoras, al menos en España, es una labor de todos y cada uno puede aportar su pequeño granito de arena, y hoy estoy aquí para hablaros de opciones de mejora del TLS.

La problemática

Entre el cliente y el servidor no sólo hay un intercambio de claves, es algo mucho más complejo y por tanto sensible.

Entre cliente y servidor en TLS se intercambian una serie de características y parámetros:

• Método de intercambio de llaves.
• El algoritmo de cifrado.
• Quien y cómo se autentica.
• Qué protocolo se va a utilizar después de TLS.
• Etc.

Esa información es crítica y es necesario preservarla al máximo.

Ya sabéis que la extensión SNI se utiliza por el cliente para indicar al servidor a qué sitio web quiere acceder.

La extensión ALPN se utiliza para decidir el protocolo de capa de aplicación a utilizar cuando finalice la conexión TLS.

En fin, es un tema sensible preservar la privacidad de esta información que a día de hoy no se encripta.

Para poder encriptar toda esa información y evitar las fugas de información o de privacidad se hace necesario disponer de cifrado en el handshake, pero claro, esto es lo del huevo y la gallina.

¿Cómo el cliente y el servidor pueden elegir una clave de cifrado para el handshake si precisamente el handshake es para obtener eso mismo?

La solución podría pasar por utilizar menos parámetros, evitando los más sensibles, porque al final para negociar unas claves algo de información en claro pasará.

TLS 1.3

Antes de TLS 1.3 no había cifrado de enlace en TLS, a nadie se le ocurrió, y de hecho fue en 2013, tras las revelaciones de Snowden, cuando la comunidad de la IETF se puso en marcha para considerar cómo contrarrestar la amenaza de la vigilancia masiva.

En 2014 comenzó el proceso de estandarización de TLS 1.3 y el objetivo era claro, cifrar la cantidad de información posible, pero no se consiguió cifrar todo y quedaron parámetros sin cifrar, entre ellos nuestro amigo SNI.

Antes de seguir dejadme describir cómo funciona TLS 1.3.

• En un primer momento el cliente envía el ClientHello con la clave compartida. En ese mismo mensaje además viaja el SNI y el ALPN entre otros. Todo esto sin cifrar porque no ha habido aún intercambio de claves.
• El servidor contesta con el ServerHello que tiene la clave compartida del servidor. Este mensaje también va sin encriptar.

A partir de aquí el cliente ya conoce su llave y la del servidor, con lo que ya se puede encriptar porque ya hemos tenido el intercambio de llaves

• El primer mensaje encriptado va desde el servidor al cliente y es el EncryptedExtensions donde se envían los parámetros sensibles del servidor como por ejemplo el ALNP del servidor y por supuesto el certificado.

Vamos a parar aquí un momento.

Hemos dicho que tanto el ClientHello como el ServerHello van sin encriptar y es porque hasta que no tenemos esos dos mensajes no podemos tener el par de llaves necesarias para la encriptación.

Pero podemos pensar que sería buena idea sacar del ClientHello el SNI y lo transmitimos más tarde, pero si no tenemos el SNI no podemos ver el host, con lo que no podemos generar las llaves para el certificado. Esta es la razón por la que la información de SNI se envía sin encriptar en TLS 1.3.

ESNI

Todos tenemos en mente las siglas ESNI (Encrypted Server Name Indicator), que es una opción que haría que el SNI fuera encriptado, pero no soluciona nada más, no solucionamos el problema de ALPN, sólo el SNI.

¿Cómo funcionario?, pues realmente la única diferencia con TLS con SNI sería que utilizaremos un DNS para dejar ahí un registro TXT con la clave pública del cifrado del ESNI.

Juntando la posibilidad e encriptar el SNI con una llave pública del servidor que luego colgaríamos del DNS y con la posibilidad de utilizar DNSoHTTPS pues en principio deberíamos de tener ya algo funcional.

Una limitación que tiene ESNI consiste en que si falla el descrifrado por la razón que sea la conexión se aborta.

Algo que hay que tener con ESNI es la capacidad de ir rotando esa llave de vez en cuando, CloudFlare por ejemplo la rota cada hora parece ser.

ECH

Pero claro, si queremos una solución más completa ESNI no nos vale por lo que hemos dicho antes, no cifra todo, sólamente la extensión SNI, así que la opción buena es cifrar el ClientHello en si, algo que no se puede hacer.

Si no podemos encriptar el ClientHello sí que podemos convertirlo en ClientHelloOuter (sin cifrar) y ClientHelloInner (cifrado) y siguiendo un esquema parecido al de ESNI, la diferencia es que aquí sí que terminamos cifrando todo y aunque fallase el descifrado no se abortaría la conexión.

Vamos a verlo con más detenimiento.

En el ClientHelloInner(el cifrado) el cliente indica los parámetros que necesita para la conexión, incluyendo el SNI origen del servidor al que quiere llegar, la lista ALPN.

En el ClientHelloOutter (el no cifrado) no se usa para la conexión real y la información se completa de forma automática, el servidor indicará al cliente que no pudo llegar a si destino previsto por error en el descifrado, pero enviando la llave pública del ECH correcta. De esta forma el cliente puede volver a enviar el mensaje corrigiendo la configuración.

El objetivo de ECH es que las peticiones realizadas a un proveedor de servicio sean indistinguibles entre si

Todo esto todavía está bastante verde todavía y a partir del próximo borrador se comenzarán ya a hacer pruebas.

Foto de Dan Nelson en Pexels