Resumo

  • No TLS/DTLS 1.2, o RFC 10015 determina que clientes não ofereçam e servidores não selecionem suítes FFDH, FFDHE ou de troca RSA; ECDH estático fica sob SHOULD NOT.
  • O recorte é funcional e depende da versão: FFDHE permanece possível no TLS/DTLS 1.3, e um certificado RSA pode autenticar uma troca efêmera permitida.
  • A marca D da IANA registra a decisão, mas não altera o processo. Inventário, testes positivos e negativos, causas de falha, exceções com prazo e telemetria de negociação formam a prova operacional.

Quando o fornecedor diz que o certificado está correto

Um equipamento remoto para de enviar dados depois de uma mudança no gateway. O fornecedor responde com três fatos: o certificado do servidor é válido, TLS 1.2 ainda está habilitado e o mesmo equipamento funcionava na véspera. Todos são verdadeiros. Nenhum explica o fracasso.

O cliente só oferecia troca de chaves RSA.

O RFC 10015, publicado no Standards Track em julho de 2026, torna essa oferta incompatível com a nova regra. Em TLS ou DTLS 1.2, o cliente não deve oferecer e o servidor não deve selecionar uma suíte de troca RSA. O fato de TLS 1.2 continuar disponível não conserva todas as suas formas históricas de criar o segredo da sessão.

Esse detalhe muda a autoridade sobre a resposta. Reabrir TLS_RSA_* não é simples rollback de certificado; é reativar um caminho proibido. Manter a recusa sem um dono para o equipamento também não é gestão: é transformar uma dependência não inventariada em indisponibilidade permanente.

Versão, certificado e troca são perguntas diferentes

Uma suíte TLS 1.2 combina autenticação, estabelecimento do segredo, cifra e integridade. O painel que mostra apenas a versão perde a decisão mais importante do RFC 10015.

FFDH é Diffie-Hellman em campo finito não efêmero, com chave DH estática no certificado. FFDHE transmite um valor temporário no handshake e o autentica. ECDH e ECDHE fazem a divisão equivalente em curvas elípticas.

Para TLS/DTLS 1.2, o texto estabelece:

  • FFDH não efêmero: cliente e servidor estão sob MUST NOT;
  • FFDHE: cliente e servidor estão sob MUST NOT;
  • troca de chaves RSA: cliente e servidor estão sob MUST NOT;
  • ECDH não efêmero: cliente e servidor estão sob SHOULD NOT.

Os tipos fixos rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh e ecdsa_fixed_ecdh, válidos para 1.2 e versões anteriores, também não devem ser usados ou aceitos.

A força normativa precisa sobreviver ao dashboard. ECDH estático requer uma justificativa excepcional, delimitada e temporária; não é a mesma violação absoluta de RSA ou FFDHE. Já manter uma suíte proibida no fim da lista de preferência não resolve: se ela ainda pode ser escolhida quando é o único ponto comum, o caminho permanece vivo.

Dois bloqueios amplos produziriam a política errada

“Remova RSA” pode alcançar o objeto errado. Um certificado com chave RSA pode assinar a autenticação de ECDHE, enquanto o segredo nasce da troca efêmera. O RFC retira a troca RSA, não todo certificado RSA.

“Remova DHE” ignora a versão. O RFC afirma que FFDHE em TLS e DTLS 1.3 não herda os problemas descritos para 1.2 e pode continuar sendo oferecido. Uma expressão global que desative o nome em todas as versões transformaria uma retirada precisa em perda desnecessária de capacidade moderna.

Por isso, o registro mínimo é uma relação: ponto de terminação, configuração carregada, oferta do cliente, seleção do servidor, versão e resultado. Nenhum campo isolado prova a decisão.

Por que o FFDHE de 1.2 não ganhou uma nova prorrogação

Efemeridade ajuda a proteger sessões antigas contra a exposição futura da chave de autenticação. Mas, no TLS 1.2, a escolha do grupo finito criou problemas próprios. Servidores difundiram grupos personalizados; o cliente não consegue verificar todas as propriedades de um grupo arbitrário durante o handshake e tampouco dispõe de uma negociação limpa para pedir outro aceitável.

