SSH sobre HTTPS

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

Ejecutar SSH sobre HTTPS está emergiendo como una forma práctica de eludir redes que bloquean la mayoría de los puertos y protocolos salientes, pero aún permiten tráfico web en 80/443. Los comentaristas comparan enfoques como poner SSH directamente en el puerto 443, tunelizar mediante HTTP CONNECT, WebSockets o VPNs que imitan HTTPS, y usar herramientas como sslh, chisel o Cloudflare Tunnel, sopesando la facilidad de configuración frente a la resistencia a la inspección profunda de paquetes. El hilo también aborda preocupaciones más amplias sobre la fosilización de protocolos, donde middleboxes cada vez más agresivos empujan a todo a ir sobre HTTPS, y sobre las compensaciones de usabilidad y privacidad de métodos alternativos de autenticación como los certificados TLS de cliente y las passkeys.

SSH sobre HTTPS frente a simplemente mover puertos

  • Varios comentarios señalan que simplemente ejecutar SSH en el puerto 80/443 a menudo elude cortafuegos básicos, y muchos lo hacen en la práctica.
  • Otros subrayan que las redes modernas usan inspección profunda de paquetes (DPI), así que SSH en 80/443 es trivial de detectar por el banner de SSH y bloquear.
  • El atractivo de SSH sobre HTTPS es la resistencia a DPI y compartir el puerto 443 con el tráfico web normal, en lugar de dedicar una IP/puerto a SSH.

Políticas de cortafuegos y “seguridad”

  • Muchas redes bloquean todos los puertos salientes excepto 80/443, a veces también haciendo MITM de HTTPS con CAs personalizadas.
  • Las razones que se dan son “mejores prácticas de seguridad” genéricas, a menudo sin modelos de amenaza claros.
  • Esto lleva a los usuarios a tunelizar todo sobre HTTPS (SSH, VPN, otros protocolos) para recuperar la funcionalidad completa de Internet.

Identidad del cliente y certificados de cliente HTTPS

  • Algunos desearían una identidad nativa de estilo “HTTP sobre SSH” (basada en clave pública) en los navegadores.
  • Las passkeys se ven como algo de capa de aplicación y no equivalente.
  • Los certificados de cliente HTTPS se plantean como candidata, pero tienen problemas:
    • Mala UX: ventanas emergentes frecuentes, cambio de cuentas incómodo y errores opacos de la capa TLS.
    • Riesgo de fingerprinting: la mera presencia de certificados puede abusarse para rastrear.
    • Particularidades de plataforma: restricciones del llavero de macOS, instalación de CA a nivel de sistema, límites de certificados de 1 año.

Herramientas y variantes de tunelización

  • Se mencionan muchas herramientas y patrones existentes:
    • Demultiplexar SSH/HTTPS en el mismo puerto: sslh, httpssh, HAProxy con SNI/ALPN o inspección heurística.
    • Herramientas de HTTP CONNECT / túnel HTTP: corkscrew, httptunnel; SSH sobre WebSockets mediante parches personalizados de socat o websocat.
    • Soluciones tipo VPN sobre HTTPS/TLS: SSL VPNs (p. ej., AnyConnect/OpenConnect), SSTP, WireGuard en puertos “permitidos”, Cloudflare Tunnel, Tailscale, chisel, Ligolo-ng.
    • Consolas basadas en navegador: shellinabox para entornos donde no hay clientes SSH disponibles.

HTTPS como sustrato universal

  • Varios comentarios ven una tendencia a ejecutar protocolos arbitrarios sobre HTTPS (y QUIC/HTTP3) debido a la discriminación de middleboxes.
  • Se citan gRPC y RPC sobre HTTP2 similares como ejemplos de “HTTP como el nuevo TCP”.
  • Surgen preocupaciones sobre la centralización de protocolos y proveedores (todo sobre 443, a menudo detrás de grandes CDNs), pero otros señalan que esto dificulta bloquear contenido específico.