Resumo

  • No TLS 1.2 e no DTLS 1.2, o RFC 10015 determina que clientes não ofereçam e servidores não selecionem várias trocas Diffie–Hellman sobre campos finitos e a troca RSA estática. ECDH estático e certos tipos de certificado de cliente DH continuam no nível SHOULD NOT.
  • A marca D da IANA comprova o estado normativo, não a execução. Dizer “desativado” exige ligar a regra à configuração carregada, a todas as terminações, aos testes de oferta e seleção, à telemetria, ao vencimento das exceções e à migração dos clientes legados.

O painel ficou verde assim que o registro foi atualizado. A configuração central também já estava correta. Mesmo assim, um terminador DTLS antigo, fora da administração comum, continuava rodando uma imagem anterior. A IANA dizia a verdade sobre a norma; o painel dizia mais do que a evidência permitia.

O RFC 10015, publicado na trilha de padrões do IETF, atualiza as exigências para trocas de chaves no TLS 1.2 e no DTLS 1.2. Ele não mede adoção, não enumera produtos e não verifica a configuração de um serviço. Seu trabalho é definir o comportamento conforme. Transformar essa definição em constatação sobre uma frota é responsabilidade do operador.

A confusão prospera porque os dados normativos são fáceis de automatizar. Um sistema lê a tabela, encontra D, abre ou encerra um controle. Entre essa linha e um handshake real, porém, existem o código da biblioteca, o padrão do fornecedor, a política local, o arquivo renderizado, o processo que o carregou, o inventário de terminações, a oferta do cliente e a seleção do servidor.

A norma preserva diferenças importantes

O RFC 10015 não cria um único saco chamado “TLS antigo”. Em TLS 1.2 e DTLS 1.2, clientes MUST NOT oferecer e servidores MUST NOT selecionar suítes DH não efêmeras sobre campos finitos. A mesma proibição vale para DHE efêmero nessas versões. A troca de chaves RSA estática também recebe MUST NOT.

Para ECDH estático, o texto mantém SHOULD NOT. Os tipos de certificado de cliente com DH fixo tratados no documento também são SHOULD NOT. Uma exceção precisa de justificativa robusta e revisão, mas não tem a mesma semântica de uma violação a MUST NOT. Um controle que reduz tudo a “obsoleto” apaga justamente a informação necessária para julgar uma exceção.

A versão do protocolo não pode sumir do registro de controle. O RFC 8996 já havia desaconselhado TLS 1.0 e 1.1. O RFC 5246 define TLS 1.2; o RFC 8446 redesenha o acordo de chaves no TLS 1.3. O RFC 10015 permite explicitamente FFDHE em TLS 1.3. Os problemas de TLS 1.2 não tornam todo uso de Diffie–Hellman finito proibido. O RFC 7919 permanece relevante para entender grupos negociados.

“RSA estática” também não quer dizer “qualquer RSA”. Um serviço pode usar certificado e assinatura RSA sem empregar transporte estático de chave RSA. Vasculhar o inventário de certificados pela palavra RSA responde a outra pergunta, não à possibilidade de seleção da troca atingida pelo RFC.

As razões criptográficas explicam o rigor. Sem sigilo futuro, o comprometimento posterior de uma chave duradoura pode revelar sessões antigas. A reutilização de chaves DH finitas traz perigos de temporização e de grupo; a reutilização de ECDH amplia riscos de curva inválida, canal lateral e falha. RSA estática carrega a recorrência de ataques da classe Bleichenbacher e problemas de reutilização entre protocolos. O RFC 9325 e o RFC 9847 integram o esforço de manter a prática de implantação alinhada às evidências acumuladas, não à mera disponibilidade histórica do código.

O que o D realmente atesta

O registro TLS da IANA marca as suítes afetadas e quatro valores ClientCertificateType com D e referência ao RFC 10015. O significado é discouraged, desaconselhado. A intensidade exata — MUST NOT ou SHOULD NOT — vem do documento citado.