O RFC 7919 padronizou grupos FFDHE nomeados e descreveu a pressão de compatibilidade que mantinha tamanhos amplamente suportados. O RFC 10015 reúne o restante da conta: pequenos subgrupos, grupos de 1024 bits ainda em uso, pré-computação compartilhável contra grupos populares e exposição quando segredos supostamente efêmeros são reutilizados, como na classe Raccoon.

A letra “E” no nome da suíte não comprova que o processo criou e descartou um segredo novo. A regra avalia o mecanismo implantado em 1.2, não condena Diffie-Hellman em qualquer protocolo.

A troca RSA amplia a janela no tempo e entre serviços

Na troca RSA de TLS 1.2, o cliente gera o segredo inicial e o cifra para a chave RSA do servidor. Não há sigilo futuro. Tráfego capturado pode ser decifrado mais tarde se a chave privada for obtida.

Ataques de oráculo do tipo Bleichenbacher exploram diferenças observáveis no tratamento de textos cifrados inválidos. ROBOT e DROWN mostram como essa família volta porque contramedidas perfeitamente indistinguíveis são difíceis de implementar.

Há ainda a reutilização. TLS/DTLS 1.2 não oferece separação de domínio conveniente para a chave. Um endpoint fraco pode afetar todos os serviços que compartilham a mesma chave RSA. O inventário precisa, portanto, mapear a impressão digital da chave privada, e não apenas sujeito e validade do certificado.

D é metadado de coordenação, não estado de runtime

O RFC 10015 atualiza dezessete RFCs, entre eles TLS 1.2, DTLS 1.2 e BCP 195. No registro TLS da IANA, as entradas afetadas receberam D na coluna Recommended e a nova referência. O RFC 9847 dá à marca o sentido de desaconselhado para novas implementações ou implantações.

O registro alinha linguagem entre implementação, compra e operação. Ele não edita biblioteca, proxy, CDN, balanceador ou firmware. Entre a tabela e o handshake existem defaults, provedores criptográficos, variáveis, sobrescritas de aplicação e modelos regionais.

Um diff de configuração comprova intenção. A configuração efetivamente carregada mostra o próximo estágio. Só a negociação observada mostra que cliente e servidor chegaram — ou deixaram de chegar — àquele caminho.

Montar o livro-caixa antes da retirada

O inventário cobre listeners públicos, APIs internas, clientes de saída, DTLS, service mesh, proxies, bordas, appliances e dispositivos embarcados. Cada terminação recebe proprietário, biblioteca e provedor, suítes efetivas, versões, SNI/ALPN, certificado, reutilização de chave, região e população cliente.

Na linha de base, cada sucesso liga versão, suíte, troca, terminação e canário de aplicação. Cada falha identifica a primeira causa acionável: nenhuma suíte comum, grupo, certificado, versão ou aplicação depois do transporte.

Os testes têm pares. Um cliente que só oferece RSA ou FFDHE em 1.2 deve falhar. Um cliente 1.2 com troca efêmera permitida deve passar. TLS 1.3 deve permanecer disponível, inclusive FFDHE quando aceito. Uma oferta mista deve selecionar o caminho novo sem fallback escondido.

A mudança avança por fronteiras de propriedade — classe de listener, região, proxy ou grupo de clientes. Guardam-se impressões antes/depois, amostras de handshake, distribuição de erros e rollback restrito. Implantar o arquivo é evento; retirar a negociação proibida sem perder as admitidas é resultado.

O código em execução encerra a discussão factual

A primazia do código em execução de Heng Lu coloca a evidência no lugar certo. O RFC pode definir uma condição e a IANA pode registrá-la; nenhum deles produz a transcrição de uma conexão real.

O modelo de especificação inicial mínima e decisão futura localizada preserva uma regra comum estreita e a autoridade de implementação de cada participante. O operador decide inventário, sequência, substituição, isolamento, exceção e rollback. Essa autonomia não transforma uma suíte proibida em compatível; ela atribui o custo e a prova a quem controla o endpoint.

O RFC desenha a fronteira. A configuração carregada e o handshake mostram se ela chegou à produção.