Quando a Cloudflare abre uma conexão TLS 1.3 com um servidor de origem, precisa enviar uma proposta de troca de chaves já no primeiro pacote. O servidor ainda não contou quais algoritmos prefere. Se a escolha não serve, ele responde com HelloRetryRequest e o handshake gasta mais uma viagem pela rede.
O Automatic Key Exchange, anunciado em 8 de setembro, troca esse palpite estático por medição. A Cloudflare testa quais grupos cada origem aceita, escolhe a opção mais forte compatível e acompanha o rollout. O objetivo é combinar menos latência com mais conexões protegidas por troca de chaves pós-quântica.
Entre o visitante e o servidor existem dois TLS
Num domínio atrás de reverse proxy, a conexão segura do visitante termina na Cloudflare. Outra conexão liga a Cloudflare à origem. Cada trecho negocia suas próprias chaves e autentica sua contraparte. A novidade atua nesse segundo caminho; ela não muda diretamente o handshake entre navegador e borda.
No TLS 1.3, o cliente envia um ClientHello com os algoritmos suportados e uma ou mais key shares, valores usados para construir o segredo da sessão. Antecipar uma opção permite concluir o handshake em uma ida e volta. Antecipar a opção errada exige que o servidor peça outra.
X25519 era um bom padrão, mas não era universal
Por anos, a Cloudflare iniciava conexões com X25519. É rápido e amplamente suportado, mas as medições mostraram que ele era uma escolha ruim para cerca de 30% das conexões de origem analisadas. Alguns servidores preferem curvas P-256, P-384 ou P-521. Outros já aceitam a combinação híbrida X25519MLKEM768.
O híbrido usa uma troca clássica e uma pós-quântica. A ideia é manter a segurança mesmo se uma das famílias perder sua proteção no futuro. Isso reduz o risco de “capture agora, decifre depois”, no qual tráfego criptografado é armazenado na expectativa de que computadores futuros consigam quebrá-lo.
Há um custo de compatibilidade. Uma key share X25519 ocupa 32 bytes; a X25519MLKEM768 citada pela Cloudflare ocupa 1.216 bytes. O ClientHello pode atravessar o limite de um pacote, expondo falhas de servidores e middleboxes antigos que não lidam bem com a fragmentação.
Medir fora do tráfego antes de mudar o tráfego
O sistema faz handshakes leves fora do caminho das requisições de produção, oferecendo individualmente X25519, curvas NIST e X25519MLKEM768. Assim, descobre tanto o suporte do servidor quanto problemas nos equipamentos entre a borda e a origem.
- Testa os grupos aceitos por cada origem TLS 1.3.
- Pondera os resultados pelo tráfego real dos subdomínios.
- Prefere o híbrido pós-quântico; se ele não existir, escolhe a curva clássica compatível.
- Libera a preferência para uma parte pequena do tráfego.
- Compara falhas e
HelloRetryRequestcom a linha de base e reverte se houver piora. - Repete a medição diariamente para acompanhar mudanças no servidor.
O rollout gradual limita o pior caso. Uma preferência inadequada pode acrescentar uma viagem durante a fase de teste, em vez de derrubar todas as conexões até alguém alterar a configuração manualmente.
Os números mostram onde a viagem extra pesava
No grupo de origens já analisado, a taxa geral de HelloRetryRequest caiu de cerca de 52% para 3,7%. A latência p90 do estabelecimento de conexão diminuiu em mais de 150 ms. Entre conexões pós-quânticas, 99,2% passaram a concluir o handshake sem retry, e o tráfego protegido nessa rota chegou a 45 bilhões de conexões diárias.
Esses resultados são medições publicadas pela própria Cloudflare e descrevem o grupo já incluído no rollout. Não devem ser convertidos em promessa de 150 ms para toda página. Requisições que reutilizam conexões keep-alive não fazem um novo handshake e não recebem esse ganho. Cache hit na borda talvez nem precise chegar à origem.
Automático não instala suporte no seu servidor
O recurso está ativo por padrão para domínios existentes e novos, mas só pode escolher X25519MLKEM768 quando a origem e o caminho de rede aceitam o algoritmo. A Cloudflare encontrou suporte pós-quântico em pouco mais de 12% das origens individuais observadas. As demais continuam numa opção clássica compatível e ainda podem evitar retries desnecessários.
Versões atuais de OpenSSL, BoringSSL e rustls já oferecem suporte, porém configurações antigas de curvas podem substituir os padrões novos. A auditoria precisa incluir load balancer, WAF, proxy e qualquer equipamento que termine ou inspecione TLS, não apenas o servidor da aplicação.
Cuidado com o modo de conformidade
O painel permite restringir a negociação a híbridos pós-quânticos ou a grupos compatíveis com FIPS. Essas opções expressam uma obrigação, não uma melhoria gratuita. Se você exigir exclusivamente X25519MLKEM768 e a origem não suportar o grupo, não haverá algoritmo em comum e todas as conexões TLS 1.3 poderão falhar.
Para a maioria dos sites, manter as restrições desmarcadas permite que o sistema escolha a melhor opção disponível e recue com segurança. Requisitos rígidos devem entrar somente depois de teste em todos os endpoints e de um plano para origens legadas.
O que verificar na prática
- Confirme que a origem oferece TLS 1.3.
- Use uma ferramenta que teste o endereço da origem, não apenas o hostname já protegido pela Cloudflare.
- Atualize bibliotecas e revise listas manuais de curvas.
- Observe falhas de handshake, retries e latência de cache misses.
- Não ative restrição pós-quântica exclusiva antes de comprovar suporte de ponta a ponta.
A parte mais interessante do Automatic Key Exchange não é escolher uma curva “vencedora”. É reconhecer que o ecossistema muda, medir a capacidade real e adaptar a primeira proposta sem transformar cada administrador em especialista em criptografia. No TLS, acertar de primeira economiza tempo; medir antes de impor evita indisponibilidade.
