Conexión SSH a través de HTTPS

Transportar SSH a través de HTTPS

• Para transportar SSH a través de HTTPS, hay que ajustar tanto el cliente como el servidor.
• En el ejemplo de configuración del cliente, se establecen ProxyCommand y ServerAliveInterval en el archivo ~/.ssh/config.
• El script ~/.ssh/https-tunnel.bash que se usa crea una conexión TLS con socat mientras envía el método CONNECT en los encabezados.

Ejemplo de configuración del servidor

• En la configuración del servidor HTTPS de Apache2, se carga proxy_connect_module y se usa la directiva AllowCONNECT para permitir el uso del método HTTP CONNECT hacia un destino específico.
• Del lado del servidor, se configura para que en https-server el método CONNECT solo pueda usarse para el único destino, el host ssh-server.

Contexto

• Mientras se permanece en un hospital, se busca trabajar de forma remota a través del Wi‑Fi del hospital, donde la mayoría de los tipos de conexión están bloqueados.
• La red del hospital solo permite conexiones HTTP y HTTPS, y SSH está completamente bloqueado.
• Se exploran formas de transportar SSH a través de HTTP o HTTPS.

Métodos posibles

• El proyecto sslh, que coalberga los protocolos SSH y HTTPS en un solo puerto y los distribuye de forma transparente.
• sslh no encapsula un protocolo dentro de otro, sino que usa varias heurísticas para redirigir al backend real.
• Un método que encapsula por completo el protocolo SSH dentro de otro protocolo usando la directiva ProxyCommand de openssh.

SSH sobre HTTP

• Para un intento simple de SSH sobre HTTP, se configura Apache2 para permitir el método CONNECT hacia el único destino ssh-server:22.
• Del lado del cliente, se ajusta fácilmente usando socat.
• Se usa ServerAliveInterval para evitar que la conexión HTTP se cierre incluso cuando está inactiva.

SSH sobre HTTPS

• socat no es compatible con proxies HTTPS, pero sí con encapsulación TLS.
• Es fácil implementar manualmente un método basado en CONNECT.
• Se implementa el túnel SSH sobre HTTPS usando el script ~/.ssh/https-tunnel.bash.

Cierre

• La presencia generalizada de HTTPS permite transportar datos a través de dispositivos intermedios muy restrictivos.
• El método CONNECT es un hack útil para envolver un flujo de carga útil TCP dentro de un flujo de host TLS.
• ServerAliveInterval se usa para mantener la conexión en transportes subyacentes que no son amigables con las conexiones inactivas.

Opinión de GN⁺

• Lo más importante de este artículo es que presenta una solución creativa para hacer posible una conexión SSH incluso en entornos de red restrictivos.
• La forma de combinar SSH y HTTPS puede ser especialmente interesante para personas con conocimientos especializados relacionados con seguridad de redes.
• La manera de evadir restricciones de red mediante la configuración de ProxyCommand y ServerAliveInterval ofrece información útil para administradores de red o especialistas en seguridad.

[GN⁺]

Comentarios de Hacker News

• El proveedor de internet neerlandés XS4ALL en el pasado ofrecía acceso SSH a través del puerto 80. Esta función era útil cuando otros puertos estaban bloqueados, como en el Wi‑Fi de hoteles.
• La presencia universal de HTTPS permite transmitir datos a través de dispositivos intermedios muy restrictivos. Esta es la principal razón por la que los protocolos VPN propietarios conocidos como SSL VPN implementan un modo para iniciar túneles a través de HTTPS.
• También existe la opción de poner SSH en el puerto 80 o 443 y usar ProxyJump a través de otro host, o conseguir una conexión a internet menos restringida mediante SOCKS. También es posible reenviar DNS sobre TLS a través de una conexión SSH.
• Una empresa llamada Adaptive está construyendo una infraestructura de seguridad de datos que ofrece SSH y varios protocolos a través de HTTP3. Con esto, los usuarios pueden conectarse a bases de datos, servidores y otros recursos mediante puertos externos.
• En la práctica, la mayoría de los firewalls pueden eludirse simplemente haciendo que openssh escuche en el puerto 443.
• Es interesante pensar en el método CONNECT no como un proxy de reenvío, sino como un proxy inverso. Sin embargo, CONNECT por sí solo no basta, así que se usa SSH sobre WebSocket para evadir proxies corporativos.
• Resulta molesta la frecuencia de las publicaciones sobre soluciones "nuevas". Estas ideas no son nuevas y mucha gente ya las conoce.
• Sería bueno que los navegadores trajeran integrado un sistema de gestión de identidad similar a SSH. Cuando leí por primera vez sobre la propuesta de autenticación HTTP con clave pública llamada hobo, me emocioné, pero luego descubrí que no había implementación del servidor ni tampoco del cliente (navegador).
• Hace unos 20 años usé una herramienta llamada corkscrew para atravesar firewalls corporativos. Resultan impresionantes tanto la implementación independiente de esta herramienta como su explicación.
• El tunelizado a través de HTTP2 es una excelente opción. Existe gRPC, un protocolo RPC construido sobre HTTP2. HTTP2 es excelente para enviar y recibir simultáneamente varias estructuras de datos sobre una conexión TCP. Sin embargo, quizá no sea necesario usar HTTP3, porque QUIC por sí mismo ya ofrece multiplexación.