SSL/TLS是一种在两方之间提供端到端加密通信的协议，每一方都具有私钥/公钥对中的一个密钥。通常是浏览器和 Web 服务器。

在正常情况下，两个端点之间的任何设备都无法解密通信。这包括防火墙。

然而，可以（并在组织中使用）使用代理服务器来解密和重新加密通信，从而允许拦截和解密（例如用于监视和过滤）。但是，它确实需要将附加证书添加到客户端计算机上的受信任证书存储中（通过软件管理系统自动或由用户手动）。

正如@techraf 所回答的那样，代理/防火墙的重新加密步骤要求您安装额外的证书（公钥以匹配代理拥有的私钥）。

实际上，这是一次 MITM 攻击，但您同意了。

浏览器“信任”流量，但证书链几乎肯定与您在没有过滤器的情况下看到的不同，因为签名链现在引用代理/防火墙签名证书链，而不是在流量源处使用的证书链.

您应该能够确定流量已被检查，但客户端不太可能在没有额外帮助的情况下检测到这一点。如果您有通往同一站点的替代路线，则可以直接请求原始证书并比较证书链。

即使签名链相同，指纹也会不同。

如果有人可以访问您已经信任的公共证书的私钥之一，您将不需要安装额外的证书并且很难发现这一点。世界各地的执法机构可能不会忘记这一事实。端点的唯一区别是（可能）使用哪些签名和根证书来重新密封流量。

请注意，在防火墙的情况下，不涉及“代理”配置，它可以透明地完成。

TLS 1.2 握手中的前几个数据包未加密。这些包括：

• 客户你好（我想用这些密码套件之一与服务器 X 交谈......）
• 服务器你好（好吧，让我们使用密码套件 XYZ）
• 证书（这是我的服务器证书，供您对我进行身份验证）
• 证书请求（向我发送客户证书，我信任这些根...）
• 证书（这是我的客户证书）

之后，数据包被加密。但是防火墙可以并且确实会修改这些数据包，它们可以交换证书或强制使用某些密码套件。

可以使用目标服务器的私钥证书配置服务器端防火墙，这可以允许它随后解密整个 TLS 会话。前提是 RSA 用于密钥交换。如果 Diffie-Hellman 用于密钥交换，则无法解密。但是，如果客户端支持任何使用 RSA 的密码套件，防火墙只能强制使用 RSA 的密码套件（通过修改客户端 Hello 数据包）。