破坏您的根 CA 或中间 CA 比破坏商业 CA 更容易，因此当您的员工直接连接到 Internet 时，它降低了在 HTTPS 连接上安装用户无法检测到的中间人攻击的成本（例如咖啡店wifi）。我不认为这是一个非常大的威胁。

恶意雇主/系统管理员/受损代理服务器给用户带来的风险明显增加——攻击者现在可以拦截和窃取他们所有的个人社交网络/电子邮件/银行凭据。

在操作上，这导致了不在代理服务器的受信任存储中的根证书的问题。如果网络管理员没有跟上设备上的补丁程序，或者设备已过期（请参阅 Bluecoat），这很常见。

我注意到使用 HTTPS 代理的服务器存在许多问题，尤其是代理无意中代理了负载平衡器等网络设备时。为此，我们禁用了服务器代理。

最后，在内部部署 CA 基础架构并使其具有高可用性可能会出现问题。CRL 必须可通过 HTTP（不是 HTTPS）获得，并且需要正确配置 OCSP。

如果 CRL 更新不够频繁（如 中所述next update），那么某些内部客户可能会基于他们无法证明证书已被撤销的前提而拒绝该证书。

最后，根证书必须在所有适用的本地存储中。例如，Java、Firefox、IE/Windows 都有不同的商店需要更新。部署证书并不像通过 GPO 部署它那么简单。

在部署此根证书时，还要考虑您的非 AD 设备，例如 Mac、iPhone、非集中管理 (BYOD) 的移动设备。

底线

部署集中式 SSL 代理所涉及的复杂性可能会在您的安全策略中造成意外和/或未维护的漏洞。

应该有一个全面的解决方案来维护、免除或禁止不符合安全策略的不兼容组件。这应该尽可能简单。

e.g. Exempt servers, and mobile devices on wifi.  Everything on corpnet as a workstation must be proxied.

风险与向指定的保安人员提供打开建筑物所有门的钥匙所暗示的风险大致相同：

• 守卫成为有价值的目标；攻击者会想抢劫守卫或贿赂守卫，以获得金钥匙。

• 包罗万象，密钥绕过所有程序和安全层；如果潜在的攻击者有一把可以打开所有门的钥匙，您就无法将建筑物的各个部分相互隔离。

• 仅仅知道某些保安人员手中存在一个开放的一切密钥将使用户非常不信任。人类用户倾向于重视他们的隐私，并且不喜欢有人会定期打开他们的办公桌和储物柜并检查内容的想法。

除了关键的类比之外，使用 SSL 拦截（使用特定于组织的 CA 来即时构建MitM 攻击）具有以下特定后果：

• 在桌面系统上，拦截需要在“受信任的存储”中安装特殊的 CA 证书。每次安装新操作系统时都必须重新安装；用户可以自行删除；一些 Web 浏览器（特别是 Firefox）会忽略操作系统信任存储并使用它们自己的。因此，这里有足够的破损空间。这可以通过锁定操作系统配置和软件安装来解决，但是你锁定的越多，用户就越不开心。

• 操作系统信任库可用于 SSL 以外的其他用途；例如，它可用于验证软件更新和驱动程序的签名。成功窃取组织 CA 私钥的攻击者可能因此获得整个网络的广泛权力，而不仅仅是拦截 SSL 连接的能力（这已经很多了）。

• 因此，组织 CA 的私钥是敏感的，但无法使用高隔离层进行保护，因为通过构造，该特殊 CA必须能够即时发布虚假的 SSL 服务器证书。所以它必须在线，在“靠近互联网”的服务器上。

• 这种中间人拦截破坏了基于证书的客户端身份验证。https://网站很少使用客户端证书，但我看到一些银行使用它来验证他们的客户（至少作为实验部署的一部分）。

• 在许多司法管辖区，雇主对用户通信的自动检查是合法的，但受制于某些条件，通常是雇员合同中的明确通知。此类拦截可能存在法律风险（类似于阅读信件、窃听电话和在办公室安装摄像机）。强烈建议绕行法律部门。

所以我们可以说，虽然组织 SSL 拦截允许检查 SSL 下载的内容（因此可以在代理上应用防病毒和其他过滤器），但它也打开了新的漏洞。因此，安装此类系统可能会恶化整体安全状况。

我可以看到的主要风险是代理服务器本身的受损。这将允许攻击者解密通过该系统的所有流量。

事实上，这种设置与某些身份验证机制不兼容：任何依赖 SSL 客户端证书身份验证的系统都将无法工作。

更广泛的问题是实现本身的质量：它需要使用私有根 CA 以及中间 CA，并具有适当的撤销机制和对所有 CA 元素的严格安全性。在设计阶段做事不当可能会留下比你的 SSL 流量更多的东西。