通过 HTTPS 运行 SSH

原文 ↗ Hacker News 讨论 ↗

通过 HTTPS 运行 SSH 正成为一种实用方式，用来绕过那些会封锁大多数出站端口和协议、但仍允许 80/443 网页流量的网络。评论者比较了多种做法，例如直接把 SSH 放到 443 端口、通过 HTTP CONNECT 或 WebSockets 做隧道，或使用模仿 HTTPS 的 VPN，以及 sslh、chisel、Cloudflare Tunnel 等工具，并权衡了部署难度与对深度包检测的抵抗能力。讨论还延伸到更广泛的协议固化担忧：越来越强势的中间盒推动一切都叠加在 HTTPS 之上，以及客户端 TLS 证书和 passkeys 等替代认证方式在可用性与隐私方面的取舍。

SSH over HTTPS vs. just moving ports

  • 多条评论指出，仅仅把 SSH 运行在 80/443 端口上，通常就能绕过基础防火墙，而且现实中很多人也是这么做的。
  • 其他人强调，现代网络使用深度包检测（DPI），因此 SSH 放在 80/443 上可以通过 SSH banner 轻易识别并被封锁。
  • SSH-over-HTTPS 的吸引力在于抗 DPI，以及与正常网页流量共享 443 端口，而不是给 SSH 单独分配一个 IP/端口。

Firewall policies and “security”

  • 许多网络会封锁所有出站端口，只允许 80/443，有时还会用自定义 CA 对 HTTPS 做 MITM。
  • 给出的原因通常是泛泛的“安全最佳实践”，往往没有清晰的威胁模型。
  • 这导致用户把一切都隧道到 HTTPS 之下（SSH、VPN、其他协议），以恢复完整的互联网功能。

Client identity and HTTPS client certificates

  • 有些人希望浏览器原生支持类似“HTTP over SSH”的身份标识（基于公钥）。
  • Passkeys 被认为是应用层方案，并不等价。
  • HTTPS 客户端证书被提出来作为候选，但存在问题：
    • 糟糕的 UX：频繁弹窗、切换账号别扭，以及不透明的 TLS 层错误。
    • 指纹识别风险：仅仅存在证书就可能被滥用来跟踪。
    • 平台怪癖：macOS 钥匙串限制、系统级 CA 安装、证书 1 年期限限制。

Tools and tunneling variants

  • 文中提到了许多现有工具和模式：
    • 在同一端口上分流 SSH/HTTPS：sslh、httpssh、使用 SNI/ALPN 或启发式检测的 HAProxy。
    • HTTP CONNECT / HTTP 隧道工具：corkscrew、httptunnel；通过自定义 socat 补丁或 websocat 实现的 SSH over WebSockets。
    • 运行在 HTTPS/TLS 上、类似 VPN 的方案：SSL VPN（例如 AnyConnect/OpenConnect）、SSTP、运行在“允许”端口上的 WireGuard、Cloudflare Tunnel、Tailscale、chisel、Ligolo-ng。
    • 基于浏览器的 shell：在没有 SSH 客户端可用的环境中使用 shellinabox。

HTTPS as the universal substrate

  • 多条评论认为，受中间盒歧视影响，越来越多的任意协议会运行在 HTTPS（以及 QUIC/HTTP3）之上。
  • gRPC 和类似的基于 HTTP2 的 RPC 被当作“HTTP 就是新的 TCP”的例子。
  • 有人对协议和提供方的中心化表示担忧（一切都在 443 上，且常常位于大型 CDN 之后），但也有人指出，这让阻止特定内容变得更困难。