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

Question

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

Jas*_*son 41 encryption ssl https webserver server-administration

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

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

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

Answer 1

S.L*_*ott 25

回答托马斯的回答:

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

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

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

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

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

据我所知,大多数浏览器不会缓存SSL的页面,因此页面请求将需要更长时间

再说一遍,你测量过这个吗？

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

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

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

Answer 2

poo*_*lie 20

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

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

企业政策"一切都通过SSL,没有特定的豁免"是合理的.

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

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

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

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

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

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

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

安全地区分需要通过SSL的页面和那些不需要开发人员努力的页面,几乎可以肯定地使用它们.

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

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

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

谷歌的Adam Langley在2010年写道:

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

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

进一步的证据：Youtube.com 现在通过 https 提供服务。如果他们可以在如此庞大的数据量和可能相对较低的收入/字节的情况下做到这一点，那么您也可以。 (3认同)
是的，但即使这样也不安全。中间人仍然可以通过修改下载的可执行文件以插入病毒或恶意软件、将用户重定向到网络钓鱼站点，甚至修改以他们认为所在的域名发送给用户的 Web 内容来攻击用户。一旦您通过未加密的连接提供任何服务，您就会将站点访问者暴露在不必要的安全风险中。即使用户最初请求 HTTP 站点，即使它重定向到 HTTPS，实际上也是危险的，因为会话 cookie 可以被我的 MITM 捕获。 (2认同)
这就是为什么你让像谷歌这样的实体真正理解安全的重要性[在所有地方提倡SSL](http://online.wsj.com/article/BT-CO-20140414-709948.html).用户应安装[HTTPS Everywhere](https://www.eff.org/https-everywhere)以确保他们不公开会话cookie,允许[SSL剥离](http://www.thoughtcrime.org/software/ sslstrip /),或者甚至在可能的情况下尝试HTTP连接允许其他攻击. (2认同)
很棒的补充。HSTS 将防止 SSL 剥离。但是，它应该与 HTTPS Everywhere 之类的东西结合使用，因为即使使用 HSTS，第一个请求仍然可以通过 HTTP 发出。使用 HTTPS Everywhere，它可以防止大部分此类情况。它们真的应该一起使用，特别是因为大多数站点仍然不发送 STS 标头。 (2认同)

Answer 3

Tho*_*nin 8

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

SSL使所谓的"虚拟域"的使用变得复杂.传统上,为了形成SSL连接,浏览器和服务器需要使用相同的域名.这使得无法在单个IP上托管多个SSL证书,因为服务器将使用错误的证书进行响应.的实现的服务器名称指示(延伸到SSL使用TLS协议)已经修正了许多与此问题.

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

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

这真的不应该被标记为"正确"的答案.这是非常误导,甚至是错误的.事实是,对于用户而言,有许多可能的MITM攻击向量,如果没有在任何地方使用SSL,公司可能永远不会发现这些攻击向量.无论您使用何种类型的网站,SSL都是一项廉价且必要的要求.它不仅仅适用于"温暖的模糊".我厌倦了开发人员对安全性几乎没有理解或对此采取如此宽松和不负责任的态度. (9认同)
WRT SSL阻止缓存,这只是一些事实:http://stackoverflow.com/questions/174348/will-web-browsers-cache-content-over-https (5认同)
这是非常正确的.很好的答案,但略有不清楚.现代浏览器通过HTTPS缓存所有内容,除非明确告知不这样做. (5认同)
这是错的.SSL虚拟主机可以很好地与虚拟域配合使用:http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI和http://www.techrepublic.com/blog/opensource/configure-apache-to-support-multiple-ssl-网站上,一单IP地址/ 987 (2认同)
很多人都抱怨这个答案的准确性.如果你看到这样的错误,***就修好了***.这是SE的重点. (2认同)

Answer 4

Kev*_*ang 8

所以我已经看到了这个问题的一些很棒的答案,但几天后我发现有一些东西丢失了.因此,我想提一下几件事:

为什么在一切上使用SSL

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

为什么不SSL一切

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

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

但那只是我.:d

如果您担心传输速度,请使用SPDY,一切都将在SSL下,并且可能比HTTP更快. (4认同)

归档时间：	15 年，7 月前
查看次数：	11493 次
最近记录：	10 年，10 月前