所有网站是否应该默认使用SSL?

我们正在将我们的networking架构转移到新的环境中。 包括几十个不同的网站,从几乎完全静态的网站到需要authentication并包含敏感内容的dynamic网站。 我们的Web服务器pipe理员(没有任何开发团队的任何意见)决定在新的环境中将其作为一项标准,以强制所有的SSL。 我不同意这个决定,并且当我坐下来讨论这个问题的时候,希望有尽可能多的知识。 以下是我到目前为止:

  • 对于每个站点,SSL证书都有直接成本。 我们有一个dev,qa和prod环境,因此这是每个站点需要的三个证书
  • 对于大多数页面来说,内容是不安全的,强制SSL会使服务器上的页面请求花费更长的时间,因为encryption和解密
  • 据我所知,大多数浏览器不会caching已经SSL的页面,因此再次页面请求将花费更长的时间
  • 较旧的浏览器在进行SSLencryption时遇到文件下载问题

当用户进行身份validation或他们请求敏感数据时,我没有强制SSL的问题。 不过,我认为所有网站默认强制SSL是有点多。

SSL 可以禁止networking级别的caching。 有解决方法,但这可能意味着同一networking中的多台计算机不得不重新下载页面资源。 这可能会增加两端的networking负载。 浏览器级caching在现代浏览器中不是问题。

SSL使得所谓的“虚拟域”变得复杂。 传统上,为了形成SSL连接,浏览器和服务器需要工作到相同的域名。 这使得无法在一个IP上托pipe多个SSL证书,因为服务器将以错误的证书进行响应。 服务器名称指示 (SSL使用的TLS协议的扩展)的实现已经解决了这个问题的许多问题。

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

总的来说,把SSL放在每个地方看起来都是一种在安全方面获得“温暖的模糊感觉”的方法。 不是很好。 这通常意味着,通过专注于无关紧要的事情,pipe理员将更可能忽视实际的安全问题。 也会使系统维护更加复杂,更难以诊断和纠正问题。 请注意,从pipe理员的angular度来看,这使得他们的工作更加安全,因为它增加了解雇他们的成本。

回答托马斯的回答 :

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

几乎没有。 您不需要拥有有效的当前证书的每个开发者和qa背后的SSL。 你 – 也许 – 需要一个有效的证书登台网站。 但是除了Apache前端之外,您的后端不应该知道涉及SSL。 您不是通过购买开发证书来testing任何独特或特殊的东西。

而且,成本是名义上的。 你花在交谈上的钱比证书实际花费更多。

对于大多数页面来说,内容是不安全的,强制SSL会使服务器上的页面请求花费更长的时间,因为encryption和解密

一点。 你有没有测量? 您可能会发现很难衡量,因为互联网速度的可变性胜过了SSL处理的成本。

据我所知,大多数浏览器不会caching已经SSL的页面,因此再次页面请求将花费更长的时间

再次,你有没有测量这个?

较旧的浏览器在进行SSLencryption时遇到文件下载问题

真? 你打算支持哪一个特定的“老浏览器”有这个问题? 如果你找不到一个人,在想某个人,某个地方可能有这个问题,那么你可能是在过度工作。 检查你的日志,看看你的客户实际使用的浏览器,然后确定是否有问题。

我同意“到处都是SSL”不是一个很好的方法。 我认为你至less需要一个非SSL端口-80“欢迎”页面。 但是我不确定你目前的一系列问题是否可靠。 我认为你需要更多的测量来certificateSSL实际上涉及真正的成本或真正的性能命中。

截至2012年, 如果网站具有个人身份信息(PII)或商业重要信息,或者他们有任何login概念,则应仅使用SSL。

只发布低价值,低信任的只读公共信息的网站有点争议,但可能仍然可以通过HTTPS提供一切有用的服务。 攻击者可能会尝试将恶意软件或广告软件,或redirect到HTTP内容中。

“一切顺利,没有特定豁免”的公司政策是合理的。

您还应该考虑部署HTTP严格传输安全性 ,以确保用户的第一个inputexample.com的请求是通过HTTPS发送的。

中间人攻击是一个现实世界的问题,尤其是在无线networking上,而且在ISP和国家层面上。 如果您仅通过SSL进行login阶段,然后未encryption传递会话cookie,那么会话cookie将被盗用。 请参阅Firesheep以获得清晰的演示。

