TLS pós-quântico: preparar certificados não é só trocar o algoritmo

A Cloudflare anunciou planos de operar uma autoridade certificadora pública com emissão padrão gratuita e suporte a Merkle Tree Certificates, os MTCs.[7] O objetivo é enfrentar o custo da autenticação pós-quântica de servidores na Web PKI.[7] A meta anunciada é o início de 2027 para inclusão no novo repositório de raízes resistentes a ataques quânticos do Chrome, sujeita a avaliação e aceitação.[7]

A notícia não é uma autorização para migrar toda a infraestrutura hoje. É um aviso de que a mudança alcança formato, distribuição de confiança e operação, não apenas a escolha de um algoritmo.

O que muda para quem desenvolve

Na proposta, a autoridade agrupa emissões numa árvore de Merkle de inclusão crescente, assina estados da árvore e fornece provas compactas de inclusão baseadas em hashes.[7] Em vez de transportar uma assinatura pesada individual para cada certificado, o desenho permite compartilhar estados autenticados.[7]

A otimização usa landmarks, distribuídos aos clientes por um canal de atualização separado.[7] Quando o cliente possui o estado relevante, o servidor pode apresentar uma prova relativa a ele; clientes sem landmarks adequados precisam de um caminho alternativo.[7]

Minha leitura: parte do custo sai da conexão e passa para uma infraestrutura de atualização e sincronização de confiança. Isso torna importante testar clientes novos, desatualizados e com conectividade limitada, não apenas o caso otimizado.

A Cloudflare relata um experimento com 50% do Chrome Beta 146, provas menores que 1 kB no caso otimizado e latência mediana 9% menor que a de uma cadeia clássica.[7] O experimento utilizou assinaturas clássicas, e grande parte do ganho veio da eliminação de intermediários.[7] Portanto, não use esses números como benchmark independente de uma infraestrutura pós-quântica completa.

Como aplicar

O primeiro trabalho útil não depende de adotar MTC. Faça um inventário dos pontos que terminam TLS, das bibliotecas utilizadas, dos clientes relevantes e do mecanismo de renovação de certificados. Registre quem pode atualizar cada parte e quais dependências impedem uma mudança.

Separe duas perguntas: como a conexão estabelece as chaves e como autentica a identidade do servidor. A reportagem trata a autenticação como uma frente que não se resolve apenas com a troca de chaves.[7] Essa distinção deve aparecer no plano de migração.

Como exercício de operação, use um ambiente de teste para renovar um certificado e verificar os clientes suportados antes e depois da troca. Simule uma falha do mecanismo de renovação, confirme o alerta e documente a recuperação. Não publique um serviço com certificado inválido para testar a reação dos usuários.

Para um futuro piloto MTC, exija critérios de compatibilidade, negociação e caminho alternativo. Meça os casos com e sem o estado necessário no cliente. O objetivo é conhecer as condições do resultado, não reproduzir um percentual de uma demonstração do fornecedor.

Cuidados e limites

A especificação MTC continua em desenvolvimento no IETF, e a arquitetura prevê convivência com certificados tradicionais.[7] Essa convivência não torna a autenticação de clientes legados automaticamente resistente a ataques quânticos.[7]

Transparência também não substitui verificar controle do domínio e vincular corretamente identidade e chave pública.[7] Há confiança e responsabilidades operacionais a preservar. Preparar renovação, inventário e atualização de clientes tem valor agora; assumir disponibilidade e confiança universal de uma nova CA não tem respaldo no anúncio.

Fonte

[7] Fonte: InfoQ, com conferência do texto técnico de base da Cloudflare