TL；DR - 我认为您的问题根本与 SSL 无关，但您正在尝试使用没有代理标头的代理服务器。

那么，如果我使用 stunnel 创建一个 SSL 隧道，然后通过它传递 HTTP 流量，会不会和正常使用 HTTPS 一样呢？

是的。我们在工作中使用 http over stunnel 与 https-server 通信。这是针对 Java https 客户端中在某些情况下无法与 ISS https 服务器通信的错误的解决方法。

那么，如果代理/防火墙只看到带有加密流量的 SSL/TLS 连接，它怎么知道流量不是 HTTP？

普通的代理/防火墙无法分辨里面有什么。

有解密 https-proxy。为了让他们工作，他们需要欺骗客户端接受他们自己的公钥而不是真实服务器的公钥。在 https 中，公钥是证书的一部分，其中包含有关服务器名称的信息。证书通常由 CA 签名，浏览器认为 CA 是可信的。

代理服务器需要伪造服务器证书才能让客户端使用自己的公钥。普通客户端将显示有关无效证书的警告。但是代理可以使用自己的 CA 签署伪造的证书。并且管理员可以在客户端上安装受信任的 CA。

理论上，我认为如果代理/防火墙无法注意到差异，则应该能够通过 SSL/TLS 连接（使用 stunnel 创建）而不是 HTTP 来传输 SSH 流量。

在非解密 https 代理上，即使没有 SSL 层，隧道 SSH 的常用方法也可以工作。

但是，在实践中，我发现这不起作用 - 代理/防火墙似乎能够检测到它不是 HTTPS 流量。

要么你做错了什么，要么你在解密 https，如上所述。

我认为这就是使用 Proxytunnel 的原因，但我不明白 Proxytunnel 有什么不同的做法来避免检测。它只是创建虚假的 HTTP 标头吗？

您必须在这里区分防火墙和代理：如果只有网络防火墙，您可以正常连接到端口 443 上的目标 IP 地址。但是如果有代理，则需要连接代理的ip地址和端口，然后告诉它使用http协议连接到目标。命令是：CONNECT target:port HTTP/1.1 <cr><lf>

在大多数情况下，https-proxy-servers 允许连接到任何 IP 地址，但只能连接到端口 443。发送连接字符串后，您会得到一个 http 响应标头。在普通的 https 代理上，任何进一步的信息都会按原样转发到任何方向。所以你可以说任何你想要的协议。从这里本地使用 ssh 就可以了。

理论上，防火墙或哑代理可以通过检测非 SSL 流量来阻止这种本机隧道传输。但这种情况非常少见。只有 https 解密代理才能有效地阻止这种隧道。

如果您对 stunnel 实例的服务器端口执行 HTTP：

client <--- TCP ---> stunnel <--- TCP ---> server
                             <--- TLS --->
       <------------- HTTP -------------->

它将几乎与使用 HTTPS 完全一样，但不完全是因为客户端仍然认为自己使用基于 TCP 的 HTTP。例如，浏览器不会在 URL 栏中显示“安全”，如果连接不是 HTTPS，浏览器中运行的 Javascript 代码可能会拒绝执行操作。

对于剩下的问题，您需要弄清楚您正在使用的“防火墙”或“代理”到底发生了什么；它可能使用许多不同的技术来处理连接，当您使用它时，这些技术将允许或阻止某些技术。

1.直接TCP连接

如果您正在建立一个终止于远程主机的 TCP 连接（上图），即使它以某种方式被修改（例如，通过 NAT 更改的地址），并且您在该 TCP 连接上设置了一个 TLS 连接，中间路由器也会无法看到超出流量、IP 地址和 TCP 端口以及它是 TLS 的事实之外的任何流量。IP 级别防火墙可能配置为禁止与 443 以外的端口的连接，或者如果发现 443 不是 TLS，则丢弃与 443 的连接。它甚至可能首先连接到端口本身，以查看服务器是否似乎在该端口上运行 HTTP/TLS。

2. HTTP 代理 CONNECT

如果您要通过使用CONNECT动词的 HTTP 代理，就像Proxytunnel一样，则涉及两个 TCP 连接，但您通过它们执行一个 TLS 连接：

client <---- TCP 1 ----> proxy <---- TCP 2 ----> server
                        CONNECT
      <------------------ TLS ---------------->

您仍在与另一端的真实服务器协商 TLS，情况与上面的 #1 几乎相同。实际上，您不需要通过 TCP 连接执行 TLS；CONNECT server.mydom.com:22如果代理不拒绝该请求，您可以简单地开始通过该连接进行 SSH 通信。有些人正是为此目的在端口 443 上侦听 SSH 服务器。但是，如果代理足够复杂，可以检查正在使用的协议，如果它看到您没有进行标准 TLS 设置，它可能会断开您的连接，即使一旦 TLS 启动，它也无法准确看到该连接中发生了什么.

3. 中间人

一些组织对 HTTPS 连接进行中间人攻击（有时更客气地称为“SSL 拦截”）。当您尝试通过直接 TCP 连接或代理（如上述任何一种情况）连接到远程服务器时，网络设备会假装它是远程服务器。

client <---- TCP 1 ----> MITM <---- TCP 2 ----> server
       <---- TLS 1 ---->      <---- TLS 2 ---->
       <---------------- HTTP ---------------->

您的网络浏览器会尝试 TLS 设置，检查证书，并验证它不是因为它是真正的证书，而是因为设备生成了一个由私有 CA（证书颁发机构）签名的证书，并且 IT 部门还修改了证书列表信任该 CA 的浏览器或操作系统。（您通常可以通过尝试与另一个使用不同证书列表但没有该证书的程序进行相同的连接来判断这种情况正在发生，例如 Firefox，如果您独立下载它。）您与 MITM 设备建立了安全连接，但它正在解密所有内容并在转发数据时对其进行重新加密，以便与服务器建立另一个单独的安全连接。

在这种情况下，尽管您认为您正在与远程服务器通信，但实际上您只是在安全地与代理通信，该代理可以完全访问连接上的所有数据，并且可以根据需要查看和修改它。