Podcast de Redes de Eduardo Collado
Encrypted ClientHello (ECH)
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,