Portanto, a marca prova o estado da recomendação pública. Ela pode alimentar revisão de código, política de compras e fila de migração. Não comprova que a biblioteca removeu a capacidade, que o produto mudou o padrão, que a configuração local retirou a suíte ou que o processo carregou a nova configuração.

Também não cobre automaticamente cada listener, SNI, proxy, balanceador e borda regional. Não mostra que clientes pararam de oferecer, servidores pararam de selecionar ou que uma exceção e uma imagem de rollback não conseguem reintroduzir a escolha. São afirmações diferentes, com donos e relógios diferentes.

Capacidade, oferta, seleção e observação

Um modelo operacional útil mantém quatro estados. Capacidade é o código conseguir executar a troca. Oferta é o que o cliente envia em um handshake específico. Seleção é a escolha efetiva do servidor. Observação é o recorte que a sonda ou a telemetria conseguiu enxergar.

A capacidade pode continuar presente enquanto a política bloqueia todas as ofertas. Uma suíte pode constar de um arquivo, mas nunca vencer regras de prioridade. Uma varredura pode não observá-la por desconhecer um SNI, não testar UDP, ignorar uma borda interna ou sempre oferecer uma alternativa melhor. Ausência na amostra não é impossibilidade.

Um teste negativo controlado oferece somente a família proibida e espera recusa. É mais informativo que uma conexão normal de navegador moderno, mas vale apenas para o endereço, porta, transporte, SNI, horário e versão de política alcançados. O DTLS 1.3 do RFC 9147 lembra que uma campanha de TLS sobre TCP não encerra uma exposição DTLS sobre UDP.

Um recibo de encerramento da descontinuação

Cada exposição deve produzir um recibo de encerramento da descontinuação. A primeira parte identifica RFC, item IANA, versão do protocolo, família e força normativa. Isso impede que FFDHE permitido no TLS 1.3 seja removido por semelhança de nome e que SHOULD NOT seja tratado como MUST NOT sem registro.

A segunda parte localiza o controle efetivo: fonte autorizada da configuração, revisão aprovada, política renderizada, build ou firmware, listener, SNI, endereço, porta, transporte e proxies anteriores. “Política global atualizada” não é suficiente quando a terminação está distribuída entre serviços e equipes.

A terceira parte prova ativação: reinício, reload, atualização dinâmica ou rollout administrado; horário; identificador da mudança; população-alvo; instâncias concluídas, falhas e ausentes; versão de retorno. O diff demonstra intenção. A identidade do processo e a política carregada se aproximam da execução.

A quarta parte registra comportamento: recusa à oferta exclusiva da suíte proibida, seleção diante de alternativas, ofertas e escolhas vistas na telemetria, janela de observação e lacunas de amostragem. O recibo nunca transforma “não visto” em “impossível”.

Por fim, entram dependências e exceções: cliente legado, função, escopo, controle compensatório, responsável, aprovação, validade e critério de saída. A migração do cliente e a remoção do caminho compatível precisam ser comprovadas. Exceção sem prazo é uma segunda política permanente.

Esse recibo é uma proposta editorial de Daniel Kade, não uma nova obrigação do RFC 10015. Ele evita que a facilidade de ler uma alteração normativa produza uma certeza artificial sobre infraestrutura que não foi inspecionada.

Automação com linguagem verificável

O sistema deve dizer “desaconselhado no registro”, “removido da configuração”, “reload confirmado”, “oferta negativa recusada”, “nenhuma seleção observada nesta cobertura” ou “exceção encerrada”. “Desativado” só cabe quando as terminações relevantes apresentam a cadeia completa.

Essa precisão ajuda quando algo falha. Se a seleção proibida reaparecer, a equipe consegue procurar a ruptura na fonte, na renderização, na implantação, no inventário, na exceção ou no cliente dependente. Um único bit verde elimina esse caminho causal.

O IETF definiu a linha normativa. A governança operacional começa depois dela: qual endpoint ainda consegue fazer a escolha antiga, quem o controla e qual evidência sustenta que ele já não consegue fazê-la?

Fontes