SSH sobre HTTPS

Artigo original ↗ Discussão no Hacker News ↗

Executar SSH sobre HTTPS está emergindo como uma forma prática de contornar redes que bloqueiam a maioria das portas e protocolos de saída, mas ainda permitem tráfego web nas portas 80/443. Os comentaristas comparam abordagens como colocar SSH diretamente na porta 443, tunelar via HTTP CONNECT, WebSockets ou VPNs que imitam HTTPS, e usar ferramentas como sslh, chisel ou Cloudflare Tunnel, avaliando a facilidade de configuração versus a resistência à inspeção profunda de pacotes. A discussão também aborda preocupações mais amplas sobre ossificação de protocolos, em que middleboxes cada vez mais agressivos levam tudo a rodar sobre HTTPS, e os trade-offs de usabilidade e privacidade de métodos alternativos de autenticação como certificados TLS de cliente e passkeys.

SSH sobre HTTPS vs. apenas mudar portas

  • Vários comentários observam que simplesmente executar SSH na porta 80/443 muitas vezes contorna firewalls básicos, e muitos fazem isso na prática.
  • Outros enfatizam que redes modernas usam inspeção profunda de pacotes (DPI), então SSH em 80/443 é trivial de detectar pelo banner SSH e bloquear.
  • O apelo de SSH-sobre-HTTPS é a resistência à DPI e o compartilhamento da porta 443 com tráfego web normal, em vez de dedicar um IP/porta ao SSH.

Políticas de firewall e “segurança”

  • Muitas redes bloqueiam todas as portas de saída, exceto 80/443, às vezes também fazendo MITM de HTTPS com CAs personalizadas.
  • As razões dadas são “boas práticas de segurança” genéricas, muitas vezes sem modelos de ameaça claros.
  • Isso leva usuários a tunelar tudo sobre HTTPS (SSH, VPN, outros protocolos) para restaurar a funcionalidade completa da Internet.

Identidade do cliente e certificados de cliente HTTPS

  • Alguns gostariam de identidade nativa estilo “HTTP sobre SSH” (baseada em chave pública) nos navegadores.
  • Passkeys são vistos como de camada de aplicação e não equivalentes.
  • Certificados de cliente HTTPS são levantados como candidato, mas têm problemas:
    • UX ruim: popups frequentes, troca de conta desajeitada e erros opacos da camada TLS.
    • Risco de fingerprinting: a mera presença de certificados pode ser abusada para rastreamento.
    • Peculiaridades de plataforma: restrições do chaveiro do macOS, instalação de CA em nível de sistema, limites de certificados de 1 ano.

Ferramentas e variantes de tunelamento

  • Muitas ferramentas e padrões existentes são mencionados:
    • Demultiplexar SSH/HTTPS na mesma porta: sslh, httpssh, HAProxy com SNI/ALPN ou inspeção heurística.
    • Ferramentas de HTTP CONNECT / túnel HTTP: corkscrew, httptunnel; SSH sobre WebSockets via patches personalizados de socat ou websocat.
    • Soluções semelhantes a VPN sobre HTTPS/TLS: SSL VPNs (por exemplo, AnyConnect/OpenConnect), SSTP, WireGuard em portas “permitidas”, Cloudflare Tunnel, Tailscale, chisel, Ligolo-ng.
    • Shells baseadas em navegador: shellinabox para ambientes em que clientes SSH não estão disponíveis.

HTTPS como substrato universal

  • Vários comentários veem uma tendência de executar protocolos arbitrários sobre HTTPS (e QUIC/HTTP3) devido à discriminação de middleboxes.
  • gRPC e RPC sobre HTTP2 semelhantes são citados como exemplos de “HTTP como o novo TCP”.
  • Surgem preocupações sobre centralização de protocolo e provedor (tudo sobre 443, muitas vezes atrás de grandes CDNs), mas אחרים observam que isso dificulta bloquear conteúdo específico.