简短的回答是： 不，并非总是如此。我已经深入研究了这个话题，请在得出结论之前阅读整篇文章。

SSLSniff 是一个概念证明利用平台，可利用 PKI 中的缺陷，例如OCSP中的漏洞或（巧妙的）空前缀证书攻击。如果您使用的是完全打补丁的系统，并且您了解 SSL 错误的含义，那么您无需 HTTPS Everywhere就可以免受大多数（但不是全部）这些攻击。如果您没有针对空前缀证书攻击进行修补，那么证书将显示为有效，并且无处不在的 HTTPS 将毫无用处。如果您不了解 SSL 错误的含义，那么 HTTPS Everywhere 对 SSLSniff 毫无用处。

我认为比 SSLSniff 更令人担忧的是SSLStrip，它也是由 Moxie Marlinspike 编写的，并在他的演讲New Tricks For Defeating SSL In Practice中进行了介绍。 此工具不会导致 ssl 错误。这是利用 HTTP/HTTPS 应用程序层。如果您通过 HTTP 加载页面，它将重写页面删除 HTTPS 链接。它将更进一步，将 favicon.ico 文件更改为锁的图片，以欺骗新手用户。很简单，但绝对是毁灭性的后果。为了应对这种攻击，谷歌引入了严格的传输层安全性(STS)，它很像 HTTPS Everywhere，但内置于浏览器中。还应该注意的是，HTTPS Everywhere 确实可以很好地防御 SSLStrip 攻击。事实上，这是 EFF 针对 SSL 剥离以及粗心的OWASP a9 - 传输层保护不足违规等攻击的解决方案。

那么 HTTPS Everywhere 和 STS 什么时候会失败呢？https://stackoverflow.com怎么样。如果您注意到，他们正在使用自签名证书。 Jeff Atwood 本人并不关心这个问题。由于本网站使用的是自签名证书，HTTP Everywhere 将强制使用 HTTPS，但攻击者仍然可以使用 SSLSniff 传递自己的自签名证书，因此 HTTPS Everywhere 无法保护他人免遭劫持您的 StackOverflow 帐户。

好的，所以此时您可能是在对自己说。“这就是我们有 PKI 的原因！”。好吧，除了 PKI 并不完美。HTTPS 的创建者之一说“PKI 更像是最后一分钟的手波”（参见：SSL 和真实性的未来）。在这次演讲中，Moxie 提出了一个很好的问题，PKI 真的是最好的解决方案吗？我的意思是我们遇到了像DigiNotor 这样的 CA 被黑客入侵的问题。当一个 CA 被黑后，攻击者可以创建一个有效的证书，然后HTTPS Everywhere 完全没用，攻击者仍然可以使用 SSLSniff，因为他有一个“有效”的证书。EFF的SSL 天文台演示了 PKI 系统是多么混乱。我的意思是，是什么阻止了中国为 gmail.com 创建证书？嗯，EFF 正在提议Sovereign Keys 项目，我认为这是一个好主意。除了目前还不存在主权密钥这一事实之外，还有另一个问题， 主权密钥不能帮助像https://stackoverflow.com使用的那样的自签名证书！ 然而莫西想到了这种情况，想出了一个他称之为收敛的解决方案. 融合是依靠群众的信任。主机将从地球上的多个连接中签约，如果其中任何一个看到不同的自签名证书，那么您就知道 MITM 攻击正在发生。有一个错误的警告总比没有好。

总而言之，HTTPS Everywhere 存在根本问题。当用于验证证书的软件存在漏洞时。当用户不了解 SSL 故障的后果时。使用自签名证书时。最后，当我们的受损 PKI 被用来对付您时。这是一个严重的问题，聪明的人正在努力解决它，这包括 EFF 和 SSLStrip 的作者 Moxie Marlinspike。

“HTTPS Everywhere”只是在可能的情况下使用 SSL —— 即自动使用站点的 SSL 版本（如果存在），即使您键入或遵循的链接是针对同名的非 SSL 站点。这就是“HTTPS Everywhere”所做的一切。

