如果攻击者正在做一个中间人以在流中注入好的答案，我当然不会介意......

更严重的是，StackExchange 依赖于大多数人基本上是诚实的，而大多数攻击者基本上都是人，即懒惰。维持一个有效的大规模中间人攻击需要相当多的努力和资源，因此我们可以假设绝大多数与 SE 站点的连接不会被篡改。不是很让人放心，但文明的整个概念建立在更脆弱的基础上，我们已经学会了与之共存（偶尔但并非如此罕见，为它而死）。

从 SE 经理的角度来看，这是一种权衡：他们会从站点范围的 SSL 中获得什么，他们会失去什么？站点范围的 SSL 增加了 CPU 负载，但幅度不大：根据 Google 的说法，CPU 仅增加了 1%，网络带宽增加了 2%。这是在 Gmail 的背景下；一个 SE 站点有不同的使用模式，特别是提供大量可以缓存的“公共且大部分是静态数据”（例如，通过 ISP 安装的透明代理）。最大的成本可能是引用：尽管搜索引擎现在索引 HTTPS 内容，但可以想象它们处理它的方式与处理 HTTP 内容的方式不同。搜索引擎优化是免费网站的生命力。总而言之，切换到全站点 HTTPS 似乎存在一些成本或风险（从经济上讲，它们是相同的）。

另一方面，SE 会从全站 HTTPS 中获得什么？他们不保证数据的真实性，并且是公开的。保证传输中数据的机密性和完整性有什么意义，而这些数据一开始就不是机密的，也不能证明是真实的？而且，更重要的是，SE 会从中赚到更多的钱来弥补额外的成本吗？请记住，StackExchange 是一家私营企业。他们不是特蕾莎修女。他们想以一种或另一种方式赚钱。

因此，从逻辑上讲，SE 管理者只有在他们认为全站点 HTTPS 会带来足够多的读者时才会设想它。这对我来说似乎很可疑。我并不是说我一般不想要更多 SSL。但我不能责怪 SE 维护者选择其他方式。

未经证实，您永远不应该相信您在互联网上阅读的任何内容。

该站点提供了有用的资源并与一些真正了解安全性的人进行讨论。但是您在这里（以及其他任何地方）阅读的所有内容都需要独立确认。

虽然没有 SSL 传输的页面实际上可能会被篡改，但您阅读的信息很可能是完全错误的——在这里和其他任何地方。与 Wikipedia 一样，StackExchange 不应被视为信息的“主要来源”。这是一个需要独立确认的信息集合。

我的 2 美分，并不是从 IT 安全的角度来看：

理想情况下，您将关联和检查在此站点上找到的信息。一般来说，答案分为两类：

• 总结或解释相关信息。

• 提供原创的想法或分析。

第一个最终归结为有人重写现有的人类知识。在这些情况下，如果您需要任何重要的信息，您可能应该验证答案并在其他地方检查它们。例如，“SE 上的某个人这么说”不是一个好的合作 IT 政策的独裁者，您应该在遵循之前理解并同意所说的话。

在这些情况下，您将寻求 IT.SE 上提到的信息，并在您的研究中从其他来源获取。您应该会在其他地方看到相同的事实和解释。任何对您和 IT.SE 执行 MITM 的人都将被迫对您查看的所有其他来源执行 MITM。虽然并非不可能，但它提高了攻击难度，以至于他们需要过滤您的整个 Internet 浏览体验。在这一点上，问题更多是关于缺乏通用 HTTPS 以及互联网连接本身是否安全。

对于包含非常困难或几乎不可能以另一种方式验证的原始信息的偶尔帖子，这是一个有效的观点。攻击者可能会破坏您自己的信息来源。但不幸的是，大多数其他地方也不通过 HTTPS 托管此类内容。这不是 IT.SE 独有的。

真的，你不能。信息没有认证。也就是说，一般而言，在该向量中进行有意义的攻击的可能性可能相当小，因此银行可能认为在页面上使用 SSL 是不值得的（它确实需要更多的服务器资源来执行 HTTPS）。什么是好的权衡和什么不是的平衡点总是一条模糊的线，但例如，如果攻击者发布了一个电话号码，它必须实际注册给一个人，并且更容易追踪谁来负责，而简单地攻击登录凭据以使他们在网络钓鱼站点上输入它通常比 MitMing 网站本身更容易。

但是不，没有办法证明这个数字是正确的。

另外，为了将来参考，如果您碰巧在该站点上，因为您认为您的计算机感染了病毒，并且该站点说，不要从轨道上对其进行核攻击，那么显然您的病毒正在攻击所提供的内容，因此您应该从轨道上对其进行核打击。:)