Stack Overflow团队是否不了解OWASP A9的威胁？他们是否不在乎花20美元购买证书来为用户提供保护自己的选择？通过切换到HTTPS，Google并未显着增加资源消耗。至少让人们有选择来保护自己。
默认情况下，Gmail切换为对所有内容使用HTTPS。以前，它是作为一种选项引入的，但是现在，我们所有的用户都使用HTTPS来始终保护其浏览器和Google之间的电子邮件安全。为此，我们不必部署其他机器，也无需部署特殊硬件。在我们的生产前端机器上，SSL / TLS占CPU负载的不到1％，每个连接少于10 KB的内存，不到网络开销的2％。
来源：VeriSign
#1 楼
我本打算发表此评论，但空间不足。对于@Kop和@Rook：
对于像Stack Overflow / Server Fault / Super User以及Stack Exchange网络这样规模的站点，您不能只拍一个将$ 20的凭证放到您的网络服务器上，每天收费。 SSL处理是一项网络开销大的操作，因此您可能会破坏网站的性能。即使它不像我曾经知道的那样占用大量CPU，您仍然需要在计划和实施中考虑CPU-因为这确实增加了开销，并且在您处理10MM每月可开始累加的唯一性时快。
要正确执行此操作，我们需要实现一个高可用性的SSL负载平衡器/代理，它可以处理入站SSL连接，而不会阻塞。至少可能需要处理Trilogy的四个部分的负载（我猜这里是因为出于明显的原因而没有运行数字），至少需要4-6个非常强大的服务器，每台大约6-8k ，加上Kyle和我的时间来设计，实施和测试解决方案。
在大型网站上运行SSL并不是便宜的$ 20证书，而且您不只是将SSL证书拍到您的Web服务器上并每天调用它。对于我们收到的流量而言，它昂贵得多，并且需要在不降低站点性能的情况下正确运行SSL。
编辑：澄清一下，购买证书不是问题
评论
应该注意的是，您是SE的sysadmin之一。 blog.stackoverflow.com/2010/09/…
– jjnguy
10-11-1在23:28
扮演恶魔的拥护者：SSL不再那么昂贵。
–杰夫·阿特伍德
2010年11月2日，0：18
也许您误解了我的评论，但我只是想使用https的可能性，而不是对任何用户来说在每个页面上都是自动的。
–托马斯·博尼尼（Thomas Bonini）
2010年11月2日，11：16
@Kop不，我了解您，但是您必须认识到使用SSL的可能性与强制使用SSL的工程相同，如果您发现大量用户选择使用SSL，则需要解决后一个问题。
–Zypher
2010年11月2日，11：45
我想知道是否可以为信誉超过1000的用户启用HTTPS？这将解决大量用户的问题，并成为使用该网站的诱因。这就像为具有较高代表的用户关闭广告一样。
– Nevan King
2010年11月3日，21：07
@nevan，除了首先要协商SSL连接外，因此我们仍然必须设计大量的SSL流量，然后重定向10k以下的流量
–Zypher
2010年11月3日，21：18
@Jeff的确如此，只要问Google他们何时在gmail中为所有人实现https ...而无需添加新硬件等，总性能就会下降1％！
–alexanderpas
2010-12-10在1:38
@alexanderpas，请重新阅读我的文章，其中大部分与CPU开销无关，大部分与遵循7P有关。我不确定我还能强调的是，您不只是将证书扔到一个非常繁忙的服务器上，然后说：“很酷，所有工作都让我赚了钱。”证书的费用在这里绝对不是问题。
–Zypher
2010-12-10在2:17
@Zypher，是的，但与硬件/软件的每次更改和/或新功能所带来的成本无关。添加SSL应该像添加任何其他功能一样进行处理-同样：多年前，随着添加SSL / TLS会话恢复，已经不再相信切换为使用纯SSL / TLS是一种负担。会话恢复允许特定的客户端和服务器执行一次高开销的公钥协商，而该协商仅来自@BlueRaja帖子中的链接。意味着用户使用该网站的次数越多，协商对服务器的影响就越小。
–alexanderpas
2010-12-12 6:40
那么，是什么在阻止您选择较新的低容量站点之一（也许是security.stackexchange）并收集一些性能数据？您似乎认为这是一个巨大的问题，但是如果您确实可以提供证明，那么您将更有说服力。
– Zoredache
2011年1月3日，22：16
顺便说一句，购买20美元的证书可以完全解决我的问题，因为我可以在任何地方使用HTTPSE，而不会被黑客入侵。其他所有人仍然被搞砸。
–浏览
2011年1月8日18:15
当然，这不像购买20美元的证书那么简单。但是，要运行像SO这样的网站，毫无疑问，您必须解决很多难题。为什么HTTPS被证明对您如此阻碍？
–intgr
2011年3月30日12:17
再次值得注意的是，来自Google的信息：“在我们的生产前端计算机上，SSL / TLS占CPU负载的不到1％，每个连接的内存不足10KB，而网络开销则不到2％。”因此，增加的网络使用量也微不足道。
–布伦丹·朗（Brendan Long）
2012年11月9日在22:45
如果您2％的努力不值得花在安全性上，那么您就应该被黑客入侵。这太恶心了。
–浏览
13年2月18日在18:11
这篇文章使SO看起来很糟糕，也许它需要更新。
–浏览
13年4月14日在21:14
#2 楼
我们将在本周购买该网络的证书（开发人员已经到位），但是在转向SSL方面还有很多工作要做。如果您对这些细节感到好奇，可以阅读我在此处写的一篇最近的博客文章。这项任务不容易，但是我们正在努力使SSL可用，然后使默认。我将继续在博客中介绍SSL实现（例如，websockets可能很有趣）。
如果有当前问题，我很乐意回答。关于这一点：我们为什么不做任何事情？好吧，我们现在...我们为什么不呢？因为它很复杂，而且在现在甚至不可能。第三方内容（广告，MathJax等）必须予以支持，直到最近才出现。
更新＃1 2013年6月20日：当我们看到如何在生产环境中安全地进行迁移时，迁移到SSL配置的工作就更多了。我们将在下周初测试内部/虚拟负载平衡器，然后准备将证书部署到生产中。站点代码将花费更长的时间（将
https://设置为默认值，301，规范等），但这将使SSL尽快可用。注意：在预期的设置中，websocket几乎完全未知，您可能会看到实时的间歇性连接，因为我们了解了设置所涉及的有趣时间以及SSL套接字将如何最好地发挥作用。
更新＃2 2017年5月22日：我们已经推出跨网络的HTTPS。接下来是聊天强制
https://（即使内容混合），然后是secure仅cookie。希望这两件事很快就会发生。评论
@Nick，对此有任何更新...刚才，在使用Ask Ubuntu时，我注意到它在Firefox 26（Win 7）上默认为https：//，但在IE 11（Win 7）上默认为http：//。 ）...我没有使用任何强制执行https ..的插件。
– Aditya
2014年1月20日，11：20
@Aditya我们仅将https：//用作登录表单，如果您获得https：//链接，则可以使用一个插件。
–尼克·克拉弗♦
2014年1月20日下午13:44
@NickCraver：我没有使用任何强制使用https：//的插件，在打开浏览器时，该会话会自动为我默认为https。.我已重新启动浏览器，并恢复了正常状态-默认情况下仅使用http：// ...我不知道那时候发生了什么:-)
– Aditya
2014年1月20日下午13:51
截至2014年2月，状态如何？
–bmike
2014年2月11日下午16:04
@NickCraver：是2016年，法国用户仍会担心如果他们的帐户被劫持并在特殊情况下用于发布非法材料，将被判入狱数年。即使他们没有事先的司法判决。
–user2284570
16年7月17日在22:39
听起来需要更新。
–ɥʇǝS
17年3月18日在23:20
#3 楼
这是我为获取堆栈溢出Cookie所做的设置。请注意，我什至不知道如何编写“ leet”，而我只是通过查看Firesheep中的其他设置，并在Stack Overflow上询问有关如何遍历页面HTML来获取用户名来做到这一点的。如果我在家中创建开放的Wi-Fi网络，请在一台计算机上注销Stack Overflow（运行Firesheep），然后查看另一台计算机（已登录）上的Stack Overflow页面，无需登录即可访问。我认为对于Stack Overflow来说并没有什么大不了的。您能做的最坏的事情是冒充用户并给其他人起名字。甚至删除也可以回滚。对于Gmail来说，这更为严重。也就是说，我希望能够查看哪些IP地址访问了我的帐户。
使用此插件，我注意到很难在没有Wi-Fi的情况下在开放的Wi-Fi上使用Google搜索公开您的Google Cookie。即使访问https://google.com，也会将您重定向到不安全的网站。更糟糕的是，Google似乎会向您发送通知，从而暴露您的Gmail帐户（即使您没有访问gmail，即使您在Gmail中设置了“始终使用https”也是如此）。如果您想安全地进行搜索，则可以在任何地方使用HTTPS，但是我发现它存在很多问题。
我希望您不要以为我不负责发布此信息。别忘了，任何人都可以这样做。看一下代码有多简单。我花了很少的时间来创建，也花了很少的知识（从另一个设置复制模板，在Firefox中查看cookie名称，获得一些JavaScript帮助）。在看到有关Meta Stack Overflow的问题并在Stack Overflow的Firesheep标记下找不到任何内容之后，我实际上开始考虑这个问题。
register({
name: 'Stack Overflow',
url: 'http://stackoverflow.com/',
domains: [ 'stackoverflow.com' ],
sessionCookieNames: [ 'usr', '__utmz', '__utma' , '__qca' ],
identifyUser: function () {
var resp = this.httpGet(this.siteUrl);
this.userName = resp.body.querySelectorAll('a')[3].textContent;
}
});
评论
+1了不起的工作，希望这能说服开发人员对他们的设计负责。
–浏览
2010年11月3日，21：50
“我希望能够看到哪些IP访问了我的帐户。”这已经在您的用户页面上显示了两年了-在您的用户页面上搜索“上次活动：”一词
–杰夫·阿特伍德
2010-11-3 22:10
我希望有一个IP列表，更像是gmail显示访问邮箱的最近10个IP的方式。仅显示1个IP，您必须始终记住对其进行检查。
–nevan king
2010-11-3 22:36
@Jeff Atwood，但是如果您使用的是无线网络，则您将拥有相同的IP，并且不会有攻击迹象。
–浏览
2010年11月4日，0：28
@Rook我认为Stack Overflow对此无能为力。
–鲍玉红
2010年11月4日，7：30
@Yuhong Bao这是100％由开发人员引起的。 gmail于几年前解决了这个问题，github于上周修复，facebook很快就会效仿。
–浏览
2010-11-5 5:43
@Rook Um，您似乎解释错了...我很确定Yuhong Bao表示SO无法做任何事情向用户显示来自同一无线网络（具有相同IP）的哪些计算机已访问您的帐户。
–伊拉里（Ilari Kajaste）
2010-11-19在13:00
@Ilari Kajaste是您的权利，这就是为什么So至少应具有SSL选项。
–浏览
2010年11月19日在16:01
@Jeff：我从上一次活动中看到的一切显而易见，是我43秒钟前的活动。那以前的IP地址列表呢？也许是最后5个。我在家和工作中都使用SOFU。因此，除了那些IP地址之外，其他任何东西都将引起关注。
– IAbstract
2010-12-10 12:59
crypto.google.com的防火墙不会使您只能通过gmail访问https。选择对感兴趣的SO或metaSO用户进行的试运行不会受到伤害。
– abel
2011年1月7日在20:36
#4 楼
如果您有一个“中间人”，那么就会有更深层次的问题，例如您正在使用一个受感染的网络。您的旧Cookie可能无效。前提是他们停止了收听，并且您继续使用该网站。此外，我们认为，与您的网上银行帐户相比，有人窃取您的Stack Overflow帐户的风险不是很危险，或您的Gmail。 （记住电子邮件是我所知道的所有在线登录的事实上的基本密钥。）
评论
在我同意的同时，我也同意OP关于20美元的观点。拥有有效证书怎么会伤害任何人？它将使偏执的人们感到高兴。 =）
–托马斯·博尼尼（Thomas Bonini）
2010年11月1日23:05
@rook为什么不将您的愤慨引导到网络上也有此“问题”的其他99.99％？
–杰夫·阿特伍德
2010年11月1日23:55
@Jeff Atwood“但是网络上有很多SQL注入，为什么要打补丁我的应用程序？”
–浏览
2010年11月2日，0：26
@rook不一样的东西；您在抱怨网络的工作方式，而不是我们的代码编写方式
–杰夫·阿特伍德
2010年11月2日，下午1:23
@Jeff Atwood麻烦的是，此问题不会影响您，它会影响您的每个用户。这种对他人安全的老茧态度对我来说是那么令人反感。向那些想在各处使用诸如https之类的工具以保护自己的人提供https是微不足道的，但是您的回答对被黑客入侵的人来说是标志性的：“为什么有人会入侵我？”。
–浏览
2010年11月2日，下午1:36
@rook，因此请使用https代理-您已经可以执行此操作。 stackexchange.com/search?q=https+secure+proxy
–杰夫·阿特伍德
2010年11月2日，下午1:46
@Jeff Atwood我希望我可以对评论投反对票。
–浏览
2010年11月2日，1：50
“如果您有一个“中间人”，那么就会出现更深层次的问题，例如您正在使用一个受到威胁的网络。” -也就是说，如果您假设每个Internet骨干网以及它们之间的所有链接都是可信赖的且毫不妥协的。 ：） 只是在说'
– BlueRaja
2010-11-5 15:34
机场和星巴克是否算作被盗用的网络？严重的是，SO并不完全是我的银行。如果您可以破解我的SO帐户，那么您最糟糕的事情就是张贴垃圾，而这些垃圾将不得不清除。至于“网络运作的方式”，我认为像Twitter和Facebook这样的公司应该在这个部门中处于领先地位。因此，SO在这里致力于解决他们的技术问题。一旦网络以不同的方式工作，SO就会效仿。
–user27414
2010年11月8日在16:28
我对此表示同意。如果我的身份以明文形式传输，则站点的编码方式无关紧要。确保帐户被盗的影响相对较小，但这不是重点。坦率地说，SO可以轻松地对此进行打击，而在告诉人们游说网站运营商时不采取任何措施，这一事实实在令人困惑。
–NotMe
2010-11-15 17:09
@chris这是网络的基本体系结构问题，我们不是您的银行。了解更多：codinghorror.com/blog/2010/11/breaking-the-webs-cookie-jar.html
–杰夫·阿特伍德
2010-11-15 20:27
@Jeff：我读了博客，这就是促使我来到这里的原因。你说的两件事浮现在脑海。第一：“我一定会在乎他们是否嗅出我的cookie并开始像我一样四处奔波！”其次，“向您喜欢的网站索取这不是不合理的事情。”
–NotMe
2010-11-15 20:35
@Jeff：“这里没有社交活动”嗯，什么？我认为这正是在这里做的事情，是在讨论，确实很社交。当然，我们在这里没有与其他身份建立联系，但是那又如何-我在这里所做的社交活动比在LinkedIn中要多得多。也许您对社交有不同的定义？
–伊拉里（Ilari Kajaste）
2010-11-19 12:51
@jeff我读了您的博客，为什么向您推荐：“游说您用于提供HTTPS浏览的网站。”，当这正是我正在做的事情时，您就把我击倒了。
–浏览
2010年11月19日在16:05
该线程有点像发现圣诞老人不是真实的。
– John Dubya
2012年3月22日17:50
#5 楼
就其价值而言，Jeff现在似乎相信“也许加密连接应该是所有网站的默认设置。”
我知道Jeff即将退出Stack Overflow在2012年3月发布，但是他的这篇文章可能表明，对HTTPS的完全支持还不是那么遥不可及。
评论
这是一个多毛的技术问题。不是6-8周的事情，最终可能会发生
–华夫饼
2012年2月24日在2:37
@ waffles，6-8周？！他只有5天！ :)
– Benjol
2012年2月24日在6:28
#6 楼
我可以提出一个折衷方案吗？我认为，不公开的信息应通过安全连接提供。其中可能包括：
主持人访问页面时，主持人只能访问该页面
当用户访问他/她自己的用户页面时
当用户登录时使用登录页面
这不会造成性能问题，因为访问这些页面的次数是有限的。这也与Google之类的大公司过去的做法是一致的：即使不是Gmail的默认https，用户帐户设置页面也通过安全连接提供。
让我补充说，我认为这些页面应该安全，因为它们包含有关用户的私人信息，因此SE应该确保这些页面上的信息仍然是私人信息。
评论
很好，但是我认为这意味着在首次访问HTTPS页面时需要显式登录吗？ （或者，更可能的是：也将登录页面设置为HTTPS，用一块石头杀死2个东西。）但是，这样做确实会阻止其他人将您锁定或添加其他OpenID。最重要的是：我非常喜欢保护主持人操作的想法。
– Arjan
2011-4-25 9:41
是的，但是我关心的是会话被劫持了。如果有人这样做，那么他们将在https中查看我的所有信息。
–浏览
2011-04-25 15:53
@Kaveh，您缺少OWASP A9和Firesheep的要点。您对SO所做的每个请求都有您的会话ID，如果您使用的是开放的wifi网络（我现在位于此处），则网络上的其他所有人都可以看到此会话ID。 Firesheep会嗅探网络并列出其找到的每个sessoin ID。您只需单击被劫持的会话，然后您就可以成为它们。整个会话期间都使用HTTPS是防止这种情况的唯一方法。
–浏览
2011-4-25 17:54
-1我看不到这如何提高安全性。
–浏览
2011-4-25 17:55
gmail也因为攻击（例如Firesheep）而使用https作为所有内容。
–浏览
2011-4-25 17:56
@Rook，正如我之前所说的，这是几个月前的GMail做法，而且他们改用完整的https是最近的事情，我不知道确切的原因，但我不认为像攻击一样发出鞭炮声是主要原因，我认为中东镇压政府的问题可能在他们的决定中占了更大的比例。
–卡韦
2011年4月26日在2:53
@Kaveh一切皆有或无。您要么阻止轻松丢弃样式攻击，要么屈服于它们。 Google的许多服务都选择使用https，因为政府在进行烈火风格的攻击。
–浏览
2011年4月26日在2:59
您建议的是违反owasp的行为。因此，我总是反对违规。
–浏览
2011年4月26日在3:11
@Rock，当然可以，那是你的投票！ :)顺便说一句，我不建议违反任何规定，如果每个页面都在https上显示，我个人比较喜欢。但是由于SE目前似乎还没有准备好这样做，所以我希望进行改进。我说的也是正确的，我的建议是对当前状况进行重大改进，并且是许多超大型站点（如亚马逊）的当前做法。
–卡韦
2011-4-26在3:15
@Rook，我非常确定Gmail的每个页面上都有隐私敏感信息：电子邮件！在SE上不是很多。甚至SE收件箱也显示公共信息。显然，该团队认为登录用户的流量不够小，不足以对每个登录请求使用HTTPS。然后，我同意Kaveh的观点，即可以通过对那些页面实施HTTPS（显然也需要安全的cookie）来保护有限的数据和操作集（被视为个人或危险的信息）。
– Arjan
2011年4月26日上午11:48
@Arjan @Kaveh哇，所以如果孩子可以劫持您的帐户，你们可以不在乎吗？真？我真的有这种转换吗？
–浏览
2011年4月26日在15:48
@Arjan我知道，每当您通过纯文本传输身份验证凭据时，都存在漏洞，协议无关紧要。 SSL / TLS最昂贵的部分是握手，所有其他请求都使用缓存的“主机密”，并且开销很小。它全有还是全无。
–浏览
2011年4月26日在16:39
@Kaveh这个名字叫“ rook”，就像我图标中的小鸟一样。 TLS / SSL最昂贵的部分是建立主密钥的握手。然后将这个主密钥缓存起来，并用于会话的整个生命周期。 Facebook现在是纯https，因为Mark Zuckerburg被Firesheep入侵了。当一家大公司这样做时，他们购买了只需要握手的设备。这确实要花钱，SO团队更喜欢金钱而不是安全。
–浏览
2011年4月26日在16:50
@Kaveh您所提议的唯一一件事就是浪费资源。更令人担忧的是您认为它会有所帮助。毫无疑问，您是一位受人尊敬且成就斐然的开发人员，不幸的是，这是非常令人信服的，并且不了解安全性。请阅读OWASP前10名。
–浏览
11年4月27日在8:20
@Arjan让我感到困惑，您认为这完全有帮助。您的房子周围是否有2英尺长的栅栏，人们会越过？
–浏览
2011年4月27日在8:23
#7 楼
我同意您应该使用TLS / SSL来解决此问题。同时，本阿迪达（Ben Adida）针对“ SessionLock Lite”的提案/代码提供了一种廉价的临时方法，看起来至少可以防止持久性被动攻击者的劫持。当然，它不提供任何防止窃听的保护。对于诸如firesheep之类的工具，也存在一小段令人担忧的漏洞窗口，您应该采用其他服务器端方法来缓解此漏洞。但这可以减少您设计SSL解决方案时的风险：http://benlog.com/articles/2010/10/25/keep-your-hands-off-my-session-cookies/
顺便说一句-当用户注销时，您至少实际上使服务器端的cookie失效了吗？
#8 楼
我的第一个猜测是广告将不支持HTTPS，因此进行混合会话，用户必须处理浏览器“是否要继续”对话框更多信息：Google Ads不支持HTTPS。有什么替代方法？
也许SO有不同的广告处理方式。
#9 楼
为什么Stack Overflow团队无法解决Firesheep样式的Cookie盗窃问题？因为即使是高代表用户也有速率限制，所以如果将帐户分成几个帐户，几乎不会造成任何损害完全消除溢出，并且造成的损坏很容易补救。
以后可能会更完整地解决某些问题，但是需要做出一致的努力才能拉出类似的东西关闭。例如，和几个朋友一起去CES，并设置他们的笔记本以嗅探cookie信息并将其报告给中央服务器。然后，该服务器确定它收集了哪些帐户，并设置了一个控制器，以便单个用户可以使用多个帐户即时关闭问题，发布问题并即时投票等。 ，StackOverflow已经具有针对滥用者的重要监视，速率限制和防火墙阻止功能，因此使用当前设置可能会阻止这种简单的设置（如上所述）。
最大的危险是如果有人从主持人那里获得Cookie，这时他们可能会造成一些无法轻易回滚的损害。
评论
主持人和Jeff不再需要CES之类的东西;-)
– Arjan
2011年2月2日在20:17
我仍然希望我关心安全性。
–房间
2011年4月26日在16:42
Boo回应说：“它只会对被入侵的用户造成损害，因此SE等人不会胡扯”。很高兴我的银行没有采取这种安全措施。
–劳伦斯·多尔（Lawrence Dol）
2013年1月19日在21:08
@AdamDavis：不同意……如果有人劫持了我的帐户cookie并发布了种族仇恨言论（并且如果堆栈交换不愿意提供证据证明我的帐户已被高封），并且警方在mods删除它之前发现了它，那么我担心会花费2年在监狱
–user2284570
16年7月17日在22:01
@ user2284570听起来像一个非常压迫的政权。我建议您注册的任何站点都不需要两到三个因素的身份验证，这会使您的生命面临极大的风险。考虑使用诸如tor之类的隐私网络，并且不要将您的个人ID附加到任何互联网站点。另外，我相信这种特殊的攻击是由https处理的，我相信您现在可以在堆栈交换中使用它。请记住，这个问题已有3年历史了。最后，由于社区的积极调节，仇恨言论很可能会被从站点中移除太快而无法进行调查。
– Pollyanna
16年7月18日在2:18
@AdamDavis：现实中，网站主持人没有撤回的绝大多数非法材料实际上并未将其作家带到警察局。但这有可能发生。而且以前没有任何人使用其他人的帐户发布此类材料的案例（因为甚至没有报告过此类案例）。问题是我必须证明，尽管这是我的帐户，但我不是邮件的作者。在stackexchange的任何地方都使用ʜᴛᴛᴘꜱ就足够了，但不能在移动设备上完成。
–user2284570
16 Jul 18'2:36
@亚当·戴维斯（AdamDavis）：更不用说被抓住的男人发疯了。
–user2284570
16年7月18日在8:05
#10 楼
有一些方法可以在不使用SSL的情况下防止cookie泄漏，这将增加很少的负载。创建会话后，请生成一个随机数（R）并将其与会话相关联。作为登录过程的一部分，将此数字传递回浏览器（因此它已被SSL覆盖，因此是秘密的）。
然后通过HTTP针对每个请求：
浏览器生成随机数Q。
浏览器计算S = SHA1（Q + R）
浏览器在请求中将Q和S以及会话cookie一起包含
服务器接收请求，验证SHA1 （Q + R）= S，如果是，则会话有效。
不难，每个请求标头增加大约40个字节，而增加的服务器负载可以忽略不计。破解此漏洞需要某种XSS漏洞，该漏洞会揭示R，破解SHA1或猜测随机数序列，但这些都不会很快。
评论
因此，防止使用SSL的方法是...使用SSL？我不明白
– Aarobot
2010年11月8日在16:38
因此，即使在登录过程中也不要使用SSL。他们依靠第三方OpenID提供程序来处理安全登录，因此您的解决方案仍会添加新的SSL。
–重
2010年11月8日在16:45
嗯，嗯，我没有太多使用StackOverflow。实际上。该解决方案只允许通过SSL进行原始登录，而通过HTTP进行其余登录，这比将整个站点迁移为使用SSL便宜得多。但是可以，它仍然需要通过SSL进行初始连接。
–user153246
2010年11月8日在16:47
-1表示您以纯文本格式传输了MAC中使用的机密，从而破坏了MAC的全部重点。此外，如果黑客可以修改用于生成页面的html和javascript，从而获得您的机密Q。不要构建安全系统，那么这个建议就令人震惊。
–浏览
10 Nov 17 '17：13
您需要ssl，并且不要让任何人告诉您。
–浏览
10 Nov 17 '17：14
但是，如何将密码R存储在浏览器中以供后续请求...？
– Arjan
2010-12-10 9:18
有趣的。尽管这不能完全抵御MITM攻击，因为攻击者可以传递SHA1（Q + R）的值，并对请求执行其他操作。
–nealmcb
2011年1月2日，1：17
@rook-Q仅在浏览器中，对于每个请求都是新鲜的，而不是通过网络发送的。 MITM攻击发送到浏览器的javascript是一个聪明的主意-我想知道浏览器是否有可能以某种方式依赖在最初的安全会话中发送的javascript，该javascript通过HTML5保存在本地存储中。但我同意-充其量是一个冒险，脆弱和脆弱的提议。有关更多讨论，请访问security.stackexchange.com/questions/1322/…
–nealmcb
2011年1月2日，下午1:39
@nealmcb消息摘要功能无法解决此问题。作为对密码学问题的最佳回答，我告诉您SSL是解决此问题的唯一方法，请不要告诉其他人。
–浏览
2011年1月2日在4:02
@rook是的-我们同意这绝对不能替代ssl，并且总体来说这是一个愚蠢的方向。我只是想知道带有html5的服务器是否可以防止MITM窃取可重用的会话标识符。考虑到MITM仍然可以解决的所有问题，那并不是对用户有很大帮助。而且我只是在澄清，这里的提议并未“以纯文本形式传输秘密”，即使如前所述，MITM也很有可能也可以将其从浏览器中撬出，除非html5具有允许优秀的javascript程序员使用的良好功能。防止这种情况。
–nealmcb
2011年1月2日，下午6:41
@nealmcb您的解决方案可以使攻击窗口更小。仍然存在加载html / js的问题。如果有办法对此内容进行签名，则此解决方案可能会有效。但是就目前而言，如果我的协议在任何步骤上都不安全，那将是无法使用的。
–浏览
2011年1月2日，18：45
@rook：是的-它需要一直都是安全的，我还没有证据表明它可以变得安全，而且到处都有龙……。普通的SSL肯定更有意义。感谢您帮助澄清这些内容。
–nealmcb
2011年1月4日，下午3:27
@ user153246：我知道很多人认为无法显示任何JavaScript的网站都是恶意软件。
–user2284570
16年7月17日在22:08
评论
对于SO / SF / SU大小的站点，它的价格超过20美元的证书很多@Zypher的真实故事，但我的抱怨是我什至不能在任何地方都使用https。
有人已经在尝试使用Firesheep劫持stackoverflow（并询问关于stackoverflow的问题）stackoverflow.com/questions/4089665/…
@扎克·约翰逊非常有趣。
@Zach我绝对不是要劫持堆栈溢出。使用此插件，您只能劫持一个人的帐户，并且只有在同一星巴克并使用WiFi时恰好有另一个Stack Overflow用户编码时才能使用。
这是一个合理的问题，但是夸张是不必要的。
@Craig Stuntz是的，确保您的用户不会被黑是轻描淡写的。这样的奢侈品只能通过twitter，github，gmail ...等来享受。
@Rook，我还没有意识到夸张是您的第一语言。抱歉！
相关历史事件：保护Cookie：HttpOnly（希望Jeff，主持人，甚至任何10k用户永远都不会被欺骗在某些会议上使用某些wifi登录到SO）。
@Arjan我们将在这里做两件事。首先，httponly cookie不会阻止攻击者嗅探您的HTTP流量并获取cookie。此外，仍然可以通过使用XHR来利用httponly cookie来以类似于CSRF的攻击方式“占用”会话。 HttpOnly cookie绝不是一个完整的解决方案。
（@Rook，我知道，但我指的是两年半之前被盗用的SOÜberAdmin帐户...）
@Arjan oooooooah，很不错。
@DanBeale-即使使用WPA，您仍然可以ARP欺骗，ICMP重定向欺骗或运行恶意DHCP服务器来诱骗用户自己进行路由。咖啡店通常也是开门的，使用“墙上的密码” WPA方法可以运行具有相同SSID的恶意AP ...
我想在StackExchange上看到HTTPS。如今，您可以获得2年的您可以签署的普遍信任的扩展验证证书，包括无限的备用名称和通配符，价格约为200美元。 TLS是一种资源密集型的事情，现在已经不正确了。
@aef我甚至接受信任SE根CA证书，但是正如Zypher所说，问题更多的是性能而不是证书。尽管我认为毕竟不应该那么麻烦。