Java e TLS pós-quântico: Protegendo suas conexões com o JDK 27

Java e TLS pós-quântico

Olá, Habr!

O JEP 527 adiciona suporte no JDK 27 para post-quantum hybrid key exchange para TLS 1.3. Se o aplicativo estiver na pilha JSSE padrão através do javax.net.ssl, após a transição para o JDK 27 com o JEP 527, ele poderá usar o novo key exchange híbrido no TLS 1.3.

O que será abordado neste artigo

• O que é TLS
• O problema “harvest now, decrypt later”
• O que o JEP 527 adiciona
• Por que o key exchange é híbrido
• O que muda para o desenvolvedor
• O que pode quebrar

1. O que é TLS

TLS (Transport Layer Security) é um protocolo para uma conexão de rede segura. Ele é usado em HTTPS, conexões a bancos de dados, APIs externas e mTLS interno.

• Handshake é a fase inicial de uma conexão TLS. Nela, o cliente e o servidor negociam a versão do protocolo, parâmetros de segurança, verificam certificados e preparam as chaves.
• TLS negotiation é a negociação de parâmetros dentro do handshake: versões do TLS, algoritmos, grupos suportados e outras configurações que ambos os lados podem usar.
• Key exchange é a parte do handshake onde as partes obtêm um segredo compartilhado. Então, a partir desse segredo, as chaves são derivadas, com as quais o tráfego do aplicativo é criptografado.

2. O problema “harvest now, decrypt later”

O TLS 1.3 clássico geralmente usa ECDHE (Ephemeral Elliptic-Curve Diffie-Hellman), um mecanismo de key exchange familiar e amplamente utilizado. Ele oferece forward secrecy. Se, em um ano, a chave privada do certificado do servidor vazar, as antigas sessões TLS não devem ser reveladas automaticamente. Os segredos para essas sessões foram criados com chaves temporárias durante o handshake, e não diretamente com a chave privada do certificado.

Mas os algoritmos clássicos em curvas elípticas têm uma perspectiva desagradável. Um computador quântico suficientemente poderoso poderá atacar essa matemática de forma diferente de um computador comum. Isso não significa que amanhã de manhã todo o HTTPS será quebrado, mas há uma ameaça de harvest now, decrypt later. Um invasor pode gravar o tráfego criptografado agora, ele não pode descriptografá-lo agora. Mas se os dados forem valiosos em cinco ou dez anos, a questão surge: o que acontecerá quando ataques quânticos mais fortes aparecerem? Para um código único de 30 segundos, isso não importa. Para dados médicos ou pessoais, documentos financeiros e contratos comerciais - já é mais interessante. É por isso que a migração criptográfica começa com antecedência, quando ainda há tempo para atualizar plataformas, protocolos e infraestrutura com calma.

3. O que o JEP 527 adiciona

O JEP 527 adiciona suporte no JDK para três grupos nomeados híbridos TLS 1.3:

• X25519MLKEM768
• SecP256r1MLKEM768
• SecP384r1MLKEM1024

A opção mais importante para um desenvolvedor de aplicativos é X25519MLKEM768. É ele que está incluído na lista padrão de grupos nomeados e é colocado em primeiro lugar. Simplificando, o cliente Java começa a dizer ao servidor:

• Eu suporto X25519MLKEM768.
• Eu também suporto x25519 normal.
• Se puder, vamos escolher a opção híbrida.
• Caso contrário, vamos concordar com a opção antiga.

Essa mudança não está no HTTP, REST ou no código HttpClient, mas dentro do handshake TLS. Se o servidor também suportar X25519MLKEM768, as partes podem escolher o hybrid key exchange. Se não suportar, um fallback para um grupo normal, como x25519, deve funcionar. Mas por causa de proxies, WAFs, terminadores TLS, bibliotecas antigas e configurações personalizadas, tudo isso ainda precisa ser verificado em sua própria infraestrutura.

4. Por que o key exchange é híbrido

Híbrido aqui significa: tanto o ECDHE clássico quanto o ML-KEM pós-quântico são usados. ML-KEM é um KEM pós-quântico padronizado. Anteriormente, esse algoritmo era conhecido como Kyber. No Java, os blocos de construção já apareceram antes:

• JEP 452 adicionou a API KEM;
• JEP 496 adicionou ML-KEM;
• JEP 527 usa isso no TLS 1.3.

Por que não mudar imediatamente para um key exchange pós-quântico puro? Porque as migrações criptográficas são melhores feitas com cuidado. Os algoritmos clássicos foram estudados por muito tempo e são bem otimizados. Os algoritmos pós-quânticos são mais novos. Eles têm tamanhos diferentes de chaves e mensagens. Eles têm um perfil de desempenho diferente. Eles ainda precisam ser testados em massa na infraestrutura. A abordagem híbrida usa ambos os mecanismos de uma vez. Se o ECDHE se tornar um problema devido a ataques quânticos, o ML-KEM permanece. Se um problema desagradável for encontrado no novo algoritmo pós-quântico, a parte clássica permanece. Esta não é uma proteção absoluta contra tudo. Mas esta é uma forma de transição razoável para o enorme ecossistema TLS.

5. O que muda para o desenvolvedor

Se você estiver usando o Java TLS padrão através do javax.net.ssl, o código do aplicativo pode não mudar em tudo. Por exemplo:

java
HttpClient client = HttpClient.newBuilder()
        .version(HttpClient.Version.HTTP_2)
        .build();

Neste código, não há ML-KEM nem X25519MLKEM768. Mas o handshake TLS é feito pelo JDK. Isso significa que, após atualizar o runtime, o comportamento do handshake pode mudar. Este é o principal ponto prático.

6. O que pode quebrar

A negociação TLS deve fornecer compatibilidade com versões anteriores. O cliente oferece um grupo híbrido e grupos normais. O servidor escolhe o que suporta. Se o híbrido não for suportado, x25519 normal é escolhido. Os problemas começam onde a infraestrutura se comporta de forma estranha. Por exemplo:

• proxy antigo não gosta do grande ClientHello;
• WAF (Web Application Firewall) analisa incorretamente os novos grupos nomeados;
• o terminador TLS (nginx ou balanceador de carga) não foi atualizado por vários anos;
• uma lista de grupos é definida rigidamente no aplicativo sem fallback;
• outro provedor TLS é usado em vez de JSSE;
• diferentes serviços em um circuito mTLS funcionam em runtimes muito diferentes.

Um grande ponto prático: o key exchange pós-quântico aumenta o tamanho da key share. O ClientHello pode ficar maior. A infraestrutura moderna deve lidar com isso. Mas proxies, WAFs ou terminadores TLS antigos podem não conseguir lidar com tal handshake. Os sintomas são geralmente os seguintes:

• handshake timeout;
• SSLHandshakeException;
• connection reset;
• erro apenas através de um proxy específico;
• funciona de uma rede, não funciona de outra.

Conclusão

O JEP 527 atualiza o key exchange TLS 1.3 na implementação JSSE padrão do Java. O código do aplicativo para o cliente HTTP geralmente não precisa ser alterado por causa disso. O comportamento do handshake TLS muda no nível do JDK.

Após a transição para o JDK 27, o cliente Java poderá preferir X25519MLKEM768 se o servidor o suportar. Se o servidor não suportar o grupo híbrido, um fallback para grupos clássicos, como x25519, deve ser usado.

Antes da migração, vale a pena verificar jdk.tls.namedGroups, SSLParameters personalizados, endpoints críticos, proxies e terminadores TLS. Também é importante entender onde o TLS realmente termina: no aplicativo Java, no nginx, no balanceador de carga ou em outro componente.

O JEP 527 não torna o sistema totalmente protegido contra ataques quânticos. Ele adiciona suporte no Java para um key exchange híbrido pós-quântico para TLS 1.3. Para a equipe do aplicativo, esta é uma razão para verificar o handshake TLS ao fazer a transição para o JDK 27.

Referências

• JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3 - https://openjdk.org/jeps/527
• JEP 452: Key Encapsulation Mechanism API - https://openjdk.org/jeps/452
• JEP 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism - https://openjdk.org/jeps/496

Se você gostou do artigo, seja bem-vindo ao meu blog!

Releases seguros para você!