每个用户都可安全地cachingSSL,无论是会话还是无限期。 客户端代理caching现在很less见,针对这种情况进行优化并不重要。 当他们确实存在的时候,他们通常把事情弄错了,通过SSL绕过他们是值得的。

正确实施SSL或SPDY可以很快:服务器开销不高,很容易移到单独的反向代理机器上。 有SSL CDNs。

没有必要为仅供开发人员和testing人员使用的网站购买真正的证书。 即使是非商业的网站,证书成本也只有几十美元,可以忽略不计。

通过networkingencryption数据是一个有用的深层防御层。 显然单靠服务是不够的,服务是安全的,但是消除了一些问题,成本也很低。

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

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

为不同的系统制定标准,尤其是没有咨询的情况下,标准并不好。 但是说,网站应该都是SSL,除非有一个特别的理由,否则在一个情况下对我来说是有意义的。 个案例外的好例子,你仍然应该提供SSL但不强制redirect:

  • 该网站正在提供大量的二进制下载(音乐/video/软件分发),因此允许更多的caching和更快的下载非常重要(显示数据)
  • 客户端是陈旧的IE或embedded式客户端,只是不能充分做SSL(再次,显示它实际上是一个问题)
  • 网站上有非常多的资源,您希望漫游器通过HTTPS对其进行索引

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

Google的Adam Langley在2010年写道 :

如果有一点我们想要与世界沟通,那么SSL / TLS在计算上就不再昂贵了。 十年前,这可能是事实,但事实并非如此。 您也可以为您的用户启用HTTPS。

在今年1月份(2010年),Gmail切换为默认使用HTTPS。 之前它已经作为一个选项被引入,但是现在我们所有的用户一直使用HTTPS来保护他们的浏览器和Google之间的电子邮件。 为了做到这一点,我们不得不部署额外的机器,并没有特殊的硬件。 在我们的生产型前端机器上,SSL / TLS占用的CPU负载不到1%,每个连接的内存less于10KB,networking开销less于2%。 许多人认为SSL需要很多CPU时间,我们希望上述数字(首次公开)有助于消除这一点。

所以我已经看到了这个问题的一些奇妙的答案,但几天后,我看到有一些东西丢失 。 因此,我想提一些事情:

为什么在一切中使用SSL?

  • 安全性 – 如果只有几页是SSLencryption的,则更容易“嗅出”哪些页面包含敏感数据。 现在,SSL是非常安全的,所以这不是什么可担心的事情,但是如果你的私钥被攻破,那么最好有一个额外的安全层,这样坏人就很难进入多汁的东西。
  • 可信度 – 有人争辩说,当您访问拥有经过validation的证书的网站时,更容易相信。 由于经过validation的证书要花钱,所以信任一个知道所有者投资于信任的象征的网站会更容易。
  • 麻烦 – 在SSL下覆盖所有东西就简单多了。 所有你需要做的就是在每个资源链接的开头切断http:你很好。
  • search引擎优化configuration – 你不必打扰SEOconfiguration。 我听说,search引擎索引http://https://作为单独的条目,所以为了一致性(在SEO和页面行为),覆盖SSL的一切,只是设置301redirect似乎是一个很好的简单的解决scheme。
  • 一致性 – 如果您只是https://所有内容,您将拥有更一致的网站。 当你尝试做SSL和非SSL的混合时,许多框架会中断。 最重要的是,如果您尝试在httphttps之间来回跳动,那么依赖于URL的插件和代码将是真正的意思。
  • 这种模糊的安全感 – 你必须承认,左上angular那个说“validation域”的小绿条就是一种很好的感觉。

