我们正在将我们的 Web 架构迁移到新环境。包括几十个不同的站点，从几乎完全静态的站点到需要身份验证并包含敏感内容的动态站点。我们的 Web 服务器管理员（没有来自开发团队的任何意见）决定将其作为新环境中的标准，以强制所有内容使用 SSL。我不同意这个决定，并希望在我坐下来讨论它时尽可能多地了解它。这是我到目前为止所拥有的：
当用户进行身份验证或请求敏感数据时，我没有强制使用 SSL 的问题。但是，我认为在所有站点上默认强制 SSL 有点过分。
回复托马斯的回答：
对于每个站点，SSL 证书都有直接成本。我们有一个 dev、qa 和 prod 环境，因此每个站点都需要三个证书
几乎不是真的。您不需要让 SSL 背后的每个开发人员和 qa 都使用有效的当前证书。您——也许——想要一个具有有效证书的登台站点。但除了 Apache 前端，您的后端不应该知道其中涉及 SSL。您不会通过购买开发证书来测试任何独特或特殊的东西。
此外，成本是名义上的。你花在谈话上的钱比证书的实际成本还要多。
对于大多数页面，内容不安全，并且由于加密和解密，强制 SSL 会使页面请求在服务器上花费更长的时间
一点。你量过吗？您可能会发现这很难衡量，因为互联网速度的可变性超过了 SSL 处理的成本。
据我了解，大多数浏览器不会缓存经过 SSL 的页面，因此页面请求将需要更长的时间
再说一次，你测量过这个吗？
旧版浏览器在使用 SSL 时会出现文件下载问题
真的吗？您打算支持哪个特定的“旧浏览器”存在此问题？如果你找不到一个并且认为某个地方的某个人可能有这个问题，那么你可能是过度设计了。检查您的日志并查看您的客户实际使用的浏览器，然后确定您是否有问题。
我同意“无处不在的 SSL”不是一个很好的方法。我认为您至少需要一个非 SSL 端口 80 “欢迎”页面。但我不确定您当前的一系列问题是否有充分的理由。我认为您需要更多的测量来证明 SSL 实际上涉及实际成本或实际性能损失。
自 2020 年起，所有网站都应使用 SSL。
有时有人争辩说，仅发布低价值、低信任度、只读公共信息的网站仍应使用 HTTP，但它们也应使用 HTTPS。HTTP 内容仍然可以让攻击者在内容中插入恶意软件或广告软件或重定向。一些主要的 ISP 向所有客户的 HTTP 页面注入广告；如果恶意广告进入他们的提要，这是一个潜在的问题。
建议制定“一切都通过 SSL，没有特定豁免”的公司政策。安全标准（PCI-DSS、ISO、big4 审计等）要求对处理敏感信息的系统进行加密，而缺乏它被认为是危险信号。
您还应该考虑部署HTTP Strict Transport Security以确保即使用户的第一个输入请求example.com也是通过 HTTPS 发送的。
中间人攻击是一个现实问题，尤其是在 wifi 网络上，但在 ISP 和国家层面也是如此。如果您的站点仅使用 SSL 登录，然后通过未加密的链接返回会话 cookie，则该会话 cookie 不仅可以，而且会被窃取。请参阅Firesheep以获得清晰的演示。
SSL 可以为每个用户安全地缓存，无论是会话还是无限期。客户端代理缓存现在很少见，针对这种情况进行优化并不重要。当它们确实存在时，它们通常会出错，通过 SSL 绕过它们是值得的。
正确实现的 SSL 或 SPDY 可以很快：服务器开销不高，并且很容易移动到单独的反向代理机器上。有 SSL CDN。
无需为仅供开发人员和测试人员使用的网站购买真正的证书。即使对于非商业网站，证书的成本也只有几十美元，可以忽略不计。
通过网络加密数据是一个有用的纵深防御层。显然，单靠服务是不够的，但它消除了一些问题，成本低。
即使对于只读数据，客户知道他们正在获取真实站点也是有价值的：例如，如果他们正在下载二进制文件，您不希望插入木马。
安全地将需要通过 SSL 的页面与那些几乎可以肯定可以更好使用的不需要开发人员努力的页面区分开来。
使标准成为各种系统的紧身衣，尤其是在没有协商的情况下，很少需要，但 SSL 上的所有内容都应该有一个强大的默认值。
个案例外情况的良好示例，您仍应提供 SSL 但不强制重定向：
该站点提供大型二进制下载（音乐/视频/软件分发），因此允许更多缓存和更快下载很重要（显示数据）-- 重要的是二进制文件在传输过程中不会被修改，它通过其他验证提供深度防御
客户端是陈旧的 IE 或嵌入式客户端，无法充分执行 SSL-- 到 2020 年，此类客户将非常老旧（并且可能很危险）
网站上有很多资源，您希望机器人通过 HTTPS 对其进行索引-- 如果你强制一切都使用 HTTPS，谷歌和可能的其他机器人会做得很好
如果您在任何地方都使用 SSL，您将使用更多的机器资源，如果它们变得重要，可以以可以优化的方式使用。如果您不使用 SSL，则您要么花费更多的开发人员资源来逐个考虑安全性，要么您很可能更容易发生帐户盗窃。
如果有一点我们想与世界交流，那就是 SSL/TLS 不再是计算昂贵的。十年前它可能是真的，但现在不再是这样了。您也有能力为您的用户启用 HTTPS。
今年 1 月（2010 年），Gmail 切换到默认使用 HTTPS。以前它是作为一个选项引入的，但现在我们所有的用户都使用 HTTPS 来保护他们的浏览器和谷歌之间的电子邮件，一直。为了做到这一点，我们不必部署额外的机器和特殊硬件。在我们的生产前端机器上，SSL/TLS 占 CPU 负载的不到 1%，每个连接不到 10KB 的内存和不到 2% 的网络开销。 许多人认为 SSL 会占用大量 CPU 时间，我们希望上述数字（首次公开）有助于消除这种情况。
所以我已经看到了这个问题的一些很棒的答案，但是几天后我发现有一些东西丢失了。因此，我想提几点：
为什么在所有东西上都使用 SSL
http:在每个资源链接的开头切断，您就很好了。http://并https://作为单独的条目，因此为了保持一致性（在 SEO 和页面行为中），将 SSL 覆盖在所有内容上并设置 301 重定向似乎是一个不错的简单解决方案。https://- 如果您只是一切，您将拥有一个更加一致的网站。当您尝试混合使用 SSL 和非 SSL 时，许多框架都会崩溃。最重要的是，如果您尝试在 和 之间来回切换，依赖于 URL 的插件和代码将非常http重要https。为什么不 SSL 一切
https://（或执行http:// -> //快速解决方案）。如果您有一堆链接，或者如果您将用户提交的内容托管在不支持 SSL 的网站上，这可能会有点乏味。在这些情况下，您的浏览器会对您发牢骚。如果您曾经看到过“此页面包含不安全内容”的通知，您就会知道这有多烦人以及看起来有多糟糕。所以简而言之，这确实是情境性的，但我倾向于避免覆盖 SSL。当然，它确实需要更多的配置，但最终你会得到一个更灵活的系统。我个人认为整个“专业主义”都是胡说八道（Twitter 和谷歌 SSL 一切）。但是，如果您有外部托管的内容或用户发布的内容，那么 SSL 一切通常是一个非常糟糕的主意。您也可能开始对所有内容进行 SSL-ing 并遇到一堆麻烦。
但这只是我。:D
SSL可以禁止网络级缓存。有解决方法，但这可能意味着同一网络中的多台计算机必须重新下载页面资源。这会增加两端的网络负载。浏览器级缓存在现代浏览器中不是问题。
SSL 使所谓的“虚拟域”的使用变得复杂。传统上，为了形成 SSL 连接，浏览器和服务器需要使用相同的域名。这使得不可能在单个 IP 上托管多个 SSL 证书，因为服务器会以错误的证书进行响应。服务器名称指示（SSL 使用的 TLS 协议的扩展）的实现解决了许多问题。
在纯粹的性能上，隧道数据的对称加密和完整性检查并不是很昂贵；如果你的服务器不能以网速加解密，那么要么你有上帝自己的光纤，要么你应该考虑更换那些i486。但是，称为“握手”的 SSL 连接的启动有点昂贵，并且可能意味着重负载时的性能瓶颈（当每秒有数百个连接时，或更多时）。幸运的是，给定的浏览器实例将重用隧道和 SSL 会话，因此如果您只有几十个用户，这不是问题。
总体而言，将 SSL 放在任何地方看起来都是一种在安全性上获得“温暖模糊感”的方法。情况不妙。这通常意味着通过专注于不相关的事情，管理员将更有可能忽视实际的安全问题。它们还将使系统的维护更加复杂，从而使诊断和纠正问题变得更加困难。请注意，从管理员的角度来看，这使他们的工作更加安全，因为它增加了解雇和更换他们的成本。
在对托马斯回答的另一个回应中，尤其是因为它位于顶部。
此外，我将一份白皮书与 SSL 的最佳实践联系起来。
SSL 不仅可以防止来自浏览器的缓存，还可以防止来自代理服务器的缓存。每个网页元素都必须由您的主服务器一次又一次地发送。这增加了网络负载。
只是部分正确。SSL 将阻止代理缓存，但不会阻止浏览器缓存 - 另请参阅此问题的答案。在我看来不是什么大问题。
SSL 防止使用所谓的“虚拟域”。[...]
这是部分正确的。但是，只要您只有一个证书，虚拟域就可以正常工作。即使您不这样做，服务器名称指示 (SNI)也应该是一个可行的替代方案（或者应该是，一旦 Windows XP 脱离地球表面）。
[性能] 但是，称为“握手”的 SSL 连接的启动有点昂贵，> 并且可能意味着重负载时的性能瓶颈（当每秒有数百个连接或更多时）。幸运的是，给定的浏览器实例将重用隧道和 SSL 会话，因此如果您只有几十个用户，这不是问题。
如果您拥有现代硬件，即使握手也不应该在服务器端引起任何性能问题。握手“慢”的主要原因是网络包需要在服务器和浏览器之间来回发送几次——计算能力与它无关。
换句话说：设置 SSL 连接将比渲染从数据库获取数据的 PHP 页面便宜一个数量级。
总体而言，将 SSL 放在任何地方看起来都是一种在安全性上获得“温暖模糊感”的方法。> 这不好。这通常意味着通过专注于不相关的事情，
一点也不真实。要么您的网站根本不需要 SSL，因为它是完全公开的内容。或者您出于某种原因确实需要 SSL（用户登录、受保护区域）。在这种情况下，最佳做法是将其放在任何地方。
仅在页面的某些部分上使用 SSL 会使您面临各种隐晦的风险。虽然您可以通过其他方式找到并缓解这些问题，但与仅在所有页面上启用 SSL 相比，这将更加复杂、容易出错和耗时。
我找到了关于SSL的这份白皮书。我不隶属于编写它的公司，但我发现它非常简洁地总结了部署 SSL 设置时需要记住的所有事项。
这种安全性不言而喻。但是已经犯了第一个错误并不是一个好的开始。
首先要问自己，SSL 给你带来了什么？它为您提供了保证，没有人也没有应用程序可以“嗅探”流量并查看 Web 服务器和浏览器之间发生的情况。成本是购买 SSL 证书的实际成本，以及下载速度略微提高的持续成本。您提到旧版浏览器无法通过 SSL 通信下载文件。我不能说那个，我也不会太在意这个。从安全的角度来看，您还有另一个问题。现代防火墙监控流量以寻找各种黑客攻击。SSL 阻止防火墙监视该通信，因此应用程序开发人员/网络管理员需要更加关注保护他们的应用程序和站点免受各种黑客攻击。长话短说，
我认为您不应该对所有网站都使用 SSL，而且绝对不需要为您的开发环境购买证书。如果您想要/需要用于开发的 SSL 证书，它可以很容易地生成，并且在大多数情况下对于该环境来说已经足够了。另一种可能性是您可以购买通配符证书并将您的开发服务器设置在一个子域中，这样您就可以在两种环境中拥有相同的证书，但同样：如果您购买通配符证书（这更多昂贵）只是为了让开发人员也能在上面工作。如果您在 prod 上有多个需要 SSL 的子域，这是有道理的。
至于速度：是的，这有点问题，但不是那么重要。SSL 响应不会被缓存，因此使用它们会增加您的服务器负载，但我认为这是管理员应该注意的部分。