刚好对DH算法场景下的TLS检查这块比较熟悉，先聊聊核心的局限性，再拆解两种常见的实现方式：

一、DH算法下TLS检查的核心局限 #

DH（包括DHE/ECDHE）的密钥交换逻辑天生给TLS检查带来了不少障碍，主要体现在这几点：

• 端到端密钥生成：会话密钥是客户端和服务器通过协商的DH参数共同计算出来的，第三方（比如检查代理）如果不参与密钥交换过程，根本拿不到足够的材料推导会话密钥，自然无法解密流量。
• PFS（完美前向保密）的限制：如果启用了搭配DHE/ECDHE的PFS，每次会话都会生成临时的DH私钥，会话密钥不会和长期私钥绑定，就算拿到某次会话的参数，也没法解密其他会话，彻底堵死了事后解密的可能。
• 非标准DH参数的兼容性：如果客户端或服务器使用了自定义的DH组（而非RFC标准组），大部分通用的TLS检查工具/代理都不支持，直接会导致握手失败或者无法完成流量解密。
• 无密钥注入/共享的话，检查完全无效：和RSA密钥交换不同，DH没有可以提前获取的长期会话密钥，必须实时参与密钥交换或者拿到关键参数，否则TLS检查就是空谈。

二、两种TLS检查的实现细节 #

方式一：双TLS通道的代理服务器 #

这是最常见的TLS检查实现，本质是主动中间人代理，代理会分别和客户端、服务器建立独立的TLS会话（也就是Client <-> Proxy <-> Server两条通道）。

具体细节：

• 代理需要持有受客户端信任的CA证书（要么是客户端手动导入的私有CA，要么是公共CA签发的证书），这样客户端才会接受代理伪造的服务器证书（代理会模拟服务器的证书信息，用自己的CA签名）。
• 两次独立的TLS协商：代理会先和客户端完成一次完整的TLS握手（包括协商DH组、密钥交换），再和服务器完成另一次握手。这意味着如果客户端用了非标准TLS扩展、自定义DH组，或者服务器有特定的TLS版本/参数要求，代理必须完全支持这些特性，否则任意一端的握手都会失败。
• 流量处理能力：因为代理能解密两端的流量，所以可以做内容过滤、入侵检测、日志审计等操作，但代价是代理需要承担两次TLS握手的性能开销，而且要维护大量的TLS特性兼容，否则很容易出现兼容性问题。
• 风险点：如果代理的CA证书泄露，或者客户端没有正确验证证书，就会引发中间人攻击；另外，代理需要维护足够多的DH组参数，以匹配不同客户端/服务器的需求。

方式二：包含密钥的中间元素（密钥注入/共享模式） #

这种方式不需要做完整的中间人，而是通过获取DH密钥交换的关键材料来推导会话密钥，从而实现流量检查。

具体细节：

• 核心逻辑：中间元素（比如网关、流量镜像工具）需要获取到客户端公钥、服务器公钥、协商的DH组参数，再加上其中一方的私钥（或者提前共享的密钥材料），就能计算出和客户端/服务器一致的会话密钥。
• 常见场景：比如服务器将自己的DH私钥共享给中间元素，或者中间元素参与DH组的生成（服务器直接使用中间元素提供的DH组参数）。
• 优势：不需要伪造证书，兼容性更好，尤其是面对非标准TLS实现的场景，只要能捕获到DH交换的关键参数，就能完成解密。
• 局限性：
  • 必须得到客户端或服务器的配合：比如你没法拿到第三方服务的DH私钥，这种方式就完全用不了。
  • 不支持PFS：如果启用了PFS，服务器每次会话都会生成临时DH私钥，中间元素无法提前获取这些临时私钥，自然没法解密流量。
  • 密钥管理风险：如果共享的DH私钥泄露，所有用该私钥生成的会话都会被解密，安全性大打折扣。

内容的提问来源于stack exchange，提问作者Jausk