RFC 10015 descontinua métodos antigos de troca de chaves no TLS 1.2 e DTLS 1.2

A IETF publicou a RFC 10015, um documento de padrão (Standards Track) que descontinua o uso de dois métodos de troca de chaves em (D)TLS 1.2: Diffie-Hellman sobre corpo finito (FFDH/FFDHE) e RSA. O texto também desencoraja o uso de cifras baseadas em ECDH estático (não efêmero).

As regras valem apenas para (D)TLS 1.2, já que TLS 1.0 e 1.1 foram descontinuados pela RFC 8996 e o TLS 1.3 ou não usa esses algoritmos ou não expõe as opções de configuração afetadas. A RFC atualiza 17 documentos anteriores, entre eles a RFC 5246 (a própria especificação do TLS 1.2) e a RFC 9325 (BCP 195, com as recomendações atuais de uso do TLS).

O que muda na prática

O documento usa linguagem normativa forte. Nos casos de FFDH não efêmero, FFDHE e RSA, a determinação é MUST NOT:

• Diffie-Hellman efêmero sobre corpo finito (FFDHE): clientes NÃO DEVEM oferecer e servidores NÃO DEVEM selecionar essas cifras em conexões (D)TLS 1.2.
• RSA como troca de chave: clientes NÃO DEVEM oferecer e servidores NÃO DEVEM selecionar essas cifras. Elas já estavam marcadas como "não recomendadas" no registro "TLS Cipher Suites".
• FFDH não efêmero: proibido em (D)TLS 1.2, incluindo certificados com parâmetros DH fixos (rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh).
• ECDH estático: clientes e servidores NÃO DEVERIAM (SHOULD NOT) negociar essas cifras, requisito que já constava na RFC 9325.

A IANA passou a marcar todas as cifras listadas com "D" na coluna "Recommended" do registro "TLS Cipher Suites". Vale notar que a RFC permite (MAY) o uso de FFDHE em TLS 1.3, onde os problemas descritos não se aplicam.

Por que descontinuar

O documento detalha as fragilidades de cada método. Para o FFDHE, os pontos incluem: falta de mecanismo de negociação de grupo, presença de subgrupos pequenos que abrem espaço para ataques, uso disseminado de grupos customizados que o cliente não consegue validar, e o uso comum de grupos de 1024 bits (o máximo que garante suporte amplo) que deixa margem estreita de segurança frente ao recorde atual de logaritmo discreto, que está em 795 bits. Há ainda o ataque de canal lateral Raccoon quando os segredos não são plenamente efêmeros.

Já o RSA como troca de chave não oferece sigilo futuro (forward secrecy) por construção e pode ser vulnerável ao ataque de Bleichenbacher, cujas variantes, segundo a RFC, ressurgem a cada poucos anos por conta da dificuldade de implementar corretamente as contramedidas (ROBOT, DROWN, entre outras). Como não há separação de domínio de chaves em (D)TLS 1.2, um único endpoint vulnerável compromete todos os que compartilham a mesma chave RSA.

O que isso significa para quem opera infra no Brasil

Para equipes que mantêm servidores web, gateways de API, balanceadores de carga e serviços expostos via TLS, o recado é revisar as suítes de cifras configuradas. Ambientes que ainda dependem de troca de chave via RSA ou de cifras TLS_DHE_ e TLS_DH_ em conexões TLS 1.2 estão fora do que o padrão agora recomenda.

Na prática, a migração passa por priorizar TLS 1.3 quando possível e, onde o TLS 1.2 ainda for necessário para compatibilidade, restringir as cifras a alternativas com troca de chave efêmera baseada em curvas elípticas (ECDHE), que preservam sigilo futuro e não estão na lista de descontinuação.

Algumas verificações úteis:

• Auditar a configuração de cifras em servidores e proxies reversos (Nginx, Apache, HAProxy, Envoy).
• Conferir se clientes e SDKs internos ainda ofertam RSA ou FFDHE em ClientHello.
• Checar certificados legados com parâmetros DH fixos, agora explicitamente desencorajados.

Como se trata de um documento de padrão aprovado pelo IESG, a expectativa é que bibliotecas de TLS e ferramentas de teste incorporem essas marcações ao longo do tempo, refletindo o status "D" no registro da IANA. Para times brasileiros que precisam atender requisitos de segurança e conformidade, alinhar a configuração ao BCP 195 atualizado é a forma direta de acompanhar a mudança.

Fonte: Hacker News