为什么不SSL一切

  • 速度 – SSL比较慢。 当然不是太多,而且大部分时间成本是微不足道的。 然而,这是一个不可避免的事实,SSL总是会变慢。
  • 浏览器兼容性 – 这可能是微不足道的,但是如果你想支持真正的旧的浏览器不通过SSLcaching,你将不得不坚持端口80。
  • 插件 – 一堆插件无法正确地通过SSL工作,所以你必须小心。 如果你想添加一个新的插件,你将不得不重新configuration你的SSL设置或寻找另一个插件。
  • 专业 – 现在尽pipe有人认为看到一个经过validation的SSL域名似乎值得信赖,但其他人认为这是一个非常业余和懒惰的解决scheme。 事实上,真正简单,便宜(花费我大约10美元)才能获得一个可以达到96%浏览器的SSL证书!
  • 麻烦 – 所以我确实说过,所有的SSL都是比较容易的,但同时你必须确保每个资源都通过https:// (或者http:// -> // quick solution )。 如果您有一堆链接,甚至不兼容,如果您有用户提交的内容托pipe在不支持SSL的网站上,则可能会有些乏味。 在这种情况下,你的浏览器会发牢骚。 如果你曾经看到过“这个页面有不安全的内容”的通知,你会知道这是多么令人讨厌,看起来有多糟糕。

所以简而言之,这是真的情况,但我倾向于避免覆盖SSL。 当然,它需要更多的configuration,但最终你会得到一个更灵活的系统。 我个人认为整个“专业”是垃圾(Twitter和Google SSL的一切)。 但是,如果您拥有外部托pipe的内容或用户发布的内容,那么SSL一切都是非常糟糕的主意。 你也可能开始SSL的一切,并遇到一堆麻烦。

但那只是我。 :d

首先要问自己,SSL买你什么? 它向您保证,没有人和应用程序可以“嗅”stream量,看看networking服务器和浏览器之间会发生什么。 成本是购买SSL证书的实际成本,以及下载速度稍微增加的持续成本。 您提到旧版浏览器无法通过SSL通信下载文件。 我不能说这个,我也不会太在乎这个。 从安全的angular度来看,你还有一个担忧。 现代防火墙监视stream量,寻找各种黑客攻击。 SSL防止防火墙监视该通信,所以应用程序开发人员/networkingpipe理员需要更关心保护他们的应用程序和网站免受各种黑客攻击。 长话短说,只应该encryption真正需要它的通信。

在对托马斯回答的另一个回应,特别是因为它是最重要的。

另外,我还将一篇白皮书与SSL的最佳实践联系起来。

SSL防止caching,不仅从浏览器,而且从代理服务器。 每个网页元素都必须由主服务器一次又一次地发送。 这增加了networking负载。

只有部分真实。 SSL将阻止代理caching,但不会浏览器caching – 也看到这个问题的答案。 在我看来,这不是一个大问题。

SSL防止使用所谓的“虚拟域”。 […]

这是部分正确的。 但是,只要您只有一个证书,虚拟域就可以正常工作。 即使你没有, 服务器名称指示(SNI)应该是一个可行的select(或者应该是,一旦Windows XP离开了这个星球的表面)。

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

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

换句话说:设置SSL连接将比渲染从数据库获取数据的PHP页面便宜一个数量级。

总的来说,把SSL放在每个地方看起来都是一种在安全方面获得“温暖的模糊感觉”的方法。 >这不好。 这通常意味着通过专注于无关紧要,

不是真的在所有 。 或者您的网站上完全不需要SSL,因为它完全是公开内容。 或者你出于某种原因需要使用SSL(用户login,保护区域)。 在这种情况下,最好的做法是把它放在任何地方。

仅在页面的某些部分使用SSL可能会导致各种模糊的风险。 尽pipe您可以通过其他方式查找和缓解这些问题,但是与仅在所有页面上启用SSL相比,它们会更复杂,更容易出错,更省时。

我发现了这个关于 SSL的白皮书 。 我与创作该公司的公司没有任何关系,但是我发现这是对部署SSL设置时需要牢记的所有事情的简要总结。

这个安全有多个组件不言而喻。 但是,第一个错误已经不是一个好的开始。

我不认为你应该SSL所有的网站,并且绝对不需要为你的开发环境购买证书。 如果你想/需要一个用于开发的SSL证书,它可以很容易地生成,并在大多数情况下,足够的环境。 另一种可能是你可以购买通配符证书,并将服务器设置在其中一个子域中,这样你就可以在两个环境中拥有相同的证书,但是如果你购买了通配符证书(更多昂贵),只是为了让开发工作。 如果您在产品上有多个需要SSL的子域,这是有道理的。

至于速度:是的,这是一个问题,但不是那么重要。 SSL响应没有caching,所以使用它们会增加你的服务器的负载,但我认为这是pipe理员应该知道的部分。