所有网站都应默认使用SSL吗？

Question

我们正在将Web架构转移到新环境。包括几十个不同的站点，从几乎完全静态到动态站点，需要身份验证和包含敏感内容。我们的Web服务器管理员（没有来自开发团队的任何输入）决定使其成为新环境中的标准，以强制所有内容使用SSL。我不同意这个决定，并希望在我坐下来讨论它时尽可能多地获得知识。这是我到目前为止所做的：

• 对于每个站点，SSL证书都有直接成本。我们有一个dev，qa和prod环境，因此这是每个站点需要的三个证书
• 对于大多数页面而言，内容不安全，并且强制SSL会因为加密和解密而导致页面请求在服务器上花费更长时间
• 根据我的理解，大多数浏览器不会缓存SSL的页面，因此页面请求会花费更长时间
• 较旧的浏览器在使用SSL时会出现文件下载问题

在用户进行身份验证或请求敏感数据时，我没有遇到强制SSL的问题。但是，我认为在所有站点上默认强制SSL有点多。

Answer 1

回复Thomas's answer：

  

对于每个站点，SSL证书都有直接成本。我们有一个dev，qa和prod环境，因此每个站点需要三个证书

很难说。您不需要使用有效的当前证书将SSL后面的每个dev和qa都包含在内。您 - 也许 - 想要一个具有有效证书的临时站点。但是除了Apache前端之外，你的后端不应该知道涉及到SSL。您不是通过购买开发证书来测试任何独特或特殊的东西。

此外，成本是名义上的。与证书实际花费相比，你在谈话上花的钱更多。

  

对于大多数页面而言，内容不安全，并且强制SSL会因为加密和解密而导致页面请求在服务器上花费更长时间

一点点。你测量过吗？您可能会发现很难衡量，因为互联网速度的变化超过了SSL处理的成本。

  

根据我的理解，大多数浏览器不会缓存SSL的页面，因此页面请求将需要更长的时间

再次，你有没有测量过这个？

  

较旧的浏览器在使用SSL时会出现文件下载问题

真的？你计划支持哪个特定的“旧浏览器”有这个问题？如果你找不到一个，并且认为某个人，某个地方可能有这个问题，你可能会过度工程。检查您的日志，查看客户实际使用的浏览器，然后确定您是否遇到问题。

我同意“无处不在的SSL”并不是一个很好的方法。我认为您至少需要一个非SSL端口-80“欢迎”页面。但我不确定你目前的一系列问题是否有充分的理由。我认为你需要更多的测量来证明SSL实际上涉及实际成本或真正的性能命中。

Answer 2

截至2012年，网站如果有个人身份信息（PII）或商业重要信息，或者他们有任何登录概念，则应仅使用SSL。

仅发布低价值，低信任的只读公共信息的网站有点争论，但可能仍然可以通过HTTPS提供有用的服务。攻击者可能会尝试将恶意软件或广告软件或重定向插入HTTP内容。

“一切通过SSL，没有特定豁免”的公司政策是合理的。

您还应该考虑部署HTTP Strict Transport Security以确保即使用户通过HTTPS发送键入example.com的第一个请求也是如此。

中间人攻击是一个现实世界的问题，尤其是在无线网络上，但也在ISP和国家层面。如果您仅通过SSL执行登录阶段，然后传递未加密的会话cookie，则该会话cookie将被盗。请参阅Firesheep以获得明确的演示。

SSL可以为每个用户安全地缓存，无论是会话还是无限期。客户端代理缓存现在很少见，并且针对该情况进行优化并不重要。当它们存在时，它们通常会出错并通过SSL绕过它们是值得的。

正确实施SSL或SPDY可能很快：服务器开销不高，很容易移动到单独的反向代理机器上。有SSL CDN。

没有必要为仅供开发人员和测试人员使用的网站购买真正的证书。即使对于非商业网站，证书的成本，低至数十美元，也可以忽略不计。

通过网络加密数据是一个有用的深层防御层。显然，使服务安全是不够的，但它消除了某些问题并且成本低。

即使对于只读数据，客户也知道他们正在获取真实网站的价值：例如，如果他们正在下载二进制文件，则不需要插入特洛伊木马。

安全地区分需要通过SSL的页面和那些不需要开发人员努力的页面，这些页面几乎可以更好地使用。

使标准成为各种系统的紧身衣，尤其是在没有咨询的情况下，从来都不是好事。但是说除非在一个案例中有特殊原因，否则所有网站都应该使用SSL，这对我来说是有道理的。逐案例外的好例子，您仍应提供SSL但不强制重定向：

