Cliente criptografado Olá: pronto para o horário nobre?

Na semana passada, dois RFCs relacionados foram publicados:

RFC 9848: Inicializando ClientHello criptografado TLS com ligações de serviço DNS

RFC 9849: Cliente criptografado TLS Olá

Essas extensões TLS já foram discutidas bastante, e Cloudflare, um dos primeiros implementadores e proponentes, já está em uso há algum tempo.

Em meio a uma preocupação crescente com as ameaças à privacidade por parte de interesses governamentais e comerciais, o movimento “criptografar tudo” vem crescendo há algum tempo. A comunidade fez diversas melhorias no TLS, como o TLS 1.3, o protocolo QUIC, a descontinuação do OCSP e os modos DNS criptografados, para proteger melhor a privacidade do tráfego de rede.

Restava um vazamento de dados: para que um cliente estabeleça uma conexão TLS, ele precisa enviar uma mensagem “TLS Client Hello”. Esta mensagem contém vários itens confidenciais, principalmente o nome do host do site ao qual o cliente tenta se conectar (“Indicação do nome do servidor”). Uma das primeiras propostas era apenas criptografar a extensão Server Name Indication. Mas isso não resolve todo o problema, permitindo impressões digitais e outros ataques. Os mesmos princípios básicos propostos para criptografar a extensão do nome do servidor também podem ser aplicados para criptografar a maior parte da mensagem de saudação do cliente, resultando em uma solução mais completa.

Um dos problemas básicos é a troca de material chave. A mensagem de saudação do cliente é a primeira mensagem enviada durante o handshake TLS. Não há oportunidade para o servidor e o cliente negociarem uma chave de criptografia e isso exigiria um segundo aperto de mão. Em vez disso, as saudações de cliente criptografadas aproveitam o registro DNS HTTPS. O registro HTTPS já é usado para negociar HTTP3/QUIC. Agora também é usado para transmitir as chaves necessárias para Encrypted Client Hello (ECH).

Habilitar o ECH é trivial se você estiver usando Cloudflare. Basta “apertar o botão” nas configurações do certificado de borda da Cloudflare. No entanto, não acredito que isso esteja disponível no plano gratuito.

Para testar se um domínio suporta ECH, use uma ferramenta como “dig” para recuperar o registro HTTP:

# dig -t HTTPS dshield.org +short

1 . alpn="h2" ipv4hint=104.26.2.15,104.26.3.15,172.67.70.195 ech=AEX+DQBBawAgACBRVO1kCb5b2znHUOTe+L42PHgEjBSNt4LD/qDNxffkAgAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:20::681a:20f,2606:4700:20::681a:30f,2606:4700:20::ac43:46c3

Observe a parte “ech=”. Sem suporte ECH, você ainda poderá ver um registro HTTPS, mas ele não conterá a parte “ech=”. A string codificada em base64 após “ech=” contém a chave de criptografia pública usada para criptografar o cliente hello. Um bom teste é cloudflare-ech.com, que mostrará se o seu navegador está usando ECH. Você também pode usar esse domínio para verificar se está vendo o registro HTTPS.

Ao usar “dig”, certifique-se de usar uma versão que suporte registros HTTPS. Versões mais antigas talvez não, e mesmo a versão mais recente do dig para macOS não oferece suporte a registros HTTPS. Você verá um aviso (que, como descobri, é facilmente esquecido) e ainda poderá obter respostas de registro “A”:

% dig -t HTTPS dshield.org +short
;; Aviso, ignorando tipo HTTPS inválido

Para todos os analistas de tráfego de rede que rangem os dentes: você pode bloquear registros HTTPS. Isso também impedirá o uso do QUIC, o que pode ser a seu favor. Mas se isso é apropriado ou não para a sua rede é uma pergunta que você deve responder com base no seu negócio.

—
Johannes B. Ullrich, Ph.D. , Reitor de Pesquisa, SANS.edu

Twitter|