Quando o Clássico e o Pós-Quântico se Encontram no TLS: Lições de um Handshake Híbrido em Laboratório
A base criptográfica que sustenta praticamente toda a comunicação segura na internet está com prazo de validade definido. Não se trata de alarme exagerado, mas de um consenso técnico consolidado, que levou o NIST a publicar, em agosto de 2024, os primeiros padrões oficiais de criptografia pós-quântica. Foi a partir dessa constatação que desenvolvemos, em laboratório no SENAI CIMATEC, uma série de experimentos focados em validar, na prática, um handshake TLS híbrido – combinando algoritmos clássicos e pós-quânticos.
O objetivo deste texto é mostrar o que foi feito, o que observamos e, principalmente, o que tudo isso significa para quem trabalha com infraestrutura, segurança da informação, redes ou arquitetura de sistemas.
—
Por que a criptografia clássica deixou de ser suficiente
Os esquemas mais usados hoje na proteção de sessões TLS – RSA e ECC (criptografia de curvas elípticas) – se garantem na dificuldade computacional de resolver problemas como fatoração de inteiros grandes e logaritmo discreto. Para máquinas clássicas, esses problemas são, na prática, intratáveis em tempo razoável.
Essa suposição começa a ruir diante de computadores quânticos de grande porte. O algoritmo de Shor, executado em uma máquina quântica suficientemente robusta, consegue quebrar RSA e ECC em tempo polinomial. Ninguém sabe com precisão quando esse tipo de hardware estará disponível em escala – as previsões oscilam entre algo em torno de 10 a 20 anos -, mas o risco não está no futuro distante: ele já é preocupante hoje.
O motivo é o ataque conhecido como “harvest now, decrypt later” (HNDL): um adversário captura e armazena agora grandes volumes de tráfego criptografado, apostando na capacidade futura de decriptar esse material quando a computação quântica estiver madura. Informações de alta sensibilidade e longa vida útil – propriedade intelectual, dados médicos, acordos estratégicos, registros financeiros – podem estar sendo coletadas neste exato momento para serem decifradas anos depois.
Em outras palavras: a ameaça não nasce no dia em que um computador quântico poderoso ficar disponível. Ela já começou, porque o tráfego protegido apenas por criptografia clássica de hoje pode se tornar texto claro no futuro.
—
A resposta: criptografia pós-quântica e o inevitável mundo híbrido
Para enfrentar esse problema, o NIST padronizou três algoritmos resistentes a ataques de computadores quânticos:
– ML-KEM (FIPS 203) – mecanismo de encapsulamento de chaves, pensado para troca de chaves segura;
– ML-DSA (FIPS 204) – esquema de assinatura digital;
– SLH-DSA (FIPS 205) – alternativa de assinatura baseada em hash.
Na teoria, bastaria substituir os algoritmos clássicos pelos novos e seguir em frente. Na prática, é inviável fazer essa troca “no interruptor”:
– a infraestrutura instalada é imensa e heterogênea;
– há uma grande base de dispositivos legados;
– ferramentas, bibliotecas, hardware de segurança e middlewares nem sempre estão preparados;
– nem todos os navegadores, clientes e serviços suportam PQC.
O resultado inevitável é a convivência por um longo período de ambientes híbridos, nos quais algoritmos clássicos e pós-quânticos operam lado a lado – inclusive dentro do mesmo handshake TLS. Nesse contexto, surgem dúvidas muito concretas:
– Como configurar, de fato, um handshake híbrido?
– O que muda no fluxo do TLS 1.3?
– A infraestrutura de certificação (PKI) atual precisa ser redesenhada?
– Qual o impacto de desempenho?
– Como gerenciar o ciclo de vida de chaves em cenário de transição?
Foi para buscar respostas práticas a essas questões que montamos o experimento em laboratório.
—
Como estruturamos o experimento: seis etapas principais
Toda a pesquisa foi conduzida em ambiente controlado, rodando Rocky Linux 9.5 e utilizando apenas ferramentas de código aberto. Essa foi uma escolha estratégica: qualquer organização com acesso à internet e conhecimento básico de Linux consegue replicar o ambiente, testar variações e adaptar o roteiro à própria realidade.
Etapa 1 – Dissecando o handshake TLS 1.3 “clássico”
Antes de tocar em pós-quântico, era essencial ter uma visão clara do que, de fato, acontece na negociação TLS 1.3 tradicional. Usando Wireshark e tcpdump, analisamos em nível de pacote:
– as mensagens ClientHello e ServerHello;
– a troca de certificados;
– a seleção de algoritmos;
– a derivação das chaves de sessão;
– e o fechamento da negociação segura.
Essa análise forma a linha de base. Sem compreender o handshake clássico em detalhes, qualquer tentativa de avaliar o impacto de algoritmos pós-quânticos vira um exercício de adivinhação.
Etapa 2 – Montagem de uma PKI local
Em seguida, criamos uma Autoridade Certificadora (CA) raiz usando OpenSSL. A partir dela, geramos e assinamos certificados digitais e configuramos a validação de cadeia de confiança em ferramentas como o próprio OpenSSL e o curl.
O propósito foi ter domínio total sobre todo o ciclo de emissão, assinatura e validação dos certificados, permitindo testar cenários de forma controlada – sem depender de terceiros ou de políticas de CAs públicas.
Etapa 3 – Servidor TLS 1.3 com NGINX
Com a PKI pronta, levantamos um servidor NGINX configurado para usar TLS 1.3 e os certificados emitidos pela nossa CA local. Esse servidor funcionou como ambiente “clássico de referência”, sobre o qual introduzimos, depois, as extensões pós-quânticas.
Assim, qualquer anomalia na negociação híbrida poderia ser comparada diretamente com um cenário funcional conhecido.
Etapa 4 – Integração OpenSSL 3.x + OQS Provider
O próximo passo foi “injetar” algoritmos pós-quânticos no ecossistema TLS. Para isso, utilizamos o OQS Provider, módulo desenvolvido pelo projeto Open Quantum Safe para agregar esquemas PQC ao OpenSSL 3.x.
Esse foi o ponto tecnicamente mais sensível do trabalho:
– a solução ainda é explicitamente experimental;
– a documentação é limitada e, muitas vezes, desatualizada;
– erros simples de configuração geram falhas silenciosas ou mensagens crípticas.
Na prática, tivemos de:
– compilar o OpenSSL com suporte ao provider;
– instalar e registrar o OQS Provider;
– configurar os arquivos de política de algoritmos;
– e validar, com testes funcionais e capturas de tráfego, que as novas curvas e KEMs estavam, de fato, sendo negociados.
Etapa 5 – Validação do handshake TLS híbrido
Com o OQS Provider em operação, configuramos cliente e servidor para negociar a suíte de chave híbrida x25519_mlkem512 – uma combinação de:
– X25519 (componente clássico de troca de chaves);
– ML-KEM-512 (componente pós-quântico, compatível com o padrão NIST FIPS 203).
O resultado foi claro:
– o handshake híbrido funcionou em ambiente de laboratório;
– a PKI tradicional, com certificado ECDSA P-256, permaneceu totalmente válida;
– a alteração ocorreu exclusivamente na camada de troca de chaves, sem exigir mudanças estruturais na hierarquia de confiança.
Em outras palavras: é possível manter certificados e cadeia de confiança clássicos, enquanto se endurece a troca de chaves com mecanismos resistentes à computação quântica.
Etapa 6 – KMS e crypto-agility em cenário de transição
Por fim, mapeamos o ciclo de vida criptográfico em um Key Management System (KMS) orientado à transição para PQC:
– geração de pares de chaves clássicas, pós-quânticas e híbridas;
– armazenamento seguro (incluindo uso ou não de HSM e cofre de segredos);
– políticas de rotação de chaves alinhadas ao risco de HNDL;
– revogação e expiração em ambientes com múltiplos algoritmos ativos;
– versionamento de políticas criptográficas para permitir crypto-agility – isto é, a capacidade de trocar algoritmos, tamanhos de chave e combinações híbridas sem redesenhar todo o sistema.
A principal constatação foi que a migração não é simplesmente “habilitar um novo algoritmo” no servidor, mas redesenhar processos de gestão de chaves para aceitar coexistência, experimentação e substituição rápida.
—
O que tudo isso significa para infra, segurança e arquitetura
Do ponto de vista de quem projeta ou opera sistemas, algumas lições práticas emergem da validação do handshake híbrido:
1. A PKI atual não precisa ser jogada fora imediatamente
É possível manter certificados RSA ou ECDSA enquanto se fortalece a troca de chaves com KEMs pós-quânticos. Isso reduz drasticamente o impacto inicial da adoção de PQC, já que o maior impacto fica concentrado na camada de TLS e não na substituição completa da infraestrutura de certificação.
2. O gargalo está na compatibilidade de clientes e bibliotecas
Navegadores, aplicativos móveis, agentes, proxies e middlewares nem sempre aceitam novas suítes híbridas. Em muitos casos, será necessário atualizar bibliotecas TLS, ajustar configurações ou, pelo menos por um tempo, manter caminhos paralelos (clássico e híbrido).
3. Teste de desempenho é obrigatório
A introdução de algoritmos pós-quânticos tende a aumentar tamanho de chaves, mensagens e operações criptográficas. Em laboratório, a sobrecarga foi aceitável para o cenário testado, mas isso varia por hardware, volume de conexões e perfil de uso. É fundamental medir latência de handshake, consumo de CPU e memória, especialmente em aplicações de alta escala.
4. Crypto-agility deixa de ser “boa prática” e passa a ser requisito
Com o ritmo acelerado de padronização e a possibilidade de novas quebras teóricas, sistemas precisam ser desenhados desde já para trocar algoritmos de forma rápida e controlada. Soluções rígidas, em que qualquer mudança criptográfica exige reescrever parte da aplicação, se tornam um risco operacional.
—
Passos concretos para começar a jornada pós-quântica
Com base no experimento e nas dificuldades encontradas, alguns passos práticos se destacam para organizações que ainda não começaram a se preparar:
– Inventariar dependências criptográficas
Mapear quais protocolos, bibliotecas e hardwares estão em uso (TLS, VPNs, mensageria, banco de dados, HSMs, smartcards etc.) e quais algoritmos suportam hoje. Este inventário é o insumo básico para qualquer plano de transição.
– Classificar dados por longevidade e sensibilidade
Nem toda informação precisa resistir por décadas. Priorize para proteção pós-quântica os dados que terão valor estratégico ou legal no longo prazo.
– Criar um ambiente de laboratório dedicado
Reproduzir, com o máximo de fidelidade possível, o tipo de tráfego e arquitetura em uso na produção, mas com liberdade para experimentar OpenSSL + OQS Provider, bibliotecas alternativas e configurações híbridas.
– Definir uma política de algoritmos e tamanhos de chave
Formalizar, em um documento interno, quais algoritmos são aceitos hoje, quais serão testados a seguir e qual é o plano para introduzir KEMs e esquemas de assinatura pós-quânticos.
– Planejar a integração com KMS e HSMs
Entender como o gerenciamento de chaves vai lidar com novos tipos de chave (clássicas, PQC e híbridas), inclusive em módulos de segurança de hardware que, muitas vezes, foram desenhados para RSA/ECC.
—
Desempenho e impacto operacional: o que esperar
Embora o nosso experimento tenha sido conduzido em escala de laboratório, alguns comportamentos já dão pistas do que deve ocorrer em produção:
– Tamanho das mensagens de handshake tende a crescer com o uso de KEMs pós-quânticos, o que pode ter impacto em ambientes com alta latência ou restrições de banda;
– Sobrecarga de CPU é maior na fase de negociação, mas, uma vez estabelecida a sessão, o tráfego de dados pode continuar usando algoritmos simétricos já consolidados (como AES-GCM ou ChaCha20-Poly1305);
– Caches de sessão e mecanismos de resumção de conexão ganham importância, pois reduzem a necessidade de refazer handshakes pesados com muita frequência.
Isso reforça a necessidade de testes de carga específicos para o cenário híbrido, evitando adotar PQC “no escuro” e descobrir gargalos só depois da implantação.
—
Riscos de adiamento e o custo de não agir
Ignorar a transição pós-quântica não elimina o problema – só o adia e encarece. Quanto mais tempo se deixa para depois:
– mais aplicações legadas vão acumular dependências rígidas de RSA/ECC;
– mais dados sensíveis serão trafegados sem proteção pós-quântica, alimentando o vetor HNDL;
– mais cara e caótica será a migração, quando finalmente se tornar inadiável.
Organizações altamente reguladas ou com forte dependência de sigilo de longo prazo (governo, defesa, financeiro, saúde, P&D) tendem a sentir o impacto primeiro, mas a mudança alcança qualquer entidade que deseje manter a confidencialidade de comunicações ao longo de anos.
—
Conclusão: o handshake híbrido como ensaio geral do futuro
Validar um handshake TLS híbrido em laboratório mostrou, de forma concreta, que:
– é tecnicamente viável combinar algoritmos clássicos e pós-quânticos na camada de troca de chaves;
– a PKI atual pode continuar operando, ao menos na fase inicial da migração;
– o grande desafio não é apenas criptográfico, mas de engenharia de sistemas, gestão de chaves, compatibilidade e desempenho;
– a postura mais prudente não é esperar o “dia do computador quântico”, mas começar agora a experimentar, medir e planejar.
O encontro entre o clássico e o pós-quântico no TLS não é um evento pontual, e sim um período de convivência longa, com ajustes constantes. Cada laboratório que valida um handshake híbrido hoje está, na prática, ensaiando a arquitetura de segurança que sustentará a internet nas próximas décadas.
Para quem cuida de infraestrutura, segurança ou arquitetura, a mensagem é direta: a hora de aprender, testar e errar barato é agora, em ambiente controlado – não no momento em que a urgência bater à porta.