他们可以欺骗服务器的身份，而不是“绕过”加密，从而（有效地）执行 MITM 攻击。

设置 SSL/TLS 连接时，加密本身只是配置的一部分：这确保了客户端和服务器之间通信的机密性。在此之前，客户端需要验证服务器的身份，以确保它与它期望的一方秘密地交换数据：这就是证书的用途。

X.509 证书由 CA 为给定的服务器名称颁发。如果浏览器信任这个 CA（大多数浏览器默认提供了许多信任锚），它可以信任它的内容：它的公钥和它包含的名称之间的绑定。浏览器还必须检查它正在寻找的服务器名称是否是证书中的名称之一。

政府可以做的是要求您信任其 CA 证书（和/或让大型 CA 给他们一个中间 CA 证书），以便他们可以为其监控设备颁发证书，从而欺骗真实的服务器证书。该设备将成为服务器并解密连接，然后充当真实服务器的客户端：然后您将拥有 2 个加密部分：一个在客户端和监控设备之间，一个在该设备和真实服务器之间。

存在执行此操作的设备（有时称为“MITM 代理服务器”），通常用于企业网络。

除了控制该 CA 私钥的任何人都可以查看和更改客户端对 HTTPS 站点的任何流量（这里有许多非技术问题）之外，在执行此操作时还存在许多技术问题。国家规模：

• 这些代理服务器可能需要在浏览器中显式配置（作为 HTTP 代理）。

  事实上，透明地实现 MITM 代理是相当困难的，因为它不能总是通过查看初始 TCP 数据包来获得它应该放入它动态生成的证书中的名称。如果不使用服务器名称指示（SNI 现在很常见，但并非所有客户端都支持），它所能获得的只是服务器的 IP 地址，不一定会解析回预期的名称。例如，如果您获得地址www.facebook.com并进行反向 DNS 查找，您将获得类似www-XYZ-XYZ.facebook.com. 它可以在这里与通配符一起使用，但通常不能预期这种模式。

• 这将使任何使用客户端证书身份验证的服务中断。由于在 SSL/TLS 握手期间，当使用客户端证书时，客户端在最后签署所有握手消息（包括服务器证书）的串联，服务器将其与它发送和接收的内容（包括真实证书）。如果中间有东西插入它自己的证书，这将使这个验证失败。

• 握手的建立肯定会有延迟，因为证书可能必须动态生成。（有些可以被缓存。）

• 这期望用户“玩得好”并使用他们打算做的端口。替代端口可能不受监控或必须完全防火墙。

• 为了以可用的形式追踪 Facebook/Google+/Gmail 交换，这些设备还需要能够查看页面结构（或 AJAX 的 JSON 有效负载）并能够提取相关数据（或存储所有内容）它无法理解某处）。这些服务的内部 API 的任何细微变化都需要进行一些昂贵的调整。

为所有 HTTPS 通信做这一切肯定需要大量的计算能力并产生大量的电费。

（顺便说一句，导致内政部制定此类计划的报告可能是在 Facebook 将所有内容切换到 HTTPS 之前起草的。）

他们将获得一个位于 CA 根区域中的 CA，供所有浏览器向他们颁发有效证书。该 CA 可能是一家英国公司。间谍活动对用户完全透明。浏览器不会显示任何警告。这将持续几天，直到公众检测到浏览器供应商将撤销相关 CA 的根证书，就像他们过去由于一些 CA 的安全问题所做的那样。除非有人使用非常周的协议，否则没有其他实用的方法可以解密加密连接，但这不太可能。他们也可以只安装这些盒子，然后有选择地使用它们，只针对他们希望监视的人，而不是所有人。在这种情况下，它可能不会被检测到，CA 证书也不会被拒绝。