Cronograma para eliminar el soporte DSA en OpenSSH

Artículo original ↗ Discusión en Hacker News ↗

Cronograma de obsolescencia e historial

  • OpenSSH planea una eliminación gradual de DSA:
    • 2024-03: DSA opcional en tiempo de compilación, habilitado de forma predeterminada.
    • 2024-06: DSA opcional, deshabilitado de forma predeterminada.
    • 2025-01: DSA eliminado de OpenSSH.
  • Los comentaristas señalan que esto sigue una guía de larga data:
    • NIST recomendó dejar de usar DSA de 1024 bits en 2010.
    • OpenSSH nunca admitió claves DSA más grandes y ya deshabilitó DSA por defecto en OpenSSH 7 (2015).

Motivos para eliminar DSA

  • Las principales razones citadas:
    • DSA en SSHv2 está limitado a claves públicas de 1024 bits / privadas de 160 bits y se considera débil.
    • Mantener código heredado es costoso, especialmente durante refactorizaciones y al añadir nuevos algoritmos (por ejemplo, posibles firmas poscuánticas).
    • Las rutas de código antiguas y rara vez probadas se consideran riesgos de seguridad.

Impacto en sistemas heredados

  • Algunos usuarios todavía necesitan DSA para الوصول a:
    • Hardware de red antiguo, switches, BMC, iLO, equipos de telecomunicaciones, control industrial, RHEL antiguo y sistemas de socios.
  • Preocupación: los sistemas que “no se pueden arreglar” pueden seguir en servicio durante décadas, especialmente en entornos industriales y de infraestructura crítica.
  • Otros sostienen que esos sistemas deberían estar aislados, sin conexión a redes, o reemplazados; si no pueden actualizarse, no deberían exponerse a redes más amplias.

Responsabilidad y derecho adquirido

  • Tema recurrente: quienes mantienen software libre no están obligados a dar soporte indefinido a criptografía obsoleta.
  • Contrapunto: trasladar el coste de la obsolescencia hacia abajo aumenta el trabajo total y puede ser difícil en entornos muy regulados o burocráticos.
  • Algunos argumentan que un indicador de “peligroso/heredado” o un modelo de plugin sería preferible a la eliminación completa.

Alternativas y soluciones provisionales

  • Sugerencias:
    • Mantener un cliente OpenSSH antiguo (posiblemente en una VM, contenedor o un “legacy jump host” especial).
    • Usar paquetes de la distribución que conserven protocolos antiguos (por ejemplo, cliente ssh1).
    • Usar implementaciones alternativas de SSH (Dropbear, PuTTY), o incluso telnet en redes estrictamente controladas.
  • Se plantean preocupaciones sobre compilar OpenSSH muy antiguo en sistemas modernos y sobre la seguridad de clientes heredados.

Debates relacionados sobre criptografía

  • Aclaraciones sobre los parámetros de DSA y su clave privada intrínseca de 160 bits bajo la especificación SSHv2 utilizada.
  • Debate sobre otros tipos de clave: RSA, ECDSA, Ed25519.
  • Un hilo lateral señala a las principales nubes: AWS añade soporte para Ed25519; Azure y algunos componentes de GCP, según informes, todavía no lo tienen.","briefText":"OpenSSH planea eliminar por completo el soporte para el algoritmo de clave pública DSA heredado a comienzos de 2025, tras años de tenerlo deshabilitado por defecto y de la recomendación de larga data del NIST de retirar DSA de 1024 bits. Los comentaristas sopesan las ventajas en seguridad y mantenimiento de borrar criptografía obsoleta —liberando al proyecto para simplificar la gestión de claves y prepararse para algoritmos poscuánticos— frente al dolor operativo para las organizaciones que todavía deben acceder a hardware no actualizable, sistemas industriales y entornos aislados. La opinión predominante es que quienes tengan esas necesidades heredadas deberían fijar versiones antiguas de OpenSSH o contenerizarlas, o usar clientes alternativos, en lugar de esperar que el proyecto principal mantenga indefinidamente algoritmos débiles."}]} ρίου