希望有人会为您进行测试并为卡巴斯基提供明确的答案。同时，这是一般情况的答案：

这取决于。

对自己运行 SSL 代理会削弱您的安全态势吗？当然。任何给定的产品都会像 Superfish 一样削弱您的安全态势吗？这非常依赖于实现，并且还受到针对单个产品本身的威胁。

Superfish 在两个关键点上失败了。

1. 它使用弱密码来保护每个系统都不是唯一的私钥。这导致密钥很容易被破解并公开披露，因此任何人都可以假装是您授权的 Superfish 代理。

2. 它未能正确验证 SSL 证书的某些条件，这使得 Superfish 代理可以接受其他无效的证书并将网站呈现给最终用户，就好像它是合法的一样。

虽然第一部分是一个重要的突破，但第二部分可以说是最关键的缺陷。如果没有第二个缺陷，只要密钥保持秘密，用户仍然会受到相对较好的保护。（Kerckhoffs 原理在起作用。）然而，鉴于第二个缺陷，攻击者甚至不需要密钥就可以在 Superfish 用户和其他安全网站之间发起令人信服的中间人攻击。

考虑到这一点，有一些简单的对策可以在很大程度上保护用户。

1. 为每个安装生成唯一的根密钥，使用强且唯一的密码保护它们，并且不要将密钥分发到代理所在的主机之外。这可以防止泄露一个系统的密钥对任何其他系统的安全性产生重大影响。

2. 正确验证 SSL 证书，并在出现问题时向用户提供适当的通知。没有这个，密钥就无关紧要了——攻击者只需要通过利用验证过程中的缺陷让代理相信他们的网站是合法的，代理就会向用户展示网站。

把这些事情做对，你就可以开始了——对吧？嗯，不完全是。

看，现在我们遇到了向用户提供证书的问题。因为代理必须拦截流量，并用自己的凭据重新加密，所以用户仍然看不到站点的原始凭据。每个站点似乎都有代理颁发的证书，其日期和时间戳取决于代理生成 MitM 证书的时间。这完全消除了用户自己决定哪些 CA 或他们认为可信的信任路径的能力，或者识别证书随时间发生的变化的能力。它还可以防止证书与其他受信任的外部实体的证实。

以 DigiNotar 为例，攻击者能够使用普遍信任的根 CA 为 Google 服务生成伪造证书。如果没有 SSL 代理，用户可能会通过多种方式中的一种或多种方式收到可疑活动的警报。

• 浏览器插件或其他实用程序可以将证书与同一用户先前在同一站点看到的其他证书进行比较，并提醒用户意外更改。（例如：与以前不同的 CA，颁发的新证书与先前证书的到期时间完全不同步等）
• 浏览器插件或其他实用程序可以将证书与在线社区或其他受信任机构在该站点报告的证书进行比较，并提醒用户意外差异（例如：您所在地区 98% 的用户报告看到的证书与你看到的一个）。
• 勤奋的用户可能会经常自己检查证书并注意到不寻常的变化。

使用代理，最终用户不再可以使用所有这些选项。代理本身可能被配置为监视和警告这些问题（就像某些浏览器插件一样），但最终最终用户仍然无法亲自看到它。