SSH over HTTPS

Original Article ↗ Hacker News Discussion ↗

Running SSH over HTTPS is emerging as a practical way to bypass networks that block most outbound ports and protocols but still allow web traffic on 80/443. Commenters compare approaches such as putting SSH directly on port 443, tunneling via HTTP CONNECT, WebSockets, or VPNs that mimic HTTPS, and using tools like sslh, chisel, or Cloudflare Tunnel, weighing ease of setup against resistance to deep packet inspection. The thread also touches on broader concerns about protocol ossification, where increasingly aggressive middleboxes push everything to ride on top of HTTPS, and on the usability and privacy trade-offs of alternative authentication methods like client TLS certificates and passkeys.

SSH over HTTPS vs. just moving ports

  • Several comments note that simply running SSH on port 80/443 often bypasses basic firewalls, and many do this in practice.
  • Others stress that modern networks use deep packet inspection (DPI), so SSH on 80/443 is trivial to detect via the SSH banner and block.
  • The appeal of SSH-over-HTTPS is DPI-resistance and sharing port 443 with normal web traffic, rather than dedicating an IP/port to SSH.

Firewall policies and “security”

  • Many networks block all outbound ports except 80/443, sometimes also MITM’ing HTTPS with custom CAs.
  • Reasons given are generic “security best practices,” often without clear threat models.
  • This leads to users tunneling everything over HTTPS (SSH, VPNs, other protocols) to restore full Internet functionality.

Client identity and HTTPS client certificates

  • Some wish for “HTTP over SSH”-style identity (public-key-based) natively in browsers.
  • Passkeys are seen as application-layer and not equivalent.
  • HTTPS client certificates are raised as a candidate but have issues:
    • Poor UX: frequent popups, awkward account switching, and opaque TLS-layer errors.
    • Fingerprinting risk: mere presence of certs can be abused for tracking.
    • Platform quirks: macOS keychain constraints, system-wide CA install, 1‑year cert limits.

Tools and tunneling variants

  • Many existing tools and patterns are mentioned:
    • Demuxing SSH/HTTPS on the same port: sslh, httpssh, HAProxy with SNI/ALPN or heuristic inspection.
    • HTTP CONNECT / HTTP tunnel tools: corkscrew, httptunnel; SSH over WebSockets via custom socat patches or websocat.
    • VPN-like solutions over HTTPS/TLS: SSL VPNs (e.g., AnyConnect/OpenConnect), SSTP, WireGuard on “allowed” ports, Cloudflare Tunnel, Tailscale, chisel, Ligolo-ng.
    • Browser-based shells: shellinabox for environments where SSH clients aren’t available.

HTTPS as the universal substrate

  • Multiple comments see a trend toward running arbitrary protocols over HTTPS (and QUIC/HTTP3) due to middlebox discrimination.
  • gRPC and similar RPC-over-HTTP2 are cited as examples of “HTTP as the new TCP.”
  • Concerns are raised about protocol and provider centralization (everything over 443, often behind large CDNs), but others note this makes blocking specific content harder.