A maior parte da comunicação na Internet moderna é encriptada, de forma a garantir que o seu conteúdo é compreendido apenas pelos pontos terminais, i.e., cliente e servidor. No entanto, a encriptação requer uma chave, pelo que os pontos terminais têm de concordar numa chave criptográfica sem a revelar a eventuais invasores. O protocolo criptográfico mais utilizado para fazer isto, chamado key exchange (troca de chaves), é o acordo "handshake" em Transport Layer Security (TLS).
Nesta publicação, iremos aprofundar o Encrypted Client Hello (ECH), uma nova extensão para TLS, que promete melhorar significativamente a privacidade deste protocolo essencial da Internet. Nos dias de hoje, vários parâmetros sensíveis à privacidade da ligação TLS são negociados abertamente. Isto deixa uma coleção de metadados disponíveis para os observadores da rede, incluindo as identidades dos pontos terminais, como eles usam a ligação, etc.
O ECH encripta todo o handshake, para que estes metadados sejam mantidos em segredo. De forma crucial, isto fecha uma velha brecha de privacidade ao proteger a Indicação de Nome do Servidor (SNI) de olhares curiosos na rede. Encriptar o segredo SNI é importante, uma vez que este é o indicador mais preponderante acerca do servidor com o qual um dado cliente está a comunicar. No entanto e, talvez, com mais importância, o ECH também provê uma base para que sejam futuramente adicionadas funcionalidades de segurança e melhorias de desempenho ao TLS, ao passo que minimiza o seu impacto na privacidade dos utilizadores finais.
O ECH é o produto de uma colaboração estreita, facilitada pelo IETF, entre académicos, líderes tecnológicos da indústria - grupo onde se inclui a Cloudflare -, os nossos amigos da Fastly e da Mozilla (ambos com ligações de co-autoria do padrão) e muitos outros. Este recurso representa um upgrade significativo ao protocolo TLS, recurso esse que se baseia em tecnologias mais avançadas, como o DNS-over-HTTPS, que estão agora a dar os primeiros passos. Como tal, o protocolo ainda não está pronto para ser implantado em grande escala na Internet. Esta publicação destina-se a ser um sinal da encriptação do handshake completo.
Antecedentes
A história do TLS é a história da Internet. À medida que nossa confiança na Internet cresceu, o protocolo também evoluiu para responder às constantes alterações de requisitos operacionais, formas de uso e modelos de ameaça em constante mudança. O cliente e o servidor não trocam apenas uma chave: eles negociam uma grande variedade de recursos e parâmetros - o método exato de troca de chaves, o algoritmo de encriptação, quem é autenticado e como, que protocolo de camada de aplicações usar após o handshake e muito, muito mais. Todos estes parâmetros têm impacto sobre as propriedades de segurança do canal de comunicação de uma forma ou de outra.
O SNI é um excelente exemplo de um parâmetro que tem impacto na segurança do canal. A extensão SNI é usada pelo cliente para indicar ao servidor qual o site que quer alcançar. Esse recurso é essencial para a Web moderna, pois hoje em dia é comum que muitos servidores de origem fiquem atrás de um único operador de TLS. Neste cenário, o operador usa o SNI para determinar quem irá autenticar a ligação: sem isso, o operador não teria qualquer maneira de saber que certificado TLS deve apresentar ao cliente. O problema é que o SNI divulga na rede a identidade do servidor de origem ao qual o cliente deseja ligar-se, permitindo, potencialmente, que curiosos infiram muita informação sobre a sua comunicação. (Existem, claro, outras formas de um observador da rede identificar a origem —o endereço de IP da origem, por exemplo. Mas a co-localização com outras origens no mesmo endereço de IP torna muito mais difícil usar essa métrica do que simplesmente inspecionar o SNI.)
Embora a proteção do SNI sirva como ímpeto para o ECH, não é de modo algum o único parâmetro de handshake sensível à privacidade que o cliente e o servidor negoceiam. Outro exemplo é a extensão ALPN, usada para decidir que protocolo de camada de aplicações deve ser usado quando a ligação TLS é estabelecida. O cliente envia a lista de aplicações que suporta — seja HTTPS, e-mail, mensagens instantâneas ou a infinidade de outras aplicações que usam TLS para segurança de transporte — e o servidor seleciona uma desta lista, enviando a sua seleção para o cliente. Ao fazê-lo, o cliente e o servidor revelam à rede um sinal claro das suas capacidades e para que é que pode ser usada a ligação.
Alguns recursos são tão sensíveis à privacidade que a sua inclusão no handshake não é solução. Uma das ideias apresentadas foi a de substituir a troca de chaves no centro do TLS pela troca de chaves autenticada por palavras-chave (PAKE). Isso permitiria que a autenticação baseada em palavras-chave fosse usada ao mesmo tempo que (ou em vez de) uma autenticação baseada em certificados, tornando o TLS mais robusto e adequado para uma mais ampla gama de aplicações. O problema de privacidade aqui é análogo ao do SNI: os servidores normalmente associam um identificador exclusivo a cada cliente (p.ex., um nome de utilizador ou endereço de e-mail) que é usado para recuperar as credenciais do cliente; sendo o cliente quem deve, de alguma forma, transmitir essa identidade ao servidor no decurso do handshake. Caso seja enviada de forma não encriptada, então estas informações que permitem a identificação pessoal seriam facilmente acessíveis a qualquer observador da rede.
Um dos ingredientes necessários para lidar com todas essas fugas de privacidade é a encriptação do handshake, ou seja, a encriptação de mensagens de handshake além dos dados da aplicação. Parece bastante simples, mas esta solução apresenta outro problema: como é que o cliente e o servidor escolhem uma chave de encriptação se, no fim de contas, o handshake é em si um meio de trocar uma chave? Como é óbvio, alguns parâmetros têm de ser enviados de forma não encriptada. Neste sentido, o objetivo do ECH é encriptar todos os parâmetros do handshake, exceto aqueles que são essenciais para concluir a troca de chaves.
Para compreender o funcionamento do ECH e as decisões de design por detrás dele, é-nos útil saber um pouco mais sobre a história da encriptação do handshake no TLS.
Encriptação de handshake no TLS
O TLS não tinha qualquer encriptação do handshake antes da sua versão mais recente, o TLS 1.3. Na sequência das revelações de Snowden em 2013, o IETF começou a considerar formas de combater a ameaça que a vigilância em massa representava para a Internet aberta. Quando o processo de padronização do TLS 1.3 começou, em 2014, um dos seus objetivos de conceção era encriptar o handshake o máximo possível. Infelizmente, o padrão final fica aquém da encriptação completa do handshake e, vários parâmetros, incluindo o SNI, ainda são enviados de forma desprotegida. Vamos ver mais de perto para perceber porquê.
O fluxo do protocolo TLS 1.3 é ilustrado na Figura 1. A encriptação de "handshake" começa assim que o cliente e o servidor calculam um novo segredo partilhado. Para fazer isso, o cliente envia uma partilha de chave na sua mensagem "ClientHello", e o servidor responde no seu "ServerHello" com a sua própria partilha de chaves. Tendo feito essas partilhas, o cliente e o servidor podem derivar um segredo partilhado. Cada mensagem de "handshake" subsequente é encriptada usando a chave de tráfego do "handshake" derivada do segredo partilhado. Os dados da aplicação são encriptados usando uma chave diferente, chamada chave de tráfego da aplicação, que também é derivada do segredo partilhado. Estas chaves derivadas têm propriedades de segurança diferentes: para dar mais ênfase a isso, estão ilustradas com cores diferentes.
A primeira mensagem de "handshake" encriptada é o "EncryptedExtensions" do servidor. O objetivo desta mensagem é proteger os parâmetros sensíveis do "handshake" do servidor, incluindo a extensão ALPN do servidor, que contém a aplicação selecionada na lista ALPN do cliente. Os parâmetros de troca de chave são enviados sem encriptação no "ClientHello" e "ServerHello".
Todos os parâmetros de "handshake" do cliente, sensíveis ou não, são enviados no "ClientHello". Olhando para a Figura 1, poderá pensar em formas de reinventar o "handshake" para que alguns deles possam ser encriptados, talvez à custa de maior latência (ou seja, mais viagens de ida e volta pela rede). No entanto, extensões como SNI criam uma espécie de problema "ovo e galinha".
O cliente não encripta nada até que tenha verificado a identidade do servidor (sendo esta a função das mensagens "Certificate" e "CertificateVerify") e o servidor provar que conhece o segredo partilhado (função desempenhada pela mensagem de conclusão - Finished). Essas medidas garantem a troca de chaves seja autenticada, impedindo assim ataques monster-in-the-middle (MITM) em que o adversário imita o servidor aos olhos do cliente de maneira a que isso lhe permita desencriptar mensagens enviadas pelo cliente. Uma vez que o servidor precisa do SNI para selecionar o certificado, este precisa de ser transmitido antes que a troca de chave possa ser autenticada.
Em geral, garantir a confidencialidade dos parâmetros de "handshake" usados para autenticação só é possível se o cliente e o servidor já partilharem uma chave de encriptação. Mas de onde poderá vir essa chave?
Encriptação completa do handshake nos primórdios do TLS 1.3. Curiosamente, a encriptação completa do handshake já havia sido proposta como recurso nuclear do TLS 1.3. Nas primeiras versões do protocolo (draft-10, circa 2015), o servidor ofereceria ao cliente uma chave pública de longa-duração durante o handshake, que o cliente usaria depois para encriptar os handshakes subsequentes. (Este conceito surgiu de um protocolo chamado OPTLS, que por sua vez foi retirado da proposta original do QUIC .) Denominado "0-RTT", o objetivo principal deste modo era permitir que o cliente começasse a enviar dados da aplicação antes de concluir um handshake. Além disso, permitiu que o cliente encriptasse a sua primeira leva de mensagens de handshake depois do "ClientHello", incluindo as suas próprias EncryptedExtensions, que podem ter sido usadas para proteger os parâmetros sensíveis do handshake do cliente.
Em última análise, esse recurso não foi incluído no padrão final (o RFC 8446, publicado em 2018), principalmente devido à sua complexidade superar a utilidade. Em particular, não faz nada para proteger o handshake inicial, no qual o cliente fica a saber a chave pública do servidor. Os parâmetros que são necessários para autenticação de servidor do handshake inicial, como SNI, ainda seriam transmitidos de forma desprotegida.
No entanto, este método é notável como precursor de outros mecanismos de encriptação de handshake, como o ECH, que usam encriptação de chave pública para proteger parâmetros sensíveis do ClientHello. O principal problema que esses mecanismos devem resolver é a distribuição de chave.
Antes do ECH havia (e há!) o ESNI
O antecessor imediato do ECH era a extensão SNI encriptado (ESNI). Como o nome indica, o objetivo do ESNI era fornecer confidencialidade do SNI. Para isso, o cliente encriptaria a sua extensão SNI de acordo com a chave pública do servidor, enviando-lhe então o texto codificado. O servidor tentaria desencriptar o texto codificado usando a chave secreta, correspondente à sua chave pública. Se a desencriptação fosse bem-sucedida, o servidor prosseguiria com a ligação, usando o SNI desencriptado. Caso contrário, simplesmente cancelaria o "handshake". O fluxo de alto nível desse protocolo simples é ilustrado na Figura 2.
O ESNI contou com outro protocolo crítico para a distribuição de chaves: o Domain Name Service (DNS). Para poder usar o ESNI para estabelecer ligação a um site, o cliente pesquisaria nas suas consultas padrão A/AAAA por uma solicitação para um registo TXT contendo a chave pública ESNI. Por exemplo, para obter a chave para crypto.dance, o cliente solicitaria o registo TXT _esni.crypto.dance:
$ dig _esni.crypto.dance TXT +short
"/wGuNThxACQAHQAgXzyda0XSJRQWzDG7lk/r01r1ZQy+MdNxKg/mAqSnt0EAAhMBAQQAAAAAX67XsAAAAABftsCwAAA="
O blob codificado de base 64 contém uma chave pública ESNI e parâmetros relacionados, tais como o algoritmo de encriptação.
Mas para quê encriptar o SNI, se só vamos revelar o nome do servidor a observadores de rede e através de uma consulta DNS em texto por encriptar? Implementar o ESNI desta forma tornou-se viável com a introdução do DNS-over-HTTPS (DoH), que permite a encriptação de consultas DNS aos resolvedores que fornecem o serviço DoH (1.1.1.1 é um exemplo de tal serviço). Uma outra característica crucial do DoH é que este fornece um canal encriptado e autenticado para transmitir a chave pública ESNI do servidor DoH ao cliente. Isso evita ataques de corrupção da cache, cuja origem seja a rede local do cliente: na ausência de DoH, um invasor local pode impedir que o cliente ofereça a extensão ESNI devolvendo um registo TXT vazio, ou coagir o cliente a usar a ESNI com uma chave controlada por ele.
Apesar do ESNI ser um significativo passo em frente, fica aquém do nosso objetivo de alcançar a encriptação completa do handshake. Além de ser incompleto — uma vez que só protege a extensão SNI — é vulnerável a um punhado ataques sofisticados, que, embora difíceis de conseguir, visam as fraquezas teóricas no desenho do protocolo, com as quais temos de lidar.
O ESNI foi implementado pela Cloudflare e permitido pelo Firefox, como opção, em 2018. Essa experiência revelou alguns dos desafios acarretados por confiar ao DNS a distribuição de chaves. A Cloudflare roda a sua chave ESNI a cada hora, minimizando danos colaterais no caso de uma chave ficar comprometida. Os artefatos DNS às vezes são armazenados em cache por muito mais tempo, o que resulta numa oportunidade considerável de um cliente ter uma chave pública obsoleta. Embora o serviço ESNI da Cloudflare tolere isso até certo ponto, cada chave deverá, a dado momento, expirar. A pergunta que o protocolo ESNI deixou em aberto é como deve o cliente prosseguir caso a desencriptação falhe e não lhe seja possível aceder à chave pública atual, via DNS ou de outra forma.
Outro problema que advém de confiar no DNS para a distribuição de chaves é que vários pontos terminais podem ter a mesma autoridade para o mesmo servidor de origem, mas com capacidades diferentes. Por exemplo, uma solicitação para o registo A de "example.com" pode devolver um de dois endereços IP diferentes, cada um operado por um CDN diferente. O registo TXT para "_esni.example.com" conteria a chave pública para um desses CDNs, mas certamente não para ambos. O protocolo DNS não prevê uma maneira de aglutinar atomicamente os registos de recursos que correspondam ao mesmo ponto terminal. Em particular, é possível que um cliente dê, inadvertidamente, extensão ESNI a um ponto terminal que não o suporta, fazendo com que o handshake falhe. Corrigir esse problema exige alterações ao protocolo DNS. (Mais sobre isso abaixo.)
O futuro do ESNI. Na secção seguinte, descreveremos a especificação ECH e como esta aborda as insuficiências do ESNI. Apesar das suas limitações, o benefício prático de privacidade trazido pelo ESNI é, no entanto, significativo. A Cloudflare pretende continuar a dar suporte ao ESNI até que a ECH esteja pronta para distribuição.
Os prós e os contras do ECH
O objetivo do ECH é encriptar todo o ClientHello, fechando assim a lacuna deixada no TLS 1.3 e ESNI, ao proteger todos os parâmetros de handshake sensíveis à privacidade. De forma similar à do ESNI, o protocolo usa uma chave pública, distribuída via DNS e obtida usando o DoH, para encriptação quando o cliente começou. Mas o ECH apresenta melhorias na distribuição de chave que tornam o protocolo mais robusto para inconsistências de cache do DNS. Ao passo que o servidor ESNI interrompe a conexão se a desencriptação falhar, o servidor ECH tenta concluir o handshake e fornecer uma chave pública ao cliente que este possa usar para tentar novamente a ligação.
Mas como é que o servidor pode concluir o "handshake" se não conseguir desencriptar o "ClientHello"? Como podemos ver na Figura 3, o protocolo ECH envolve, na realidade, duas mensagens "ClientHello": o "ClientHelloOuter", que é enviado abertamente, como de costume; e o "ClientHelloInner", que é encriptado e enviado como uma extensão do "ClientHelloOuter". O servidor conclui o "handshake" com apenas um destes "ClientHellos": se a desencriptação for bem-sucedida, prossegue com o "ClientHelloInner"; caso contrário, prossegue com o "ClientHelloOuter".
O "ClientHelloInner" é composto pelos parâmetros de "handshake" que o cliente deseja usar para a ligação. Isto inclui valores sensíveis, como o SNI do servidor de origem que quer alcançar (chamado o servidor "back-end" no léxico ECH), a lista ALPN, e assim por diante. O "ClientHelloOuter", porquanto também uma mensagem "ClientHello" de pleno direito, não é usado para a ligação pretendida. Em vez disso, o "handshake" é terminado pelo próprio provedor de serviços ECH (chamado o servidor voltado para o cliente), sinalizando ao cliente que o seu destino pretendido não poderia ser alcançado devido à falha de desencriptação. Neste caso, o provedor de serviços também envia a chave pública ECH correta com que o cliente pode repetir o "handshake", "corrigindo" desse modo a configuração do cliente. (Este mecanismo é semelhante ao modo como o servidor distribuiu a sua chave pública para o modo 0-RTT no início do TLS 1.3.)
No mínimo, ambos os "ClientHellos" têm de conter os parâmetros de "handshake" que são exigidos para uma troca de chaves autenticada pelo servidor. Em particular, quando o "ClientHelloInner" contiver o SNI real, o "ClientHelloOuter" contém igualmente um valor SNI, que o cliente espera verificar em caso de falha da desencriptação ECH (isto é, o servidor voltado para o cliente). Se a ligação for estabelecida usando o "ClientHelloOuter", espera-se que o cliente a cancele imediatamente e tente novamente o "handshake", usando a chave pública fornecida pelo servidor. Não é necessário que o cliente especifique uma lista ALPN no "ClientHelloOuter", nem em qualquer outra extensão usada para orientar o comportamento pós-"handshake". Todos estes parâmetros são englobados pelo "ClientHelloInner" encriptado.
Este design soluciona —de forma muito elegante, penso eu, — a maioria dos desafios trazidos pela implementação segura da encriptação do handshake completo com que se depararam os mecanismos anteriores. É importante dizer que o design do ECH não foi inventado a partir do nada. O protocolo reflete as diferentes perspectivas da comunidade IETF, sendo que o seu desenvolvimento se encaixa noutros padrões IETF, basilares para o sucesso do ECH.
O primeiro é um novo recurso DNS importante conhecido como o tipo de registo de recurso HTTPS. A um nível superior, esse tipo de registo destina-se a permitir o anúncio de diferentes capacidades TLS por vários pontos de extremidade HTTPS, com a mesma autoridade para o mesmo nome de domínio. Isso possibilita confiar no DNS para distribuir chaves, resolvendo um dos desafios descobertos pela implantação inicial da ESNI. Para conhecer melhor este novo tipo de registo e o que isso significa para a Internet de forma mais ampla, veja a publicação recente do Blog de Alessandro Ghedini sobre o assunto.
O segundo é o padrão de Encriptação de Chave Pública Híbrida ("Hybrid Public Key Encryption") (HPKE) da CFRG, que preconiza uma estrutura extensível para a construção de métodos de encriptação de chave pública, adequados a uma ampla variedade de aplicações. O ECH delega, em particular, todos os detalhes do seu mecanismo de encriptação de handshake ao HPKE, resultando numa especificação muito mais simples e fácil de analisar. (Aliás, o HPKE também é o principal ingrediente do Oblivious DNS-over-HTTPS.)
O caminho a percorrer
A especificação ECH atual é o culminar de uma colaboração desde há anos. Neste momento, o design geral do protocolo é bastante estável. Na verdade, o esboço atual da especificação será o primeiro a ser visado para testes de interoperabilidade entre as implementações. Ainda assim, resta uma série de detalhes que precisam de ser resolvidos. Vamos terminar esta publicação com uma súmula breve do caminho adiante.
Resistência à análise de tráfego
Em última análise, o objetivo do ECH é garantir que as ligações TLS estabelecidas com diferentes servidores de origem atrás do mesmo provedor de serviços ECH sejam indistinguíveis umas das outras. Por outras palavras, quando o utilizador se liga a uma origem por trás da, digamos, Cloudflare, ninguém na rede entre ele e a Cloudflare deve ser capaz de distinguir que origem alcançou ou que parâmetros de handshake de privacidade foram negociados entre si e a origem. Além do benefício imediato de privacidade, esta propriedade, ao ser alcançada, abre caminho para a implementação de novos recursos para TLS, sem comprometer a privacidade.
Encriptar o ClientHello é um passo importante para alcançar esse objetivo, mas precisamos de fazer um pouco mais. Um vetor de ataque importante que ainda não discutimos é a análise de tráfego. Isso diz respeito à recolha e análise de propriedades do canal de comunicação, que deixam a descoberto parte do conteúdo do texto cifrado, sem quebrar o método de encriptação subjacente. Por exemplo, o comprimento do ClientHello encriptado pode revelar informações suficientes sobre o SNI para que o adversário lance um bom palpite quanto ao seu valor (este risco é especialmente alto para nomes de domínio que são quer particularmente curtos quer particularmente longos). É, portanto, crucial que o comprimento de cada texto cifrado seja independente dos valores dos parâmetros sensíveis à privacidade. A especificação ECH atual mitiga esta questão nalguma medida, mas a sua abrangência é insuficiente. Assim, melhorar a resistência do ECH à análise de tráfego é um caminho importante para o trabalho futuro.
O espectro da ossificação
Uma das questões preponderantes em aberto quanto ao ECH prende-se com o impacto que este terá nas operações de rede.
Uma das lições retiradas da implementação do TLS 1.3 foi que atualizar um protocolo central de Internet pode despoletar comportamentos inesperados da rede. A Cloudflare foi um dos primeiros operadores TLS principais a implementar o TLS 1.3 em grande escala; quando navegadores - como o Firefox e o Chrome - começaram a permiti-lo de forma experimental, observaram uma taxa significativamente mais elevada de falhas de ligação em comparação com o TLS 1.2. A raiz da causa destas falhas prendeu-se com a ossificação da rede, i.e., a tendência das "middleboxes"— dispositivos de rede entre os clientes e os servidores, que monitorizam e, nalguns casos, interceptam tráfego — de escrever software que espera que o tráfego tenha um determinado aspeto e comportamento. Alterar o protocolo antes de as middleboxes terem tido a oportunidade de atualizar o seu software levou a que elas tentassem analisar pacotes que não reconheciam, despoletando erros de software que, nalguns casos, fizeram com que as ligações caíssem por completo.
Este problema estava de tal forma disseminado que, ao invés de aguardar que os operadores de rede atualizassem o seu software, o conceito do TLS foi alterado para mitigar o impacto da ossificação da rede. A solução engenhosa encontrada foi fazer com que o TLS 1.3 "se parecesse" com outro protocolo cuja tolerância era reconhecida nas middleboxes. De forma particular, o formato de transmissão e até os conteúdos das mensagens de handshake foi adaptado para se parecer ao TLS 1.2. É claro que estes dois protocolos não são parecidos — um observador de rede curioso consegue ainda distingui-los—, mas têm um aspeto e comportamento suficientemente parecido para garantir que a maioria das middleboxes existentes não lhes dá tratamentos diferentes. Empiricamente, concluiu-se que esta estratégia reduziu, de forma significativa, a taxa de falha das ligações, em medida suficiente para viabilizar a implementação do TLS 1.3.
Mais uma vez, o ECH representa uma melhoria significativa para o TLS, sob a qual o espectro de ossificação da rede paira intensamente. O ClientHello contém parâmetros, tais como SNI, que já existem no handshake há muito tempo, sendo que não sabemos ainda que impacto advirá da sua encriptação. Para precaver os problemas que a ossificação possa causar durante a implementação, o protocolo ECH foi concebido para se assemelhar, tanto quanto possível, a um handshake TLS 1.3 padrão. A diferença mais notável é a própria extensão ECH: se as middleboxes a ignorarem — como é suposto, caso cumpram a norma TLS 1.3 — então o resto do handshake terá um aspeto e comportamento bastante normal.
Permanece, no entanto, a incerteza acerca da suficiência desta estratégia quanto à implementação em larga escala do ECH. Caso se confirme, é notável que esta nova funcionalidade venha a ajudar a mitigar o impacto de futuras atualizações ao TLS nas operações de rede. A encriptação total do handshake reduz o risco de ossificação, uma vez que ficam visíveis menos características do protocolo onde o software se poderia ossificar. Acreditamos que isto venha, no geral, a ser positivo para a saúde da Internet.
Conclusão
O antigo handshake TLS é (involuntariamente) indiscreto. Os requisitos operacionais tanto de clientes como de servidores levaram a que fossem impostos parâmetros sensíveis à privacidade, como o SNI, que são negociados de forma completamente por encriptar e ficam disponíveis para os observadores de rede. A extensão ECH pretende colmatar esta lacuna, permitindo a encriptação total do handshake. Isto representa uma melhoria significativa para o TLS, que ajudará a preservar a privacidade do utilizador final à medida que o protocolo vai evoluindo.
O padrão ECH é um projeto em curso. À medida que este trabalho prossegue, a Cloudflare está empenhada em fazer a sua parte para garantir que essa atualização importante para o TLS chegue à implementação em grande escala na Internet.