O primeiro passo pós-quântico que a sua CDN não dá por si
Um engenheiro que abra a página de estado pós-quântico da Cloudflare tem lido boas notícias há três anos sem ter feito nada. No troço entre o navegador de um visitante e a fronteira da Cloudflare, a cifra pós-quântica está ligada por omissão desde 2023, com o acordo de chaves híbrido que hoje se escreve X25519MLKEM768, e nenhum cliente o configurou. Chegou como chega o tempo lá fora.
A 29 de julho essa forma de trabalhar acabou. A Cloudflare anunciou a autenticação pós-quântica no outro troço, entre a sua rede e os servidores de origem que os clientes gerem, com assinaturas ML-DSA. A autenticação não é algo que um intermediário possa tratar em seu nome, porque aquilo que fica provado é o seu servidor. Para a usar, esse servidor tem de guardar e mostrar um certificado assinado com um algoritmo que muito provavelmente nunca viu.
O que foi de facto entregue
São dois os produtos que levam a mudança. O Authenticated Origin Pulls é o mecanismo através do qual a Cloudflare apresenta um certificado de cliente à sua origem, para que esta possa recusar ligações que não tenham passado pela Cloudflare, e aceita agora ML-DSA nos níveis de configuração por zona e por nome de anfitrião. O nível global é indicado como ficando para mais tarde. O Custom Origin Trust Store, que permite a um cliente carregar autoridades de certificação próprias em vez de depender do conjunto público, acolhe agora autoridades que assinam com ML-DSA, de modo que um certificado de origem possa ser validado contra um signatário pós-quântico.
São suportados os três conjuntos de parâmetros da FIPS 204: ML-DSA-44, ML-DSA-65 e ML-DSA-87. O acordo de chaves da ligação continua a ser o híbrido X25519MLKEM768. Por outras palavras, a confidencialidade nesse troço já estava resolvida; o que mudou foi a parte que prova quem está em cada extremo.
Cinco coisas que têm de mudar numa máquina sua
A lista de requisitos é curta e cada ponto cai do seu lado da ligação. Na origem precisa de OpenSSL 3.5.0 ou posterior apenas para conseguir criar uma cadeia de certificados ML-DSA. O certificado tem de ser carregado na codificação apenas de semente que a FIPS 204 define, que não é a que a maioria das ferramentas produz por hábito. O servidor web na origem, o NGINX no próprio exemplo da Cloudflare, tem de ser configurado para apresentar o certificado ML-DSA ou para verificar o certificado de cliente contra ele. Se usar o Custom Origin Trust Store, o modo SSL/TLS da zona tem de ficar em Full (strict). E a confiança no mecanismo vulnerável à computação quântica tem de ser retirada a seguir, porque deixá-la de pé permite a um atacante negociar o caminho antigo e torna o novo meramente decorativo.
Nada disto é exótico. O OpenSSL 3.5.0 saiu a 8 de abril de 2025 como linha de suporte prolongado com atualizações até abril de 2030 e foi a primeira versão a trazer de raiz as três normas pós-quânticas do NIST. A dificuldade não está no número da versão. Está em que a origem costuma ser a máquina menos visitada de todo o parque: um aparelho, uma caixa gerida por um fornecedor, uma máquina virtual que ninguém voltou a construir desde que foi criada, ou um distribuidor de carga cuja camada TLS é problema de outra pessoa até deixar de ser.
A implantação da própria Cloudflare é o argumento a favor de uma fase de ensaio. A 10 de junho de 2026 a empresa teve uma falha em produção durante esta distribuição, provocada pela verificação do campo KeyUsage nos certificados. É um pormenor de uma extensão de certificado, e atingiu uma equipa que vive de construir bibliotecas TLS, sobre infraestrutura que controla de ponta a ponta. Uma empresa de média dimensão que faça a mesma alteração numa quinta-feira à tarde deve contar com encontrar algo parecido.
Porque é que o conjunto recomendado é o mais pequeno
A Cloudflare recomenda o ML-DSA-44 para a maioria das aplicações e descreve-o como a opção de melhor desempenho. É uma decisão técnica defensável e é, ao mesmo tempo, o mais pequeno dos três conjuntos da FIPS 204, situado na categoria de segurança 2 do NIST. A recomendação por omissão mais comum noutros contextos é o ML-DSA-65, categoria 3. As assinaturas pós-quânticas são grandes face às que substituem e, num troço que transporta cada um dos pedidos entre fronteira e origem, a diferença de tamanho é um custo real de latência e de largura de banda, não um custo teórico.
O que conta para um empresário é que aqui nasce uma decisão com o seu nome. Se a sua política de segurança ou o seu auditor já fixaram a categoria 3 para assinar, adotar em silêncio a recomendação da CDN cria uma exceção que terá de explicar. Ponha por escrito o conjunto de parâmetros e a razão, antes que outra pessoa descubra a divergência numa revisão.
O prazo que é real e o que não é
Seja claro quanto à urgência, porque as duas metades do pós-quântico correm mesmo em relógios diferentes. O tráfego cifrado que hoje é gravado pode ser decifrado por uma máquina futura, e é isso que faz do acordo de chaves um problema do presente. Uma assinatura não se falsifica para trás da mesma maneira: ninguém vai usar um computador quântico em 2032 para inventar retroativamente um aperto de mão desta manhã. A razão para começar agora não é estar sob ataque, mas o comprimento da fila atrás desta mudança, que atravessa autoridades de certificação, equipamento, aparelhos de fornecedores e todas as origens de que já se tinha esquecido.
A Cloudflare pôs datas na sua própria fila: segurança pós-quântica completa em todos os produtos até 2029 e uma primeira distribuição de Merkle Tree Certificates do lado do visitante prevista para 2027. São os prazos dela, não os seus. O seu é a próxima auditoria que perguntar o que protege a ligação entre a sua CDN e os seus servidores, e em Portugal é o Centro Nacional de Cibersegurança que dá a referência. A resposta honesta hoje, para quase toda a gente, é criptografia clássica, com um substituto disponível e por usar.
Leia a seguir: Ter vários operadores não significa escolher o caminho | Os domínios da Albânia caíram. Os da Alemanha em maio.
