使用TLS嵌套在TLS内部防止TLS检查

Question

假设我有一个程序需要与我自己的服务器通信。

我使用TLS来保护连接，但是程序在网络中运行，它通过TLS检查代理发送所有TLS流量，程序运行的计算机信任TLS检查代理的CA证书。

但是，TLS检查服务器上的代理可以访问在我的程序和我的服务器之间发送的明文。

为了防止出现这种情况，我认为我们可以将明文包装如下：

• 明文包装在TLS会话(内部)中。
• 然后将此TLS会话包装在另一个TLS会话(外部)中。

使用此设置，TLS检查代理将只终止和替换外部TLS会话的证书，而不替换内部会话，因此服务器将无法访问明文。(假设TLS检查软件不递归地执行此操作)。

然后，我的程序可以使用计算机默认根存储来验证外部会话，但是可以为内部会话捆绑自己的受信任根存储，或者为内部会话使用证书固定。还需要对服务器进行修改，以使用此双TLS。

当然，在安装我的程序之后，用户可以通过修改编译的程序来修改用于内部会话的受信任的根存储，但我认为这不是一个很可能的情况。

这种方法还有其他缺陷吗？

Answer 1

TLS内部的TLS概念本身并没有什么不安全的地方--它甚至已经完成了。例如，一些HTTP代理，如squid支持用HTTPS连接到代理，然后在这个受保护的代理中连接到代理，即真正的连接。另外，在VPN中使用TLS也是一个类似的概念，即在彼此之间有多个加密和身份验证层。

至于实际的实现，在TLS方法中使用一个简单的TLS可能会遇到问题。TLS检查代理通常期望有一个特定的协议，比如TLS内部所说的HTTP --因为获取原始数据首先是TLS拦截的主要内容。如果这些代理没有看到预期的协议，那么它们可能只是中断了连接。因此，可能需要在期望的协议中再次对内部TLS进行分层，比如将内部TLS分层到HTTP中，然后在外部TLS中得到层。

当然，在安装我的程序之后，用户可以通过修改编译的程序来修改用于内部会话的受信任的根存储，但我认为这不是一个很可能的情况。

让最终用户以敌人的身份运行程序与试图通过某个不受信任的代理完全不同--即端点与中间的man。TLS内部的TLS可能会使反向工程和更改应用程序变得更加困难，但这并不能阻止它。因此，虽然它适合作为对拦截MITM的保护，但不适合作为针对最终用户的保护。