“sslsniff”是一种劫持 SSL 连接的攻击工具。它需要两件事：

• 一种拦截受攻击客户端和服务器之间传入和传出低级别流量的方法；sslsniff 主要依赖于 ARP 欺骗，因此攻击者必须与客户端或服务器位于同一 LAN 上。
• 在客户端浏览器中插入攻击者控制的根 CA，或利用客户端浏览器中证书验证代码中的安全漏洞。SSL 安全模型依赖于客户端根据其先验已知的根 CA 证书验证证书；sslsniff 是关于使用动态生成的假证书，但该证书仍然必须为客户端所接受。

所以 sslsniff 和 HTTPS Everywhere 之间真的没有任何联系。sslsniff 不会将HTTPS 连接降级为 HTTP；从客户端和服务器的角度来看，它仍然是 SSL，HTTPS Everywhere 会对此感到非常满意。sslsniff 是“只是”一种利用 SSL 用来确保安全的证书验证模型中的漏洞的工具。

...那么对我的 sslsniff 攻击可以成功吗？

是的。

攻击者能否因为 sslsniff 将连接从 HTTPS 降级为 HTTP 而获取信息？

是的。

让我补充一点，您的描述并不完全符合“sslsniff”的工作原理。SSLsniff 更像是拦截 SSL 流量的代理，而不是简单地降低您的连接。换句话说：与 HTTPS 连接本身相比，SSLsniff 更容易混淆证书。

这意味着你的“插件”实际上可能认为一切都很好，而事实上你的连接是尽可能不安全的，你不会知道它。

或者我在使用 HTTPS Everywhere 时可以“完全安全”免受此类攻击？

不。

永远不要期望“浏览器插件”能够提供“系统保护”。

给你一个人性化的视角：你也不会派童子军去打仗，对吗？当然不是，因为他们不适合也不能胜任这项工作。好吧，就 SSL 安全性而言，也不是一个简单的浏览器插件。

想一想：任何弄乱您的浏览器的人都可能弄乱插件。在最坏的情况下，插件可能会被修改，甚至不会警告您在浏览时“丢失”了安全的 ssl 连接并且您不会知道它。任何病毒、恶意软件甚至新的浏览器漏洞都能够（取决于其个人恶意目的）扰乱您的系统……包括您系统上的软件（包括您的网络浏览器及其插件和插件）。

更新：如果我在 HTTPS Everywhere 中将域列入白名单，会发生什么？[可以创建xml文件]。因此，该域只能通过 HTTPS 访问。

回到您的案例和示例：您担心 HTTPS 连接。您的浏览器可能会使用该连接，但它不能确定它发送或接收的数据没有被拦截，任何插件也不能。实际上，即使您使用“交易工具”，检测这样的“拦截”已经非常困难。您的网络浏览器和所有插件都没有提供任何方法来检测这种“攻击”。反正还没有... SSLsniff 是为了显示 HTTPS 连接的弱点（这不仅会影响网络浏览器）。浏览器供应商是否能够找到针对此类漏洞的可靠“修复”还有待观察。特别是，因为它不是浏览器问题，而是更多的“连接”和“网络安全”问题。http://www.thoughtcrime.org/software/sslsniff/，您会看到在拐角处等着我们的麻烦已经更多了。SSLsniff 工具获得的附加功能显示了这一点……只是为了显示相关问题，例如您最近了解并希望通过使用浏览器插件来解决的问题。

无论如何，让我重复一遍，以保持简短：永远不要指望“浏览器插件”提供“系统保护”。您可能喜欢也可能不喜欢它，但这是对您问题的最短答案，将其全部包含在一行可理解的文本中。我相当长的答案的其余部分只是一些有用的装饰 信息以在需要时提供一些见解。

您仍然容易受到 SSLSniff 的攻击。

SSLSniff 使用 Arp-spoof 作为 MITM。这意味着您的漏洞针对本地 LAN（或 wifi）。

我尚未测试最新的 sslsniff 版本以了解它如何处理证书警告，但这是用户唯一表明设置与远程站点的安全连接有问题的迹象。