Cloudflare reduz retransmissões de handshake TLS de 52% para 3,7% com medição por origem

A Cloudflare publicou dados de um ajuste silencioso, mas com efeito prático mensurável: uma mudança na forma como ela negocia TLS com os servidores de origem por trás da sua CDN. O resultado, segundo a empresa, foi derrubar a taxa de HelloRetryRequest (a retransmissão que adiciona um round trip extra ao handshake) de cerca de 52% para 3,7% nas origens escaneadas, removendo mais de 150 ms da latência p90 do handshake (InfoQ).

O chute de anos que o TLS 1.3 obriga a fazer

O TLS 1.3 exige que o cliente escolha um algoritmo de troca de chaves (key agreement) já no primeiro pacote, o ClientHello, antes de saber o que a origem realmente suporta. Acertar o algoritmo fecha o handshake em um round trip. Errar força a origem a responder com um HelloRetryRequest, o cliente reenvia um segundo ClientHello, e a conexão passa a custar dois round trips em vez de um.

A Cloudflare vinha resolvendo isso com uma suposição fixa: X25519 para toda origem na internet, porque mais de 95% dos servidores suportam esse algoritmo. Só que medir de fato revelou que esse chute era ruim em cerca de 30% das conexões de origem. Mais de 6% das origens preferem P-256 ou P-384 em vez de X25519, o que significa que essas conexões pagavam um round trip extra por um motivo puramente clássico, sem nenhuma relação com criptografia pós-quântica.

O que o Automatic Key Exchange faz de diferente

A extensão, batizada de Automatic Key Exchange e derivada do Automatic SSL/TLS já existente, sonda cada origem fora do caminho de tráfego de produção, testando um grupo de key agreement por vez para descobrir o que aquela origem suporta e prefere. Com base nisso, a Cloudflare passa a liderar o handshake com o algoritmo certo desde o primeiro pacote. Origens são reescaneadas diariamente, então a preferência acompanha trocas de load balancer ou de biblioteca TLS sem intervenção manual.

O recurso já está ligado para todas as zonas existentes e vem ativado por padrão em zonas novas, com um toggle no dashboard em SSL/TLS. Vale notar que a Cloudflare aplica uma única preferência por zona inteira, não por origem individual, o que é uma limitação relevante para quem tem infraestrutura heterogênea atrás do mesmo domínio.

Um efeito colateral interessante da medição ativa: ela descobriu milhares de origens cujo suporte a criptografia pós-quântica nunca tinha aparecido em tráfego passivo, porque muitos servidores aceitam silenciosamente um keyshare clássico em vez de emitir um retry, mesmo quando suportam algo mais forte.

Por que a chave pós-quântica pesava tanto

Um keyshare X25519MLKEM768 (o híbrido pós-quântico) tem 1.216 bytes contra os 32 bytes do X25519, o que empurra o ClientHello para além de um único pacote de rede. O padrão TLS permite ClientHello fragmentado em múltiplos segmentos TCP, mas alguns middleboxes legados e servidores de origem quebram quando isso acontece. Em um estudo anterior da própria Cloudflare, cerca de 0,34% das origens escaneadas falhavam ao completar o handshake quando recebiam um keyshare pós-quântico primeiro.

Por causa disso, desde setembro de 2023 a empresa usava o HelloRetryRequest como válvula de segurança: anunciava suporte pós-quântico, mas liderava com X25519 clássico, exigindo que origens capazes pedissem o upgrade via retry. Na prática, quase todo handshake pós-quântico pagava um segundo round trip obrigatório, o oposto do ganho de segurança que deveria trazer.

Com a medição por origem, esse cenário muda de figura: a fatia de tráfego TLS 1.3 pós-quântico completado sem HelloRetryRequest subiu de 0% para 99,2%. O suporte pós-quântico entre as origens escaneadas cresceu de 0,5% em 2023 para 12,8% hoje, e dentro desse universo já medido, 64% permaneceram em X25519 clássico sem nenhuma mudança na conexão, 33% migraram para X25519MLKEM768 e 3% moveram para outra curva clássica como P-384, P-256 ou P-521. O tráfego pós-quântico diário no cohort escaneado saltou de cerca de 25 bilhões para 45 bilhões de conexões por dia.