• 该网站提供大量二进制下载（音乐/视频/软件发行版），因此允许更多缓存和更快下载非常重要（显示数据）
• 客户是古老的IE或嵌入式客户端，无法充分地进行SSL（再次证明它实际上是一个问题）
• 网站上有很多资源，您希望机器人通过HTTPS
对其进行索引

如果您在任何地方使用SSL，您将使用更多的机器资源，如果它们变得重要，可以进行优化。如果您不使用SSL，则可以花费更多的开发人员资源来逐案考虑安全性，或者很可能您更容易被盗用。

Adam Langley of Google wrote in 2010：

  

如果我们想要向全世界传达一点，那就是SSL / TLS不再具有计算成本。十年前它可能是真的，但事实并非如此。您也可以为用户启用HTTPS。

     

今年1月（2010年），Gmail默认情况下切换为使用HTTPS。以前它已作为选项推出，但现在我们所有用户都使用HTTPS来保护他们的浏览器和Google之间的电子邮件。为了做到这一点，我们不得不部署额外的机器和没有特殊的硬件。在我们的生产前端机器上，SSL / TLS占CPU负载的不到1％，每个连接少于10KB的内存，不到2％的网络开销。许多人认为SSL占用了大量的CPU时间，我们希望上述数字（首次公开）将有助于消除这一点。

Answer 3

SSL 可以禁止网络级缓存。有一些解决方法，但这可能意味着同一网络中的多台计算机必须重新下载页面资源。这会增加两端的网络负载。浏览器级缓存在现代浏览器中不是问题。

SSL使所谓的“虚拟域”的使用变得复杂。传统上，为了形成SSL连接，浏览器和服务器需要使用相同的域名。这使得无法在单个IP上托管多个SSL证书，因为服务器将使用错误的证书进行响应。 Server Name Indication（SSL使用的TLS协议的扩展）的实现解决了许多问题。

在纯粹的性能上，隧道数据的对称加密和完整性检查不是很昂贵;如果您的服务器无法以网络速度加密和解密，那么要么您拥有上帝自己的光纤，要么您应该考虑更换那些i486。但是，启动SSL连接（称为“握手”）要贵一些，并且可能意味着重负载（当每秒有数百个连接或更多时）的性能瓶颈。幸运的是，给定的浏览器实例将重用隧道和SSL会话，因此如果您只有几十个用户，这不是问题。

总的来说，将SSL放在任何地方看起来像是一种在安全性上获得“温暖模糊感”的方法。这个不好。这通常意味着通过专注于不相关的问题，管理员将更有可能忽视实际的安全问题。它们还会使系统维护更加复杂，使诊断和纠正问题变得更加困难。请注意，从管理员的角度来看，这使他们的工作更加安全，因为它增加了解雇和替换它们的成本。

Answer 4

所以我已经看到了这个问题的一些精彩答案，但几天后我发现缺少一些东西。因此，我想提一下几件事：

为什么在所有内容上使用SSL

• 安全性 - 如果只有几页是SSL加密的，则更容易“嗅探”哪些页面包含敏感数据。现在SSL非常安全，所以这不是什么值得担心的问题，但是如果您的私钥被泄露，那么拥有额外的安全层是很好的做法，这样坏人就很难进入多汁的东西。
• 可信度 - 有人认为，当您访问具有经过验证的证书的网站时，更容易信任。由于经过验证的证书需要花钱，因此知道所有者投资于信任的象征时，更容易信任一个站点。
• 麻烦 - 在SSL下覆盖所有内容都非常简单。您所要做的就是在每个资源链接的开头切断http:并且您很好。
• SEO配置 - 您不必为SEO配置烦恼。我听说搜索引擎将http://和https://索引为单独的条目，因此为了保持一致性（在SEO和页面行为中），将SSL覆盖在所有内容上，只需设置301重定向就好了简单的解决方案。
• 一致性 - 如果您只是https://，那么您将拥有更加一致的网站。当您尝试执行SSL和非SSL的混合时，许多框架会中断。除此之外，如果您尝试在http和https之间来回跳转，那么依赖于URL的插件和代码将非常有意义。
• 模糊安全感 - 你不得不承认，左上方的那个小绿栏表示“验证域名”只是一种该死的好感觉。

为什么不是SSL一切

