SSH3: SSHv2 usando HTTP/3 e QUIC

Artigo original ↗ Discussão no Hacker News ↗

Um novo projeto chamado “SSH3” propõe reimaginar conexões de shell seguro executando semânticas semelhantes ao SSH sobre HTTP/3 e QUIC, prometendo configuração de sessão mais rápida, melhor desempenho em links de alta latência e integração com autenticação no estilo da web, como OAuth/OIDC. Os comentaristas se mostram intrigados com benefícios potenciais como passagem mais fácil por redes restritivas e esconder o SSH atrás de tráfego HTTPS padrão, mas muitos criticam o nome como enganoso e questionam a complexidade adicional e a superfície de ataque de empilhar HTTP quando SSH sobre QUIC por si só poderia bastar. Vários apontam que o SSH tradicional já suporta certificados, criptografia moderna e até passkeys, argumentando que a maioria das lacunas poderia ser tratada com melhorias incrementais em vez de um redesenho completo do protocolo.

Status do projeto e nomenclatura

  • É amplamente apontado que este é um projeto pessoal/acadêmico, não um padrão da IETF, não relacionado ao OpenSSH e não uma versão “oficial” do SSH.
  • Muitos consideram “SSH3” um nome enganoso ou apelativo, que pode confundir usuários que esperam um protocolo SSHv3 endossado.
  • Alguns argumentam que o nome é apenas cosmético; outros veem isso como um sinal de mau julgamento e pouca consciência da comunidade.

Design do protocolo: QUIC vs HTTP/3 vs SSHv2

  • A ideia central: mapear semânticas parecidas com SSH sobre mecanismos HTTP acima de QUIC+TLS 1.3.
  • Vários comentaristas acham que SSH sobre QUIC faz sentido, mas que adicionar HTTP/3 introduz complexidade desnecessária e superfície de ataque.
  • Outros dizem que usar HTTP/3 permite que o protocolo se misture à infraestrutura e às ferramentas da web, além de se alinhar com pilhas de rede modernas.

Modelo de autenticação e PKI

  • O projeto busca reutilizar mecanismos de autenticação HTTP (OIDC, OAuth, x.509), conectando o acesso SSH a identidades no estilo da web.
  • Alguns veem isso como uma grande vantagem para SSO corporativo e passkeys; outros observam que o SSH já suporta certificados, FIDO2/passkeys e até OIDC via PAM/keyboard-interactive.
  • Há preocupações com má configuração: x.509 e OAuth podem ser exagerados, frágeis ou introduzir novos modos de falha.

Segurança, privacidade e “ocultação”

  • QUIC/HTTP/3 criptografa mais metadados, o que dificulta a inspeção de rede e a segurança de middleboxes; alguns profissionais de segurança olham isso com cautela.
  • A “URL secreta” / ocultação baseada em caminho é debatida: vista por alguns como acesso do tipo capability, por outros como segurança por obscuridade que qualquer protocolo poderia adotar (por exemplo, port knocking).
  • Preocupações adicionais: pilhas HTTP têm um histórico maior de vulnerabilidades (LFI, request smuggling etc.) do que o SSH.

Desempenho e usabilidade

  • Benefícios alegados: menos RTTs para a configuração da sessão, potencial para melhor throughput em links de alta latência ou long-fat networks, e passagem mais fácil por firewalls restritivos (tráfego 443/semelhante a HTTP).
  • Céticos dizem que a latência de conexão do SSH raramente é um problema real, e que o OpenSSH já possui mitigadores (ControlMaster) e patches de alto desempenho (HPN-SSH).

Comparações com ferramentas existentes

  • Mosh e Eternal Terminal são mencionados como opções maduras para redes instáveis; eles resolvem problemas diferentes (roaming, interatividade) e em sua maioria reutilizam SSHv2.
  • Outras abordagens existentes: SSH sobre WebSockets, experimentos baseados em QUIC, compartilhamento de porta via HAProxy/nginx/sslh, DNS SSHFP, certificados SSH.

Desejos para um futuro SSH “v3”

  • Se surgir um SSHv3 de verdade, os comentaristas querem: transporte QUIC, roteamento/metadados no estilo SNI, melhor balanceamento de carga, integração mais limpa de autenticação e janelas maiores — sem herdar toda a complexidade do HTTP.