TLS pós-quântico: o que significa HTTPS resistente a quântica em 2026

O TLS pós-quântico é o HTTPS que permanece seguro mesmo contra um atacante munido de um grande computador quântico. Ele substitui a matemática por trás da troca de chaves de hoje — que um computador quântico conseguiria quebrar — por algoritmos concebidos para resistir a ataques quânticos.

Isto não é um projeto de pesquisa distante. Em meados de 2026, mais de 65% do tráfego web humano que passa pela Cloudflare já está criptografado de forma pós-quântica, e o Chrome, o Edge e o Firefox negociam troca de chaves resistente a quântica por padrão sempre que o servidor a suporta. Se você visitou o Google recentemente num navegador moderno, é quase certo que usou TLS pós-quântico sem perceber.

Por que o TLS clássico está em risco

O TLS de hoje apoia-se em dois tipos de matemática de chave pública:

• Troca de chaves (ECDHE, usando X25519 ou P-256) — acorda um segredo compartilhado por um canal aberto.
• Assinaturas (RSA, ECDSA) — prova que o certificado é autêntico.

Ambos dependem de problemas que são difíceis para computadores clássicos — fatorar números grandes (RSA) e o logaritmo discreto em curvas elípticas (ECC). O algoritmo de Shor, executado num computador quântico suficientemente grande, resolve ambos de forma eficiente. Um “computador quântico criptograficamente relevante” (CRQC) ainda não existe, mas a área avança rápido o bastante para que o planejamento tenha deixado de ser “se” e passado a ser “quando”.

Criptografia de chave pública → explica a matemática subjacente que os computadores quânticos ameaçam.

”Colher agora, decifrar depois” — por que isto já é urgente hoje

Você pode achar que não há pressa: nenhum computador quântico consegue quebrar o TLS hoje, então por que migrar agora?

A ameaça é o colher agora, decifrar depois (harvest now, decrypt later — HNDL). Um adversário grava o seu tráfego criptografado hoje e o armazena. Quando um computador quântico se tornar disponível — possivelmente na década de 2030 — ele decifra retroativamente o tráfego armazenado.

Isto torna o prazo para a troca de chaves muito anterior à chegada dos computadores quânticos. Qualquer dado com um longo tempo de vida de confidencialidade — registros de saúde, dados financeiros, segredos governamentais, código-fonte, credenciais — precisa de criptografia resistente a quântica agora, porque a gravação já está acontecendo.

A troca de chaves é urgente. As assinaturas, menos. Não dá para forjar retroativamente uma assinatura sobre um tráfego que já ocorreu — uma assinatura só precisa ser resistente a quântica antes de os computadores quânticos existirem, não antes disso. É por isso que a indústria implantou primeiro a troca de chaves pós-quântica.

Os padrões: ML-KEM e ML-DSA

Em agosto de 2024, o NIST publicou os primeiros padrões pós-quânticos finalizados:

O ML-KEM (Module-Lattice Key Encapsulation Mechanism) é o que já está implantado no TLS. Ele vem em três tamanhos: ML-KEM-512, ML-KEM-768 e ML-KEM-1024. O ML-KEM-768 é o ponto de equilíbrio ideal usado na web.

Troca de chaves híbrida: X25519MLKEM768

Os navegadores não abandonam a criptografia clássica e mudam para pós-quântica pura da noite para o dia. Isso seria imprudente — o ML-KEM é novo, e uma falha poderia comprometer tudo. Em vez disso, o TLS 1.3 usa uma troca de chaves híbrida que combina um algoritmo clássico e um pós-quântico.

O grupo nomeado que você verá em 2026 é o X25519MLKEM768:

X25519MLKEM768 = X25519 (ECDHE clássico)  +  ML-KEM-768 (pós-quântico)

Os dois segredos compartilhados são concatenados (32 bytes do X25519 + 32 bytes do ML-KEM = um segredo combinado de 64 bytes) e alimentam o key schedule do TLS.

A garantia de segurança é “seguro se qualquer um deles se mantiver”. Um atacante tem de quebrar ambos, o X25519 e o ML-KEM-768, para recuperar a chave de sessão. Logo:

• Se o ML-KEM-768 acabar tendo uma falha → o X25519 ainda protege você (contra atacantes clássicos).
• Se um computador quântico quebrar o X25519 → o ML-KEM-768 ainda protege você.

Esse projeto de redundância em duas camadas é o motivo de a abordagem híbrida ser o padrão em todos os lugares, e não a pós-quântica pura.

Onde ela se encaixa no handshake

A troca de chaves híbrida usa o mesmo handshake do TLS 1.3 descrito em O que é o TLS 1.3 →. A única diferença está no key_share: o ClientHello carrega um key share X25519MLKEM768 em vez de um X25519 simples. As chaves ML-KEM são maiores (~1.2 KB contra 32 bytes), então o ClientHello cresce cerca de um kilobyte — geralmente algo desprezível, embora possa ocasionalmente extravasar os limites de pacote em redes restritas.

Ela também continua oferecendo forward secrecy →: um novo par de chaves por conexão, agora em edição pós-quântica.

O que já está implantado em 2026