• 速度 - SSL速度较慢。当然，并不是很多，而且大多数时候成本可以忽略不计。然而，这是一个不可避免的事实，SSL总是会变慢。
• 浏览器兼容性 - 这可能是微不足道的，但如果您想支持不通过SSL缓存的真正旧浏览器，则必须坚持使用端口80。
• 插件 - 一堆插件无法通过SSL正常运行，因此您必须小心。如果您想要添加新插件，则必须重新配置SSL设置或寻找其他插件。
• 专业性 - 现在虽然有些人认为看到经过验证的SSL域似乎值得信赖，但其他人认为这是一个非常业余和懒惰的解决方案。事实上，获得经过验证的SSL证书可以轻松便宜（花费我10美元左右），这些证书可以达到96％的浏览器！
• 麻烦 - 所以我确实说过SSL更容易，但同时你必须确保通过https://加载每个资源（或者做http:// -> //快速解决方案）。如果您有一堆链接甚至不兼容，如果您在不支持SSL的站点上托管用户提交的内容，则可能有点单调乏味。在这些情况下，您的浏览器会抱怨您。如果您曾经看到过“此页面包含不安全内容”的通知，您就会知道它有多烦人，看起来有多糟糕。

所以简而言之，它确实是情境化的，但我倾向于避免覆盖SSL。当然，它需要更多的配置，但最终你会得到一个更灵活的系统。我个人认为整个“职业化”的事情是废话（Twitter和谷歌SSL一切）。但是，如果您有外部托管的内容或用户发布的内容，那么SSL通常是一个非常糟糕的主意。你也可能开始SSL所有事情，并遇到一堆麻烦。

但那只是我。 ：d

Answer 5

首先要问问自己，SSL会为您带来什么？它向您保证，没有人和任何应用程序都可以“嗅探”流量并查看Web服务器和浏览器之间的内容。成本是购买SSL证书的实际成本，以及下载速度略有提高的持续成本。您提到旧版浏览器无法通过SSL通信下载文件。我不能这样说，我也不会过多地关注自己。 从安全角度来看，您还有另一个问题。现代防火墙监控流量，寻找各种黑客企图。 SSL阻止防火墙监视该通信，因此应用程序开发人员/ Web管理员需要更加关注保护其应用程序和站点免受各种黑客攻击。 长话短说，人们应该只加密真正需要它的通信。

Answer 6

对托马斯回答的另一个回应，特别是因为它在最前面。

此外，我进一步关联了white paper with best practices for SSL。

  

SSL防止缓存，不仅来自浏览器，还来自代理服务器。每个网页   元素必须由您的主服务器一次又一次地发送。这增加了网络   负荷。

只是部分正确。 SSL将阻止代理缓存，但不浏览器缓存 - 也会看到this question的答案。在我看来，这不是一个大问题。

  

SSL阻止使用所谓的“虚拟域”。 [...]

这是部分正确的。但是，只要您只有一个证书，虚拟域就可以正常工作。即使你没有，Server Name Indication (SNI)应该是一个可行的选择（或者应该是，一旦Windows XP脱离了地球的面貌）。

  

[性能]然而，启动SSL连接，称为“握手”，有点贵，＆gt;并且可能意味着重负载的性能瓶颈（当每秒有数百个连接或更多时）。幸运的是，给定的浏览器实例将重用隧道   和SSL会话，因此如果您只有几十个用户，这不是问题。

如果您拥有现代硬件，即使握手也不会在服务器端造成任何性能问题。握手“慢”的主要原因是由于网络包需要在服务器和浏览器之间来回发送几次 - 计算能力与它几乎没有关系。

换句话说：设置SSL连接比呈现从数据库中获取数据的PHP页面便宜一个数量级。

  

总的来说，将SSL放在任何地方看起来像是一种在安全性上获得“温暖模糊感”的方法。 ＆GT;这个不好。这通常意味着通过专注于无关紧要，

一切都不正确。您在网站上根本不需要SSL，因为它完全是公共内容。或者您出于某种原因需要SSL（用户登录，受保护区域）。在这种情况下，最好的做法是把它放在任何地方。

仅在页面的某些部分使用SSL可以打开各种模糊的风险。虽然您可以通过其他方式找到并缓解这些问题，但与仅在所有页面上启用SSL相比，它将更加复杂，容易出错且耗时。

我找到了this white paper on SSL。我与编写它的公司没有任何关系，但我发现它是在部署SSL设置时需要记住的所有事项的简明摘要。

安全性不止一个组件不言而喻。但是已经犯了第一个错误并不是一个好的开始。

Answer 7

我认为您不应该对所有站点进行SSL，并且您不需要为您的开发环境购买证书。如果您想要/需要一个开发人员的SSL证书，它可以很容易地生成，并且在大多数情况下将适用于该环境。另一种可能性是您可以购买通配符证书并在其中一个子域中设置开发服务器，这样您就可以同时为两个环境提供相同的证书：如果您购买通配符证书（这是更多的话，这是浪费钱）昂贵的）只是为了开发它也是如此。如果prod上有多个子域需要进行SSL处理，这是有道理的。

至于速度：是的，它有点问题，但不是很重要。 SSL响应没有缓存，因此使用它们会增加服务器负载，但我认为这是管理员应该注意的部分。