O que muda pra quem constrói e opera APIs

Para times que rodam backends atrás da Cloudflare, o ganho de latência se concentra em dois cenários: requisições dinâmicas e cache misses de CDN, situações em que um handshake TLS novo com a origem é obrigatório. Conexões keep-alive já estabelecidas não são afetadas, então o benefício aparece mais em picos de tráfego, cold starts e serviços com baixa taxa de cache hit, não em APIs que já reaproveitam conexões persistentes.

Há também uma nova configuração de Compliance requirements, com opções para exigir apenas pós-quântico híbrido ou apenas algoritmos compatíveis com FIPS. Aqui vale atenção: essas opções restringem o que a Cloudflare pode negociar, não concedem capacidade nova à origem. Forçar pós-quântico híbrido contra uma origem que não suporta X25519MLKEM768 deixa zero algoritmo em comum, e todas as conexões TLS 1.3 para aquela origem falham. Escolher as duas opções simultaneamente é rejeitado se nenhum algoritmo satisfizer ambas ao mesmo tempo.

Quem automatiza infraestrutura via API precisa notar uma mudança silenciosa: a Origin Post-Quantum Encryption API continua disponível, mas as chamadas para ela agora são no-ops, não alteram mais o comportamento de key agreement de uma zona. A Cloudflare já sinalizou que pretende depreciar essa API, sem data definida. Para conferir na prática qual curva está sendo negociada com uma origem específica, dá para usar o cliente bssl do BoringSSL apontando para a porta 443 e checando se o resultado reporta X25519MLKEM768.

O rollout do recurso é conservador: uma nova preferência vai primeiro para uma fatia pequena do tráfego de cada origem, com monitoramento de taxa de falha e retry contra a baseline daquela origem. Se os retries sobem, a mudança é revertida automaticamente, o mesmo padrão que o Automatic SSL/TLS já usa. Segundo a Cloudflare, o pior cenário de um rollback é um round trip extra, nunca uma conexão quebrada.

O que ainda fica em aberto

Troca de chaves resolve só metade do problema de segurança pós-quântica: protege o tráfego de hoje contra descriptografia futura, mas não impede que um atacante com computador quântico forje um certificado clássico e se passe pela origem. A Cloudflare já suporta assinaturas pós-quânticas ML↳Machine learning39 conteúdosClassificador de Sentimentos – Azure MLData · abr 2019Inteligência Artificial e Machine Learning: O que você precisa saberAI · fev 2024Inteligência Artificial: seminário online da USP debate o futuro do aprendizado de máquinaGestão Dev & TI · jun 2021Ver tudo em AI →-DSA desde meados de 2026 em Authenticated Origin Pulls e no Custom Origin Trust Store, o que junto permite autenticação pós-quântica de ponta a ponta até a origem. A própria documentação da empresa avisa que apresentar um certificado ML-DSA não adianta nada se o lado verificador ainda aceitar certificados clássicos, já que um atacante que comprometa a chave clássica consegue se passar pelo peer de qualquer forma.

No roadmap, três itens: granularidade por origem (hoje a preferência é decidida por zona inteira, então uma origem atrasada trava a zona toda), varreduras sob demanda via dashboard e API para reavaliar depois de um upgrade de stack TLS sem esperar o escaneamento diário, e detecção automática de suporte a ML-DSA para desabilitar fallback clássico em clientes que quiserem proteção estrita.

A Cloudflare enquadra todo o esforço contra o que chama de Q-Day, ano de 2029 apontado por algumas estimativas do setor como o horizonte em que a criptografia clássica poderia ser quebrada, e contra ataques de harvest-now-decrypt-later, em que tráfego capturado hoje é guardado para descriptografia futura. Versões recentes de BoringSSL, OpenSSL e rustls já trazem suporte pós-quântico, mas stacks de origem corporativos, load balancers de nuvem e terminadores TLS embarcados seguem cronogramas próprios de atualização, o que explica por que sete em cada oito origens ainda não conseguem usar o híbrido pós-quântico.

Fonte: InfoQ