Cronograma para remover suporte a DSA no OpenSSH

Artigo original ↗ Discussão no Hacker News ↗

O OpenSSH planeja remover totalmente o suporte ao algoritmo de chave pública DSA legado até o início de 2025, após anos em que ele já vinha desabilitado por padrão e seguindo a orientação antiga do NIST para descontinuar o DSA de 1024‑bits. Os comentaristas ponderam os benefícios de segurança e manutenção de excluir criptografia obsoleta — liberando o projeto para simplificar o manuseio de chaves e se preparar para algoritmos pós-quânticos — contra o impacto operacional para organizações que ainda precisam acessar hardware não atualizável, sistemas industriais e ambientes isolados por air-gap. A visão predominante é que quem tem essas necessidades legadas deve fixar versões antigas do OpenSSH, usá-las em contêineres ou recorrer a clientes alternativos, em vez de esperar que o upstream mantenha algoritmos fracos indefinidamente.

Cronograma de descontinuação e histórico

  • O OpenSSH planeja uma remoção faseada do DSA:
    • 2024-03: DSA opcional na compilação, habilitado por padrão.
    • 2024-06: DSA opcional, desabilitado por padrão.
    • 2025-01: DSA removido do OpenSSH.
  • Comentadores observam que isso segue uma orientação de longa data:
    • O NIST recomendou encerrar o uso de DSA de 1024‑bits até 2010.
    • O OpenSSH nunca ofereceu suporte a chaves DSA maiores e já havia desabilitado o DSA por padrão no OpenSSH 7 (2015).

Motivo para remover o DSA

  • Principais razões citadas:
    • O DSA no SSHv2 é limitado a chaves públicas de 1024‑bits / privadas de 160‑bits e é considerado fraco.
    • Manter código legado é custoso, especialmente durante refatorações e ao adicionar novos algoritmos (por exemplo, possíveis assinaturas pós-quânticas).
    • Caminhos de código antigos e raramente testados são vistos como riscos de segurança.

Impacto em sistemas legados

  • Alguns usuários ainda precisam de DSA para acessar:
    • Equipamentos de rede antigos, switches, BMCs, iLO, equipamentos de telecom, controle industrial, RHEL antigo e sistemas de parceiros.
  • Preocupação: sistemas “que não podem ser corrigidos” podem permanecer em serviço por décadas, especialmente em infraestrutura industrial e crítica.
  • Outros argumentam que tais sistemas deveriam ser isolados, colocados em air-gap ou substituídos; se não puderem ser atualizados, não deveriam ficar expostos a redes mais amplas.

Responsabilidade e direito adquirido

  • Tema forte: mantenedores de código aberto não são obrigados a dar suporte indefinido a criptografia obsoleta.
  • Contraponto: empurrar o custo da descontinuação para downstream aumenta o trabalho total e pode ser difícil em ambientes fortemente regulados ou burocráticos.
  • Alguns defendem que uma flag “perigoso/legado” ou um modelo de plugin seria preferível à remoção completa.

Alternativas e contornos

  • Sugestões:
    • Manter um cliente OpenSSH mais antigo (possivelmente em uma VM, contêiner ou um “legacy jump host” dedicado).
    • Usar pacotes de distribuição que preservem protocolos antigos (por exemplo, cliente ssh1).
    • Usar implementações alternativas de SSH (Dropbear, PuTTY), ou até telnet em redes estritamente controladas.
  • Foram levantadas preocupações sobre compilar versões muito antigas do OpenSSH em sistemas modernos e sobre a segurança de clientes legados.

Discussões relacionadas sobre criptografia

  • Esclarecimentos sobre os parâmetros do DSA e sua chave privada inerente de 160‑bits sob a especificação SSHv2 usada.
  • Discussão sobre outros tipos de chave: RSA, ECDSA, Ed25519.
  • Um fio paralelo observando grandes nuvens: a AWS adiciona suporte a Ed25519; a Azure e alguns componentes do GCP supostamente ainda não o possuem.