SSH3: SSHv2 usando HTTP/3 y QUIC

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

Un nuevo proyecto llamado “SSH3” propone reimaginar las conexiones de secure shell ejecutando semánticas parecidas a SSH sobre HTTP/3 y QUIC, prometiendo una configuración de sesión más rápida, mejor rendimiento en enlaces de alta latencia e integración con autenticación de estilo web como OAuth/OIDC. Los comentaristas están intrigados por beneficios potenciales como un paso más fácil a través de redes cerradas y ocultar SSH detrás del tráfico estándar de HTTPS, pero muchos critican el nombre como engañoso y cuestionan la complejidad añadida y la superficie de ataque de superponer HTTP cuando SSH sobre QUIC por sí solo podría bastar. Varios señalan que SSH tradicional ya admite certificados, criptografía moderna e incluso passkeys, y argumentan que la mayoría de las carencias podrían abordarse con mejoras incrementales en lugar de una reforma total del protocolo.

Estado del proyecto y nombre

  • Se señala ampliamente que se trata de un proyecto personal/académico, no de un estándar de IETF, no relacionado con OpenSSH y no una versión “oficial” de SSH.
  • Muchos consideran que “SSH3” es un nombre engañoso o sensacionalista que puede confundir a usuarios que esperan un protocolo SSHv3 respaldado oficialmente.
  • Algunos sostienen que el nombre es una cuestión cosmética; otros lo ven como una señal de mal juicio y falta de sensibilidad hacia la comunidad.

Diseño del protocolo: QUIC vs HTTP/3 vs SSHv2

  • La idea central: mapear semánticas tipo SSH sobre mecanismos HTTP por encima de QUIC+TLS 1.3.
  • Varios comentaristas creen que SSH sobre QUIC tiene sentido, pero que añadir HTTP/3 introduce complejidad innecesaria y superficie de ataque.
  • Otros dicen que usar HTTP/3 permite que el protocolo se mezcle con la infraestructura y las herramientas web, y se alinee con las pilas de red modernas.

Autenticación y modelo PKI

  • El proyecto pretende reutilizar mecanismos de autenticación HTTP (OIDC, OAuth, x.509), vinculando el acceso SSH con identidades de estilo web.
  • Algunos ven esto como una gran ventaja para SSO empresarial y passkeys; otros señalan que SSH ya admite certificados, FIDO2/passkeys e incluso OIDC vía PAM/keyboard-interactive.
  • Preocupaciones por la mala configuración: x.509 y OAuth pueden ser excesivos, frágiles o introducir nuevos modos de fallo.

Seguridad, privacidad y “ocultación”

  • QUIC/HTTP/3 cifra más metadatos, lo que dificulta la inspección de red y la seguridad de middleboxes; a algunos profesionales de seguridad les genera cautela.
  • El “URL secreto” / ocultación basada en la ruta se debate: para algunos es un acceso de estilo capability; para otros es seguridad por oscuridad que cualquier protocolo podría adoptar (por ejemplo, port knocking).
  • Otras preocupaciones: las pilas HTTP tienen una historia más amplia de vulnerabilidades (LFI, request smuggling, etc.) que SSH.

Rendimiento y usabilidad

  • Beneficios alegados: menos RTT para la configuración de sesión, posible mejor rendimiento en enlaces de alta latencia o de gran ancho de banda, y un paso más fácil a través de cortafuegos restrictivos (tráfico 443/parecido a HTTP).
  • Los escépticos dicen que la latencia de conexión de SSH rara vez es un problema real, y que OpenSSH ya tiene mitigaciones (ControlMaster) y parches de alto rendimiento (HPN-SSH).

Comparaciones con herramientas existentes

  • Mosh y Eternal Terminal se mencionan como opciones maduras para redes poco fiables; resuelven problemas distintos (roaming, interactividad) y en su mayoría reutilizan SSHv2.
  • Otros enfoques existentes: SSH sobre WebSockets, experimentos basados en QUIC, compartición de puertos mediante HAProxy/nginx/sslh, DNS SSHFP, certificados SSH.

Deseos futuros para SSH “v3”

  • Si surge un SSHv3 real, los comentaristas quieren: transporte QUIC, enrutamiento/metadatos tipo SNI, mejor balanceo de carga, integración de autenticación más limpia y ventanas más grandes, sin heredar la complejidad completa de HTTP.