Conexão SSH via HTTPS

Transportando SSH via HTTPS

• Para transportar SSH via HTTPS, é preciso ajustar tanto o cliente quanto o servidor.
• No exemplo de configuração do cliente, são definidos ProxyCommand e ServerAliveInterval no arquivo ~/.ssh/config.
• O script ~/.ssh/https-tunnel.bash usado cria uma conexão TLS com socat, enviando o método CONNECT nos cabeçalhos.

Exemplo de configuração do servidor

• Na configuração do servidor HTTPS Apache2, carrega-se o proxy_connect_module e usa-se a diretiva AllowCONNECT para permitir o uso do método HTTP CONNECT para destinos específicos.
• No lado do servidor, configura-se o https-server para permitir o uso do método CONNECT apenas para o host único de destino ssh-server.

Contexto

• Enquanto estava internado no hospital, a pessoa queria trabalhar remotamente usando o Wi‑Fi do hospital, que bloqueava a maioria dos tipos de conexão.
• A rede do hospital permitia apenas conexões HTTP e HTTPS, e o SSH era totalmente bloqueado.
• Exploração de como transportar SSH por HTTP ou HTTPS.

Métodos possíveis

• O projeto sslh, que hospeda em conjunto os protocolos SSH e HTTPS em uma única porta e os distribui de forma transparente.
• O sslh não encapsula um protocolo dentro de outro; em vez disso, usa várias heurísticas para redirecionar ao backend real.
• Um método que encapsula completamente o protocolo SSH dentro de outro protocolo usando a diretiva ProxyCommand do openssh.

SSH sobre HTTP

• Para uma tentativa simples de SSH sobre HTTP, configura-se o Apache2 para permitir o método CONNECT para o único destino ssh-server:22.
• No lado do cliente, a adaptação é feita facilmente com socat.
• Usa-se ServerAliveInterval para evitar que a conexão HTTP seja encerrada mesmo quando estiver ociosa.

SSH sobre HTTPS

• O socat não oferece suporte a proxy HTTPS, mas oferece suporte a encapsulamento TLS.
• É fácil implementar manualmente um método baseado em CONNECT.
• O script ~/.ssh/https-tunnel.bash é usado para implementar o tunelamento de SSH sobre HTTPS.

Encerramento

• A presença quase universal do HTTPS permite transportar dados por dispositivos intermediários muito restritivos.
• O método CONNECT é um hack útil para encapsular um fluxo de payload TCP dentro de um fluxo de host TLS.
• ServerAliveInterval é usado para manter a conexão em transportes subjacentes que não lidam bem com conexões ociosas.

Opinião do GN⁺

• O ponto mais importante deste texto é apresentar uma solução criativa para viabilizar conexões SSH mesmo em ambientes de rede restritivos.
• A forma de combinar SSH e HTTPS pode ser especialmente interessante para pessoas com conhecimento especializado em segurança de redes.
• A maneira de contornar restrições de rede com as configurações de ProxyCommand e ServerAliveInterval oferece informações úteis para administradores de rede e especialistas em segurança.

[GN⁺]

Comentários do Hacker News

• O provedor de internet holandês XS4ALL já ofereceu acesso SSH pela porta 80 no passado. Esse recurso era útil em situações como Wi‑Fi de hotel, quando outras portas estavam bloqueadas.
• A presença quase universal do HTTPS permite transmitir dados por dispositivos intermediários muito restritivos. Essa é a principal razão pela qual protocolos VPN proprietários, chamados de SSL VPN, implementam um modo de iniciar túneis por HTTPS.
• Também há como colocar o SSH nas portas 80 ou 443 e usar ProxyJump por meio de outro host, ou obter uma conexão de internet menos restrita via SOCKS. Também é possível encaminhar DNS sobre TLS por uma conexão SSH.
• Uma empresa chamada Adaptive está construindo uma infraestrutura de segurança de dados que fornece SSH e vários outros protocolos por HTTP3. Com isso, os usuários podem se conectar a bancos de dados, servidores e outros recursos por portas externas.
• Na prática, a maioria dos firewalls pode ser contornada simplesmente fazendo o openssh escutar na porta 443.
• É interessante pensar no método CONNECT como algo parecido com um proxy reverso, e não um proxy de encaminhamento. Ainda assim, só o CONNECT não basta, então usa-se SSH por WebSocket para contornar proxies corporativos.
• A frequência de posts sobre soluções “novas” é incômoda. Essas ideias não são novas, e muita gente já conhece tudo isso.
• Seria bom se houvesse no navegador um sistema de gerenciamento de identidade semelhante ao do SSH. Houve empolgação ao ler pela primeira vez sobre a proposta de autenticação HTTP por chave pública chamada hobo, mas depois descobriu-se que não há implementação no servidor nem no cliente (navegador).
• Há cerca de 20 anos, foi usada uma ferramenta chamada corkscrew para atravessar firewalls corporativos. A implementação independente e a explicação sobre essa ferramenta são impressionantes.
• Tunelamento por HTTP2 é uma excelente escolha. Existe o gRPC, um protocolo RPC construído sobre HTTP2. O HTTP2 é excelente para enviar e receber simultaneamente várias estruturas de dados usando uma conexão TCP. Ainda assim, talvez não seja necessário usar HTTP3, porque o próprio QUIC já oferece multiplexação.