A peça que ainda não foi concluída em escala são os certificados pós-quânticos — assinar certificados com ML-DSA em vez de RSA/ECDSA. As assinaturas e chaves públicas do ML-DSA são muito maiores (kilobytes contra ~64 bytes), o que incha o handshake e pressiona os limites de tamanho da cadeia de certificados. A Cloudflare planeja usar ML-DSA nas conexões de origem até meados de 2026 e está explorando os Merkle Tree Certificates para manter o tamanho gerenciável, com meta de atingir a pós-quântica completa (incluindo a autenticação) até 2029.

Como verificar se você está usando TLS pós-quântico

No navegador

Abra qualquer site importante no Chrome → DevTools → aba Security → observe os detalhes da conexão. Uma conexão pós-quântica mostra uma troca de chaves como X25519MLKEM768 (ou X25519Kyber768 em versões mais antigas).

Com o OpenSSL 3.5+

openssl s_client -connect cloudflare.com:443 -groups X25519MLKEM768 2>/dev/null   | grep -i "Negotiated TLS1.3 group"
# Esperado: Negotiated TLS1.3 group: X25519MLKEM768

Se você obtiver um erro ou um grupo diferente, ou o seu OpenSSL é mais antigo que o 3.5 ou o servidor ainda não oferece troca de chaves pós-quântica.

Verifique a sua versão do OpenSSL

openssl version
# Necessário: OpenSSL 3.5+ para X25519MLKEM768 nativo

Como ativar isso no seu servidor

Para a maioria dos sites a resposta é atualizar e não desativar — a troca de chaves híbrida pós-quântica é ativada automaticamente assim que a sua stack a suporta.

Nginx / Apache

A troca de chaves pós-quântica reside na sua biblioteca TLS, não na configuração do servidor web. Compile ou execute contra o OpenSSL 3.5+ (ou BoringSSL com ML-KEM). Uma vez vinculado, o X25519MLKEM768 é oferecido automaticamente junto ao X25519 — sem necessidade de nenhuma diretiva nova. Não fixe o ssl_ecdh_curve numa única curva clássica, ou você excluirá o grupo híbrido.

Atrás de uma CDN

O caminho mais simples: coloque o seu site atrás da Cloudflare (ou de outra CDN habilitada para PQC). A conexão do navegador até a borda torna-se pós-quântica imediatamente, sem alterações na sua origem. Foi assim que a maior parte daqueles 65% de tráfego se tornou resistente a quântica — os operadores não tocaram nos seus servidores de origem.

O seu certificado ainda não muda

Você não precisa de um novo certificado para a troca de chaves pós-quântica. O seu certificado RSA ou ECC existente funciona perfeitamente — a troca de chaves híbrida protege a sessão, enquanto o certificado, por ora, ainda usa assinaturas clássicas. Os certificados pós-quânticos (ML-DSA) são uma migração separada e posterior.

Perguntas frequentes

Preciso comprar um “certificado resistente a quântica” especial?

Não. A troca de chaves pós-quântica (a parte urgente) não toca no seu certificado de forma alguma — o seu certificado RSA/ECC atual continua funcionando. Quem hoje vende um “certificado SSL resistente a quântica” está sobretudo fazendo marketing; as assinaturas pós-quânticas de produção (ML-DSA) ainda não são amplamente emitidas pelas ACs públicas.

O TLS pós-quântico é mais lento?

Quase nada. O ML-KEM-768 é computacionalmente rápido — muitas vezes mais rápido que o ECDHE. O custo principal é o tamanho: os key shares maiores acrescentam ~1 KB ao handshake, o que pode custar apenas um round trip extra em redes com limites de pacote muito pequenos. Para a quase totalidade dos usuários a diferença é imperceptível.

Quando os computadores quânticos vão de fato quebrar o RSA?

Ninguém sabe. As estimativas confiáveis vão do início da década de 2030 a “talvez nunca em escala”. Mas, por causa do colher-agora-decifrar-depois, o prazo de implantação para a troca de chaves já chegou — que é exatamente o motivo de os navegadores e as CDNs terem se movido em 2024–2026 em vez de esperar.

E o TLS 1.2?

A troca de chaves híbrida pós-quântica é definida apenas para o TLS 1.3. Este é mais um motivo para ativar o TLS 1.3 → — é o único caminho para o HTTPS resistente a quântica. O TLS 1.2 não receberá troca de chaves pós-quântica.

O ML-KEM é o mesmo que o Kyber?

Sim — o ML-KEM é a versão padronizada pelo NIST do algoritmo antes chamado CRYSTALS-Kyber. Versões mais antigas de navegadores e ferramentas mostram Kyber768; as implantações padronizadas usam ML-KEM-768. Eles são intimamente relacionados, mas não idênticos bit a bit, então um cliente com o padrão final e um servidor pré-padrão podem falhar ao negociar. Em 2026 o ecossistema já migrou em grande parte para o ML-KEM final.

Devo fazer algo agora mesmo?

Para um site típico: certifique-se de estar no TLS 1.3, mantenha a sua biblioteca TLS atualizada (OpenSSL 3.5+) e considere uma CDN habilitada para PQC se você lida com dados sensíveis de vida longa. Isso já é suficiente para ter troca de chaves resistente a quântica hoje. Os certificados pós-quânticos podem esperar o amadurecimento dos padrões e das ferramentas das ACs.