A Mozilla anunciou a inclusão de suporte para usuários do ramo estável do Firefox para o mecanismo ECH (Encrypted Client Hello), que dá continuidade ao desenvolvimento da tecnologia ESNI (Encrypted Server Name Indication) e é projetado para criptografar informações sobre os parâmetros das sessões TLS , como o nome de domínio solicitado. O código para trabalhar com ECH foi originalmente adicionado à versão Firefox 85, mas foi desabilitado por padrão. O Chrome gradualmente começou a incluir suporte ECH a partir do lançamento do Chrome 115.
Além de se conectar com servidor As informações do domínio solicitado vazam via DNS. Para proteção completa, além do ECH, você deve usar DNS sobre HTTPS ou DNS sobre TLS para criptografar o tráfego DNS. O Firefox não usará o ECH sem que o DNS sobre HTTPS esteja habilitado nas configurações. Você pode verificar a compatibilidade com ECH no seu navegador nesta página.
Um dos fatores que permitiram o suporte ECH por padrão no Firefox foi a inclusão do suporte ECH pela Cloudflare em sua rede de distribuição de conteúdo há alguns dias. Do lado prático, como os dados sobre os hosts solicitados ao usar o ECH ficam ocultos da análise, a filtragem e o bloqueio de sites indesejados usando o Cloudflare CDN agora exigirão o bloqueio de toda a rede Cloudflare, o bloqueio de todas as solicitações do ECH ou a organização da interceptação HTTPS usando certificados raiz falsos no sistema do usuário.
Inicialmente, para organizar o trabalho em um endereço IP de vários sites HTTPS, foi utilizada a extensão TLS SNI, na qual o nome do host solicitado era indicado na mensagem ClientHello transmitida antes de estabelecer um canal de comunicação criptografado. Este recurso possibilitou distribuir solicitações entre hosts virtuais em um estágio inicial do processamento da conexão, mas também possibilitou do lado do ISP filtrar seletivamente o tráfego HTTPS e analisar quais sites o usuário abre, o que não permitiu obter total confidencialidade ao usar HTTPS.
Para resolver este problema e evitar o vazamento de informações sobre o site solicitado, foi posteriormente proposta uma extensão ESNI que implementa criptografia de dados com o nome do host. Durante a implementação do ESNI, foi revelado que o mecanismo proposto não cobre todas as fontes possíveis de vazamento de dados do host e seu uso não é suficiente para garantir a total confidencialidade das sessões HTTPS. Em particular, ao retomar uma sessão previamente estabelecida, o nome de domínio em texto não criptografado continuou a ser especificado entre os parâmetros da extensão TLS PSK (Pre-Shared Key). Além disso, os esforços para implementar a ESNI identificaram problemas de compatibilidade e escalabilidade que impediram a adoção generalizada da ESNI.
Tendo em conta as deficiências identificadas do ESNI, foi desenvolvido um novo mecanismo ECH universal que permite encriptar os parâmetros de quaisquer extensões TLS. Tecnicamente, a principal diferença entre ECH e ESNI é que, em vez de campos individuais, toda a mensagem ClientHello é criptografada de uma só vez. ECH envolve a divisão do ClientHello em duas mensagens separadas - a mensagem criptografada ClientHelloInner (SNI Inner) e a mensagem ClientHelloOuter subjacente não criptografada (SNI Outer). Um SNI Outer não criptografado carrega dados não confidenciais, como a versão TLS e uma lista de cifras usadas, bem como um nome de domínio comum que não se sobrepõe ao nome real do domínio solicitado. Por exemplo, para todos os clientes Cloudflare, o SNI Outer não criptografado especifica o host comum "cloudflare-ech.com", mas o nome real do host solicitado é transmitido no SNI Inner criptografado e não está disponível para análise.

O ECH também utiliza um esquema de distribuição de chaves de criptografia diferente: as informações da chave pública são transmitidas em registros DNS HTTPSSVC em vez de registros TXT. A criptografia de ponta a ponta autenticada, baseada no mecanismo HPKE (Hybrid Public Key Encryption), é usada para obter e criptografar a chave. O ECH também suporta a retransmissão segura de chaves do servidor, o que pode ser útil em caso de rotação de chaves. servidor e para resolver problemas com a recuperação de chaves desatualizadas do cache DNS.
Fonte: opennet.ru
