关注网络安全
和行业未来

十一月SSL行业新闻回顾

Jesdoit阅读(114)评论(0)

本月大事件:Comodo易主引争议

不久之前,证书颁发机构中的龙头老大赛门铁克将其CA业务卖给了竞争对手DigiCert。如今,另一个CA巨头也易主了。Comodo的CA业务现为Francisco Partners所有。

毫无疑问,CA行业正在发生大变化。Let's Encrypt在崛起和获得巨大成功的同时,也给整个行业展现了一种新的商业模式。浏览器厂商提出的更严格的安全要求让传统CA行业老大的赛门铁克出局。当CA们易主和合并时,Mozilla发布了关于信任问题的声明

Comodo的新老板可能会引发另一个问题:Francisco Partners还拥有70%的NSO集团股份,该集团开发了政府间谍软件”飞马“。 这个间谍软件在2016年上过头条新闻,当时西铁城实验室透露,它在iOS中使用了几个零日漏洞攻击阿联酋的维权人士艾哈迈德•曼索(Ahmed Mansoor)。不过近期,Francisco Partner正尝试卖掉在NSO集团的股份

短新闻

 

稿源:Feisty Duck

iOS 10发布 安全更新机制使用HTTPS

Jesdoit阅读(141)评论(0)

随着iOS 10的发布,苹果终于将其iOS安全更新机制转移到了HTTPS!

在此之前,系统更新通过HTTP发送至设备,如果攻击者恰好处在同一网络中,用户极易收到干扰。

苹果公司表示:“iOS更新中曾存在一个问题,从而没有真正保护用户通信。现在这个问题通过使用HTTPS进行软件更新解决“,此外,中间人攻击者可能会阻止设备接收更新。

这个变化是iOS 10中修补的七个漏洞之一,这是移动操作系统的一个重大更新。 MacRumors表示,在更新的早期阶段,用户还报告了将设备置于恢复模式的安装问题。 苹果后来承认,更新过程中存在一个问题,并且少量的用户在修复之前受到了影响。

苹果在本地iOS Mail应用程序中修补了一个潜在的严重问题,在该应用程序中,网络上的攻击者可能会窃取电子邮件凭据。

“处理不受信任的证书的过程存在一个问题,”苹果解释道,”我们的做法是终止不可信的连接。”

苹果公司还在iOS 10的新消息框架中修补了一个隐私问题,苹果公司在iPhone和iPad上修补了一个未经登录的设备上读取消息的隐私问题。苹果公司表示,问题在于使用Handoff for Messages, 并通过优化状态管理解决了该问题。Handoff确保iOS设备之间的同步和连续性。

此外,这次更新还解决了恶意应用程序可以用来自定义短信发件人的漏洞。

苹果说:

“短信草稿目录中存在访问控制问题。 这个问题是通过阻止应用程序统计受影响的目录来解决的。”

苹果公司还修补了键盘缓存敏感信息的iOS键盘中的一处漏洞,并在自动更正的建议中显示。

GeoServices中的一个错误也被解决了,因为PlaceData中的权限问题,应用程序可能会读取位置信息。

苹果还为El Capitan 10.11.5及更高版本更新了Xcode,修复了otool工具中的一个漏洞,该漏洞允许本地攻击者崩溃应用程序或运行代码。 苹果表示,它修补了多个内存损坏漏洞。

最后,苹果改进了在WatchOS中的一个权限问题,该问题可能允许应用程序读取位置信息。

 

稿源:Threat post

 

【科普】实行和防止SSL剥离

Jesdoit阅读(169)评论(0)

上个月末,我们了解到了一个新的攻击,这个攻击展示了所有当代WiFi网络加密协议的一个严重弱点。KRACK攻击有效地允许在由WPA2协议保护的无线网络上拦截流量。尽管防止该攻击的方法可以简单地通过安装补丁解决,安全更新很少有及时安装的。

在此漏洞发生之前,并不存在易受拦截攻击的无线网络。一些无线网络继续使用过时的安全协议(称为WEP),这种协议显然是“完全不安全”的;其他无线网络(例如咖啡店和机场中的那些)仍然完全开放,并且不认证用户。一旦攻击者获得对网络的访问权限,他们就可以作为一个中间人(Man-in-the-Middle)来拦截网络上的连接(使用称为ARP缓存中毒和DNS劫持的策略)。是的,这些拦截策略可以很容易地部署在有线网络,并通过以太网端口访问。

毫无疑问,盲目信任连接用户和互联网的媒介是不安全的。HTTPS正式为了允许HTTP流量以加密形式传输而创建的。然而,KRACK攻击的作者通过视频展示了如何在某知名约会网站(使用HTTPS)上实行完全剥离的全过程。本文将介绍如何进行SSL剥离以及缓解这种情况的机制。

HTTP over TLS

互联网是建立在标准拼凑的基础上的,组件被重构和重建为新的公布标准。当一个标准被发现是有缺陷的,它后来被修补或被一个新的标准取代。当 一个标准被篡改,取而代之的是一个更好的标准,整个互联网变得更好。

HTTP协议最初被指定为通过互联网清楚地传输数据。在正式引入HTTP 1.0之前,HTTP的第一个记录版本被称为HTTP V0.9,并于1991年发布。Netscape首先认识到需要通过互联网提供更高的安全保证,并在1994年中期在其浏览器中首度使用了HTTPS。为了实现更大的安全保证,创建了一种名为SSL(安全套接字层)的技术。

由于一些安全问题和缺陷,SSL 1.0比较短命,并没有被标准化。该协议在SSL 2.0和SSL 3.0中逐步更新;然后由TLS(传输层安全)标准取代。

每个版本都有不同的安全限制,支持因浏览器而异。另外,所使用的加密密码可以在一定程度上独立于上面的协议来配置。因此,确保启用HTTPS的Web服务器设置为使用优化的配置来平衡浏览器支持与安全性至关重要。

从更高层次解读,使用TLS的HTTP的最终结果是:当通过https://而不是http://请求站点时,连接以加密方式完成。这一过程提供了对隐私和完整度的合理保证。换句话说,我们不止加密了发出的信息,还确保了收到的信息不被更改。建立安全连接后,网络浏览器可以通过点亮浏览器栏来向用户显示此信息。

由于SSL证书本身由CA签署,因此需要进行一定程度的域名验证。CA确保他们只给能合法修改网站的网站拥有者颁发证书。如此,证书就不会发给攻击者。如果证书的签发出错,就需要根据证书撤销列表来撤回。这样的列表由操作系统自动下载,以确保当无效证书被提供时,它在浏览器中被标记为不安全。能颁发证书的机构超过一百家,因此可以通过配置CAA DNS记录来将哪些证书颁发机构颁发给给定域的证书。

在使用HTTPS时,重要的是通过HTTPS加载网站的全部内容,而不仅仅是登录页面。过去,网站通常通过安全的加密连接来呈现登录页面,然后当用户登录时,它们会将连接降级回HTTP。一旦登录到网站,会话cookie就存储在本地浏览器上,以允许网站确保用户登录。

2010年,Eric Butler通过构建一个名为FireSheep的简单拦截工具来演示这种不安全性。通过窃听无线连接,FireSheep展现了捕获常见网站的登录会话的过程。虽然攻击者不一定能够捕获网站的密码,但他们将能够捕获登录会话并在网站上执行行为,就像登录一样。他们也可以在用户登录时拦截流量。

当使用SSL连接到网站时,第一个请求通常应该将用户重定向到网站的安全版本。例如:当你访问sslchina.com时,HTTP将重定向至HTTPS版本https://www.sslchina.com/

那么问题来了,如果有人能够截获对该网站HTTP版本的未加密请求,是不是就意味着他们可以剥离加密并响应未加密的网站给用户了?这是一个由Moxie Marlinspike提出的问题,而后HSTS被创建。

HTTP严格传输安全(HSTS)

在2009年的Blackhat DC上,Moxie Marlinspike提出了一个名为SSLStrip的工具。这个工具会拦截HTTP流量,当它发现重定向或使用HTTPS的站点链接时,它会透明地将它们剥离。受害者并不直接与网站相连,而是连接到攻击者发来的连接。这也就是大众熟知的中间人攻击。

SSLStrip的神奇之处在于,只要在未加密的HTTP连接上找到指向HTTPS网页的链接,它就会用HTTP代替HTTPS,并且坐在中间拦截连接。拦截器将使加密的连接以HTTPS方式返回到Web服务器,并将流量返回给未加密的站点访问者(在流程中记录任何有趣的密码或信用卡信息)。

作为响应,一个名为HTTP严格传输安全(HSTS)的协议在2012年创建,并在RFC 6797中进行了规定。协议的工作原理是服务器响应一个名为Strict-Transport-Security的特殊标头,该标头包含一个响应,确保用户在重定向连接到网站时必须使用HTTPS。这个响应包含一个“max-age”字段,它定义了这个规则自从上次被看到以后应该持续多长时间。

虽然HSTS为防止拦截攻击提供了改进,但并不完美,并且还存在一些缺点。

HSTS预加载

HSTS的一个缺点是,它需要之前的一个链接才能知道到底连到哪个站点是正确的。当用户第一次链接到站点是,他们不会收到HSTS规则提醒他们只使用HTTPS。只有在后续连接中,访问者的浏览器才会知道需要通过HTTPS连接的HSTS规则

攻击HSTS的其他机制已经被探索;例如劫持用于同步计算机的时间(NTP)的协议,将来可以将计算机的日期和时间设置为1。这个日期和时间可以被设置为当HSTS规则已经过期并由此绕过HSTS时的值。

HSTS预加载列表是帮助解决这些问题的一个可能的解决方案,它们通过硬编码需要使用HTTPS链接的网站列表来有效地工作。已启用HSTS的网站可以在hstspreload.org上提交到Chrome HSTS预载列表;这也被用作其他浏览器中使用的预加载列表的基础。

在Google Chrome的源代码中,有一个文件,其中包含的一个硬编码的文件列出了预加载列表中所有域的HSTS属性。每个条目都以JSON格式化,如下所示:

api.cloudflare.com in Chrome HSTS list

即使有预加载,事情还并不完美。 假设某人正在阅读关于书籍的博客,并且在该博客上的链接到在线零售商那里购买一本书。 尽管在线零售商使用HSTS强制执行HTTPS,但用户依旧有几率遭遇中间人攻击,因为提供链接到在线零售商的博客不使用HTTPS。

长路漫漫

Leonardo Nve在一个名为SSLStrip +的新版本中恢复了SSLStrip,能够避免HSTS。当站点通过未加密的HTTP链接连接时,SSLStrip +将查找指向HTTPS站点的链接。一旦找到HTTPS站点的链接,会将其重写为HTTP,并严格地将该域重写为不在HSTS预加载列表中的仿真域。

例如;假设某个网站包含https://example.com/的链接,则可以通过将网址重写为http://example.org/来删除HSTS;攻击者坐在中间,接收来自http://example.org/的流量,并将其代理到https://example.com/

这种攻击也可以针对重定向进行。假设http://example.net/通过HTTP加载,然后重定向到通过HTTPS加载的https://example.com/。在进行重定向时,合法的受HSTS保护的站点可以被重定向到攻击者用来通过HTTP提供流量并拦截流量的虚假域。

随着越来越多的互联网转移到HTTPS,这种攻击的发生率将变小,因为极少的未加密HTTP流量会被拦截。

在最新发布的谷歌浏览器版本中(62),使用不安全链接表单的站点都被标记为“不安全”。当处于隐身模式(隐私浏览)模式时,Chrome浏览器会将任何不使用HTTPS的网站标记为不安全。

这一做法帮助用户在尝试登陆时更有效地识别网站是否使用HTTPS,同时促使更多网站采用HTTPS以提高整个互联网的安全性。

总结

本文讨论了从网站上剥离HTTPS的机制,特别是HSTS如何影响这个机制。值得注意的是,在各种HTTPS规范和某些密码中还有其他潜在的攻击载体是本文没有涉及的。

尽管HTTPS提供了一种加密Web流量的机制,但重要的是要实施诸如HTTP严格传输安全性之类的技术,确保强制执行,并且最好将你的站点提交给HSTS预加载列表。随着越来越多的网站这样做,整体互联网的安全性将得到提高。

要了解如何在实践中实现HTTPS和HSTS,强烈建议Troy Hunt的博客文章:HTTPS的六步“快乐之路”。他的博客文章介绍了如何在实践中启用强大的HTTPS,另外还介绍了一种本文没有提到的被称为CSP(内容安全策略)的技术。 CSP允许你在通过HTTPS加载页面时自动升级或阻止HTTP请求,因为这会构成另一个攻击媒介。

稿源:Cloudflare

本文原文由Junade Ali于2017年10月20日发布在Cloudflare博客,SSLChina作翻译并进行适量删改。

九月SSL行业新闻回顾

Jesdoit阅读(253)评论(0)

本月大事件: CAA成强制

新的DNS记录类型应该提高证书颁发的安全性。证书颁发机构授权CAA在2013年时便记录在RFC 6844中,却直到近期才成为强制性举措。CA/B论坛决定,从9月8日起将CAA检查升级为强制性。CAA允许域所有者在DNS记录中定义哪些证书颁发机构可以为其颁发证书。

规则生效没多久,不少人验证了各大CA是否正确检查CAA,然后经过多方证明,作为CAA发明者的Comodo随即被爆出没有CAA检查记录。在事件报告中Comodo承认的该问题并解释说是因为dig命令的交互中出了错。不少其他CA也相继被爆不会用CAA,尤其是在包含DNSSEC的情况下。

Andrew Ayer创建了一个CAA测试套件。他同时还为SSLMate公司操作一个CAA记录生成器。

短新闻

 

稿源: the feisty duck

HPKP已死续篇:如何通过撤销Pin来修复HPKP

Jesdoit阅读(205)评论(0)

本文由  于2017年9月5日发布在ssllab博客。

差不多就在去年的今天,我宣布HPKP实际上已经死亡。我当时——现在仍然——相信,HPKP太复杂,太危险,不值得付出努力。最大的问题就在于没有足够的安全收益;绑定失败总是灾难性的。这一直困扰着我,我想知道是否有可能在不从头开始的情况下修复HPKP。这就是这篇博客想要讨论的内容。

今天,我将会探索用撤销pin来修复HPKP的可能性,这将在紧急情况下使用。请注意,尽管我将会从技术角度来尝试拯救HPKP,但这并不必然表明我认为HPKP是值得拯救的。PKI的情况发生了变化,现在我们有了证书透明(CT),它解决了HPKP本来想要解决的一系列问题,我们还有了证书颁发机构认证(CAA),它解决了另一些问题。有人可能会说,考虑到HPKP的复杂性,在CT和CAA之间可能没有足够的空间留给HPKP去发挥作用。我将会另找时间讨论这个问题。现在,让我们试着让HPKP变得更容易让人接受。

假设与约束

一个基础性的假设是,任何不能从操作人员的错误中恢复的技术注定会失败。在HPKP的案例中,一次绑定的失败可能意味着业务上的全面失败,那么为什么还有人想要使用这种脆弱的技术呢?或许我们仍然可以拯救HPKP,如果我们能够通过某种安全机制来对其进行扩展,那么它可以消除或显著降低业务风险。

然而,我不认为这是我们唯一需要做的事情。撤销Pin不是没有代价的。根据设计的不同,这样做可能会进一步增加HPKP的复杂性。例如,一个设计方法可能是引入一个特殊的撤销密钥,但是这仅仅意味着你又有了一个可能会丢失的东西。

然后,还有一个问题是,怎样让浏览器厂商相信,HPKP是值得修复的,不应该把它抛弃掉。浏览器厂商不会喜欢任何需要添加大量新代码却无法带来明显好处的解决方案。

最后,任何需要对服务器端进行任何修改的建议或者对TLS协议的修改都会被立刻拒绝。不太可能有足够多的人有兴趣投入足够的时间来研究这种方法对HPKP进行修复。

我们能找到满足这些标准的方法吗?

用OCSP来进行Pin撤销

也许我们可以但不必看得太远。在PKI中,我们已经有了OCSP,这是一种被设计用来实时检查证书状态的撤销检查机制。尽管OCSP实际上已经不再被用于它本来的目的了,但也许我们可以用它来为HPKP的pin撤销做准备呢?我的建议很简单:我们不用将pin视为独立的个体,而是将每个pin的生命周期与用于访问web站点的叶子证书的生命周期连接起来。让我们把这个公钥绑定变量称为HPKPbis。

在正常情况下,HPKPbis的外观和给人的感觉与HPKP相同。如果你的操作步骤没有问题,那么一切都会是一样的。只有当需要解决一个巨大的麻烦时,Pin撤销才会生效,而你的web站点将会在很长一段时间内无法使用。想要恢复的话,您只需要撤销证书就行了。相应地,撤销你的pin,你的用户就可以继续访问了,在大多数情况下,他们都不知道存在任何问题。

HPKPbis执行细节

在这一节中,我将尝试更详细地说明HPKPbis到底是如何工作的。就像PKI里的其他东西一样,魔鬼也在细节中。要理解这一节,你需要熟悉RFC 7469中规定的HPKP。

与RFC的区别如下:

  • 当第一次在没有错误的连接上观察到pin的时候,它们就会被激活。用户代理必须存储已观察到的pin以及足够的信息,以便将来验证整个证书链。对于激活pin的另一个要求是,叶子证书要包含OCSP的撤销信息。
  • 一旦对某个主机名启用了绑定,在随后的访问中至少有一个完全或部分激活的pin必须与所显示的证书链相匹配。
  • 有两种类型的pin激活。完全激活是在无错误连接上观察到匹配的证书(公钥)的时候发生的。部分激活是在一个pin被观察到(即,它被包含在一个HTTP相应头之中发送),但在证书中还未看到的时候发生的。这两种类型的pin都是有效的,但是它们有不同的安全属性。
  • 如果一个部分激活的pin与一个无错误连接的证书相匹配时,这个pin就会被升级到完全激活状态。当升级发生时,与较早的证书链之间的连接将会被删除。
  • Pin的生命周期与在激活时出现的证书链的生命周期是不可分割的。因为我们绑定的是公钥而不是证书,所以一个pin可能与不止一个证书链连接在一起。如果一个pin所连接的所有的证书链都过期了,那么它就会被认为过期了。类似地,如果一个pin所连接的所有证书链都被撤销,那么它就会被认为是被撤销了。与标准HPKP一样,一个pin的最大生命周期也受到已公布政策的持续时间的限制。
  • 在正常的操作过程中,不会检查pin是否被撤销。但是,如果尝试访问一个已绑定的站点,并且返回的证书链不匹配,那么用户代理将尝试破坏已知的pin。对所有已存储的绑定信息进行循环访问;当发现一个证书链将会过期或被撤销时,所有对应的pin(包括完全激活和部分激活的)都被认为是无效的。在这个过程的最后,如果没有有效的pin留存,那么用户代理将前进到web站点。
  • 叶子证书的撤销检查是通过OCSP进行的。在此过程中,用户代理不能容忍OCSP应答器的失败。对于一个给定的证书,如果无法获得其撤销信息,那么用户代理必须假定该证书仍然有效。
  • 如果信息可用,则可以通过OCSP检查中间证书。或者,我们可以假设使用现有的供应商专卖机制可以撤消中间证书。
  • 部分激活的pin用于支持备份证书链的部署,例如在对主密钥失去控制的时候。高级操作人员可以选择将部分激活的pin升级到完全激活状态,这可以通过有规律地轮转他们的证书链来实现。

部署场景

让我们考虑一下如何在实践中使用HPKPbis:

  • 与HPKP的情况一样,站点应该使用来自不同证书颁发机构的证书链中的两个或多个公钥进行绑定。这种方法可以避免中心点故障问题。
  • 与HPKP的情况一样,一个丢掉了pin(证书)的控制权的操作人员可以使用备份证书中的一个。剩余的完全激活的或部分激活的pin可以用来保持网站在线。
  • 一个丢掉了所有pin 的控制权的操作人员可以通过撤销与这些pin相关的所有证书来恢复。在最坏的情况下,如果不存在任何证书的记录,还可以从证书透明日志中恢复它们。
  • 如果绑定被无意地或恶意地激活,那么站点操作人员可以通过在证书透明日志中跟踪所有被绑定的证书并撤销它们来进行恢复。
  • 一个具有有效的但却是假冒的证书的MITM无法冒充一个绑定的站点,这是因为他们的证书链无法匹配已被绑定的证书。在这种情况下,当出现一个不匹配的证书链时,用户代理使用OCSP来验证pin的状态。如果他们收到“仍然有效”的回应,或者如果他们没有找到OCSP应答器,那么他们就无法关闭。

与HPKP/RFC 7469的对比

与在RFC 7469中定义的HPKP的当前版本相比,这项关于带有撤销功能的HPKP的建议怎么样呢?

优点:

  • 可以从配置错误和恶意绑定所造成的绑定失败中恢复过来。
  • 在没有出现绑定失败的情况下,HPKP工作流程是不变的。
  • 在没有出现绑定失败的情况下,在性能上不会有影响。

缺点:

  • Pin撤销的可靠性和性能取决于所选择的证书颁发机构的 OCSP基础设施的质量。
  • 在证书颁发错误或者是对手发动了成功的攻击的情况下,你所选择的证书颁发机构都有撤销pin的能力。

探讨

HPKPbis的优点是很美观很清楚,但是让我们来更仔细地看看它的缺点。有两个问题出现了,第一个问题是,OCSP基础设施是否适合完成工作任务,第二个问题是关于未授权的pin撤销的风险。

OCSP基础设施可靠性

传统上,OCSP的有着不太稳定的名声。最近,我们已经看到证书颁发机构在向CDN过渡的过程中在OCSP应答发送方面的巨大改进,但是很多人仍然对此感到紧张。问题在于:当你确实需要pin撤销才能完美地工作时,你的证书颁发机构的OCSP应答器是否可用,它们是否会承担责任?

好消息是,站点操作人员可以主动选择他们所使用的证书颁发机构,这意味着,选择那些在已被证明具有维护高可用性证书撤销基础设施的经验的证书颁发机构,可以很大程度上降低风险。

正如Richard Barnes向我指出的那样,也许可以重新调整OCSP的stapling功能来传输pin的撤销信息。目前有一种(很少使用的)TLS扩展,支持多种绑定的OCSP响应的传输。在一个部署场景中,可以使用一个OCSP响应来证明当前证书的新鲜程度,并使用额外的绑定的OCSP响应来撤销所有先前的pin。

从技术上讲,这是可行的。使用OCSP stapling功能来撤销HPKP的pin的优点是,能够可靠地将pin撤销信息传递给终端用户。另一方面,与基于需求的OCSP(只有当它们有pin需要打破的时候,才会由用户代理来调用)不同,为pin撤销绑定的OCSP响应需要一直发送给所有用户,直到先前的绑定配置过期(通常一个或两个星期,但也可能达到两个月)。这样会增大尺寸,从而减慢每次完整的TLS握手的速度。

恶意撤销攻击向量

  • 更有趣的是,潜在的新攻击向量以未经授权的证书撤销的形式出现。毫无疑问,HPKPbis在这方面技术上较弱。有两个场景:
  • 一个恶意的证书颁发机构可以撤销你的证书来破坏HPKP的pin。完全撤消一个活动证书很可能会破坏一些东西,这使它非常引人注目。作为一种改进,有恶意的诡计多端的证书颁发机构可以选择性地只对那些受到攻击的人进行“撤销”证书状态的响应。(如果实施了,从长远来看,撤销透明机制可能会有所帮助。)
  • 一个证书颁发机构还可能被说服使用社会攻击来撤销你的证书。这种攻击并不是那么有趣,因为它没有秘密可言;它很容易被检测到。

完全未经授权的撤销是一种笨拙的攻击,它可以在技术上突破HPKP,但代价很高。即使在没有重大破坏的情况下(这不太可能),也可以很容易地通过对证书状态的持续监视检测到这种攻击。

隐形的撤销更有意思,因为它们不会破坏任何东西,也不会被探测到。它们可能非常昂贵,因为它们只能与颁发这些证书的证书颁发机构进行合作。

使用多个证书颁发机构(它们可能在不同的法律管辖范围内)和完全激活的pin,可以在很大程度上减弱这两种攻击。此外,当一些政府部门在其国内发动这类攻击的时候,大部分机构不需要防范这类攻击。因此,一种更简单有效的缓解方法可能是与一个有能力的证书颁发机构建立牢固关系。这些机构已经习惯了处理这种类型的风险,例如保护他们的域名。

总结

  • HPKPbis扩展了HPKP,并添加了一个pin撤销机制。由此产生的公钥绑定方法安全性较弱,但是显著增强的可用性弥补了这一点,并大大减少了潜在的损害。
  • 对于那些计划部署公钥绑定或已经部署的人来说,HPKPbis是一个显著的改进。他们会感谢这个添加的pin撤销机制帮助他们在紧急状态下恢复设置。
  • 另一方面,还有一些不想使用绑定的人,他们可能担心该功能会被恶意使用,例如在DNS劫持之后。这一群体如果知道有一个恢复机制的话,就会高兴起来。
  • 浏览器供应商——如果他们不完全抛弃HPKP的话——可能会喜欢不那么危险的绑定机制。我们还没遇到过恶意的绑定,但是他们很可能会因为这样的原因而受到一些指责。他们可能还会对自己造成的引人注目的故障承受一部分指责。
  • 那些目前对HPKP不满意的人不太可能接受HPKPbis。对他们来说,这很可能太少也太迟了。

最终,HPKP的命运掌握在浏览器厂商手中。去除HPKP的支持比投入更多的精力要容易得多,特别是在他们的想法已经形成的时候。

相关阅读:

HPKP:炙手可热还是濒临死亡?

CAA新标准生效第一日 Comodo违规

Jesdoit阅读(304)评论(0)

新的CAA(Certificate Authority Authorization)标准于本月8日上线,而就在新规上线的第二天,某德国籍安全研究员爆出Comodo破坏规定并误发了证书。

CAA允许网站拥有者指明哪些证书颁发机构可以为他们颁发证书。 网站所有者可以通过在DNS条目中添加文本字段来为其域设置CAA规则,如下所示:

sslchina.com. CAA 0 issue "xxxx.com"

这个小规则告诉任何证书颁发机构,只有xxxx可以为sslchina.com域发出SSL证书。

Comodo颁发SSL证书 无视CAA规定

根据CA /B论坛在Ballot 187中批准的CAA标准的规定,今年四月,Comodo等证书机构必须在发出新的SSL证书之前先检查DNS记录中的CAA字段。

星期一,德国安全研究员HannoBöck向信息社区透露,即使CAA领域限制SSL发行仅限于Let's Encrypt,他也为自己的网站从Comodo获得了SSL证书,现已被撤销。Böck表示,他在上周六获得证书,也就是CAA检查在9月8日星期五成为强制性的第二天。

“我最初是从邮件提供商mail.de的Michael Kliewe那里得知Comodo缺少CAA检查的,”Böck在邮件列表中写道。 “但那是CAA成为强制性之前。”他补充道:“而今我已从多位其他人口中确认并证实了这一点。”

“现在看来,Comodo根本没有检查CAA。”

有趣的是,Comodo官方表示,该公司完全符合新CAA的要求。那么事实是否真的如此呢?让我们静待解释。

 

稿源:bleeping computer

终章:Firefox 58将移除WoSign和StartCom根证书

Jesdoit阅读(347)评论(0)

WoSign和StartCom违规颁发证书事件可能是过去一年里SSL行业里最大的新闻,而明年的一月将成为事件的终章。

Mozilla于8月30日在其安全博客中宣布了对该事件的最终计划——在Firefox 58中完全移除WoSign和StartCom的根证书。

去年10月,Mozilla曾宣布同其他主流浏览器采取同样的措施,并且停止验证所有WoSign和StartCom的新证书到其根证书。该变化从Firefox 51开始执行。

而在明年年初即将发布的Firefox 58中,Mozilla将会从信任列表中完全移除它们的根证书。

使用链接到任何以下根证书的证书的网站需要迁移到另一个根证书。

详细地说,以下根证书将在Firefox 58中被移除:

  • CA沃通根证书
  • Certification Authority of WoSign
  • Certification Authority of WoSign G2
  • CA WoSign ECC Root
  • StartCom Certification Authority
  • StartCom Certification Authority G2

简而言之,基本上是同一家公司的WoSign和StartCom被曝光误发SSL证书,以规避CAB论坛的标准。 CAB论坛是Web浏览器和证书颁发机构大会,是SSL行业的事实监管机构。

经过一系列会议后,WoSign的首席执行官辞职,浏览器厂商们草拟了一个计划,其中两个CA将逐渐不信任,直到其根源将从信托商店中删除。

Mozilla近日宣布,最后的截止日期是2018年1月。

关于整个事件的前因后果,有兴趣的读者可以参看SSL中国之前发布的跟踪报道:

【9.27更新】Mozilla 将不再信任 WoSign 和 StartCom 颁发的新证书

 

稿源:The ssl store

为什么Chrome浏览器会告诉你HTTPS站点是“安全的"

Jesdoit阅读(261)评论(0)

为配合挂锁图标,7个选项被进行测试,其中包括“私有的”和“加密的”......

去年12月份,Chrome浏览器55版本引入了“安全的”标签来表示一个有效HTTPS连接,与过去几十年中浏览器一直使用的挂锁标志一起出现。

Google SSL Certificate

毫无疑问,谷歌Chrome浏览器是浏览器安全界面的创新者和领导者。他们的团队一直在做多方面的努力,通过简化图标来改善HTTPS(还记得那个曾经在Chrome浏览器中使用的黄色“警告”三角形吗?),用简单的英语重写浏览器错误,并在不安全的时候警告用户。

新的“安全”文本是对Chrome浏览器安全指标的改进的一部分,这一改进是基于他们的工程团队所进行的研究。目标是让他们的指标更容易被终端用户所理解。

这在一定程度上是由Chrome浏览器安全工程团队的一名家庭成员发起的,她不明白为什么她的浏览器会在地址栏显示一个钱包图标。

当你将它们并排放在一起时,挂锁与许多电子商务网站使用的“购物袋”图标有很大的相似之处:

你这是在苹果公司购物吗?

但对一些人来说,“安全”标签一直备受争议。

由于许多因素——包括浏览器引导的HTTPS推送和越来越多的自动和免费证书的流行——使用SSL的恶意站点比以往任何时候都要多。令人担心的是,用户将无法理解他们的浏览器告诉他们的信息之间的细微差别——他们的连接是“安全的”——和以下两者的混合:网站整体上是安全的(不受其它威胁,如恶意软件)并且/或者合法的(例如,一个“真正的”网站而不是钓鱼网站)。

当Chrome浏览器团队开始考虑如何让他们的图标看起来不像一个双把手的时候,他们在图标旁边试了文字标签,以“帮助用户理解安全指标,特别是对于那些对图标没有先入为主期望的新互联网用户。”

鉴于现在“安全”标签已经在Chrome浏览器中使用了近9个月,而且还在受到批评,我想深入研究这一变化背后的研究和测试情况,以及Chrome浏览器未测试成功的其他选项。

收集数据

Chrome浏览器团队去年在研讨会上发表了关于“可用隐私和安全(SOUPS)”的文章。

这篇文章报道了谷歌如何全面检查了所有的指标,但我们只想关注其中的一部分:“安全”标签,现在它伴随着Chrome浏览器的每一个有效HTTPS连接。

7个不同的文本标签与挂锁图标一起测试。

这些标签是:“https”、“私密”、“稳固”、“安全”、“加密”、“稳固、私密”和“安全站点”。

通过一项在线调查,Chrome浏览器团队收集了美国6462名用户的反馈。

这项调查给用户展示了“一个包含图标、字符串和模糊的URL的模拟浏览器截图”,并向用户提出了三个问题,这三个问题被设计用来体现三个不同方面的情况:对安全的感知、识别出的威胁、以及由此导致的用户行为。

Visual Indicators From Google's Study

下面是我们自己的模拟示例,类似于向用户所展示的:

调查的问题是:

1. 如果你看到这个浏览器页面,你对当前站点的安全性感觉怎么样?

  • 根本不安全
  • 有一点安全
  • 多少有一点安全
  • 很安全
  • 极为安全

2. 如果你在浏览器地址栏中看到下面的图标和消息,那么可能意味着有人也许【可以选择多个选项或“以上都不是”】

  • 尝试在你的计算机上安装病毒或恶意软件
  • 修改页面的内容
  • 已经在站点上创建了一个技术漏洞
  • 窃取你读取和输入的内容
  • 以上都不是

3. 如果你在你的浏览器中偶然发现一个站点,并且在地址栏中看到它,那么你最有可能做什么?

  • 我会正常浏览
  • 我会离开该站点
  • 我不会输入任何信用卡信息
  • 我会寻找关于该站点的更多信息
  • 我会快速浏览,然后离开

七个候选文本中的一个被展示给用户,用户回答关于相同设计的全部三个问题。

结果

Chrome浏览器团队已经决定保留挂锁,因为它为人们所熟悉。现在的目标是决定七个候选文本中哪一个是最好的。用户被要求评估他们对上述模型的整体反应——所以他们所判断的是图标和文字的组合。

以下是第一个问题的结果:“如果你看到这个浏览器页面,你对当前站点的安全性感觉怎么样?”

UI Question 1

当我们看这些数字时,很难得出一个结论。许多候选文本看起来表现得差不多。

为了更容易理解他们的表现,我给每个回答分配一个分数,从1分到5分,然后对它们进行平均。例如,每个“根本不”的回答将得到1分,每个“极其”的回答将得到5分。然后,每个候选文本都可以通过他们的总分来进行比较。

这类似于李克特量表。统计学家在这一刻不停地尖叫,因为我要犯两大罪过。首先,谷歌所选择的回答与李克特量表不完全匹配。此外,李克特量表是一个有序的尺度,而不是一个区间尺度,这意味着一个数学平均值不是很合适。

然而,这并不是学术期刊的一篇文章,而将李克特量表中的数据解读为区间数据,对于更广泛的读者来说,是有先例的。

除此之外,当我们为七个候选文本打分时,我们可以更好地了解每个选项的整体表现:

首先是“HTTPS”和“稳固”并列,其次是“安全”和“稳固站点”,并列第二。“私密”最后出现,而“加密”只会比它略好一点。

Chrome浏览器的研究团队也有自己的方法来挑选赢家:在“稳固”的受访者中,觉得网站多少有一点安全的人最多(占40%),而觉得网站根本不安全的受访者最少(占12%)。

如果我们的目标是将感觉“根本不安全”的用户的数量降到最低,并使感到“多少有点”安全的用户数量增加到最大,那么“稳固”就是明显的赢家。在这两种情况下,没有其他候选文本表现得很好。

我之前说过,每一个调查问题都是为了评估一个效果的不同方面。第一个问题是评估对页面安全性的感知。

我们已经有两个早期的领先者:“HTTPS”和“稳固”。

关于第二个问题:“如果你在浏览器地址栏中看到下面的图标和消息,那么可能意味着有人也许”。

对于这个问题,用户可以选择多个选项,或者“以上都不是”。这个问题是用来测试用户认为图标被设计用来表示什么类型的威胁。对于HTTPS图标,用户应该能够区分不同的威胁,并识别安全HTTPS连接所带来的好处。

我们希望看到用户指出该站点可能存在病毒/恶意软件(Malware),并且该站点可能有一个技术缺陷(“bug”),因为HTTPS处理的是完全不同的威胁。他们不应该指出他们的信息处于危险中(“Steal”),或者页面可能被修改(“Modify”),因为指出这些问题是HTTPS的主要优点,并且表明他们正在与预期的意义背道而驰。

“没有”可能表明对图标的理解不准确,或者错误地认为该指标意味着站点总体上是“安全的”,没有任何威胁。选择“没有”的受访者的比例很高,这种情况并不好。

下面是结果:

UI Question 2

对于全部七个候选文本,选择“没有”的用户的比例都很高。Chrome浏览器团队写道“这表明我们的指标被广泛认为是总体安全指标,而不是具体的连接安全指标。”

这是重要的。这意味着他们选择的所有候选文本(或其本身的挂锁图标)都与“安全”站点有很强的关联。这是浏览器想要避免的常见误解,因为从技术的角度来看,HTTPS会做出非常具体的、非常有限的安全保证,而不是“万能的”。例如,HTTPS网站可以像HTTP网站一样方便地提供恶意软件。

很难对这个问题的结果进行评估,因为没有办法去建立一个度量标准。(至少)有两种不同的方法来判断最佳表现:

1、哪些选项的“偷窃”和“修改”回答组合的比例最低,因为这是一个用户不应该在HTTPS页面上关注的两个威胁。

2、哪些选项的“以上都不是”回答的比例最低?

这里的问题是,在这两种情况下,没有一个指标表现良好。事实上,在我们的第一个度量标准中表现良好的候选文本在第二个度量标准中表现得较差,反之亦然。

按照第一个度量标准,“HTTPS”、“稳固”和“安全站点”依次表现最佳。其他候选文本和这三个候选文本之间存在明显的差距。表现第二好的选项只落后了5%。“私密”选项的表现是最差的。

然而,按照第一个度量标准,“私密”选项表现最好,51%的用户选择“没有”,而“HTTPS”和“稳固”选项则表现最差,有近2/3的用户认为没有威胁与之相适应。

“私密”看起来是最不具有误导性的。更多的用户能够识别出一个被标记为“私密”的网站仍然可能有恶意软件或技术漏洞,这两种威胁是HTTPS无法保护的。这表明“私密”是最不可能过分承诺其所提供的安全利益的。

Chrome浏览器团队指出,“受访者最可能信任一个带有“https”和“稳固”字样的页面”。这两个字样确实是最接近HTTPS所提供的的安全利益的。

我们可以把所有的选项都看做是失败的,因为超过半数的受访者认为,这些选项表明没有任何威胁。

最后来看问题3:“如果你在你的浏览器中偶然发现一个站点,并且在地址栏中看到它,那么你最有可能做什么?

这个问题的设计目的是为了查看用户在看到安全连接标识时会做什么。作者并没有在这里给出一个理想的行为,但是正常浏览(“正常地”)看起来是一个理想的行为。

我们不希望用户立即离开网站(“离开网站”)或快速浏览然后离开(“快速地”)。我们可以想象这对电子商务产生的影响以及如果安全连接误导用户从页面离开带来的反弹率。

UI Question 3

在这里,“私密”再一次排在了最后。在该选项下,声称将会离开网站的用户比例最高(28%,与“加密”选项并列)。只有25%的用户说,当他们看到挂锁和该文本的组合时,他们还会正常浏览——这是一个非常糟糕的比例。

在“稳固”选项下,表示将离开该网站的用户比例最低,其次是HTTPS选项。在这两个候选文本下,声称自己会正常浏览的用户比例最高,不过HTTPS以更大的优势胜出。

出乎意料的是,在“HTTPS”选项下,声称不会输入信用卡信息的用户比例最小。技术含量更低的“安全”和“稳固站点”选项的表现也差不多。“稳固”和“私密”在这里表现不佳。

谁是赢家?

我们已经看了数据,现在是时候找到整体上的赢家了。对这七个候选文本,调查中有一些清晰的模式。

我们看到“稳固”现在占据着数百万Chrome浏览器用户的地址栏,所以我们显然知道Chrome浏览器团队是怎么想的。该团队在报告中写道:“我们发现‘稳固’和‘https’是‘绿色锁’图标最好的伴侣。”

看完数据后发现,他们是对的。

“私密”的表现不太好,在所有文本中表现几乎最差。我还是必须要给“私密”选项一些分数,以免过分承诺保护的作用——用户可以更准确地识别一个被标记为“私密”的网站可能会有恶意软件或漏洞。但仅凭这一点就无法弥补其在大多数测试指标中的糟糕表现。

我们还没有谈到的一个候选文本是“加密”。从技术角度看,这是更准确的选择之一。调查结果显示,这条路是中间路线——这通常比“HTTPS”更糟糕,尤其是在用户操作的关键领域(问题3)。它模糊了一般理解的界限。虽然它不是像“HTTPS”这样的技术术语,但大多数用户不太可能很好地理解加密的工作方式。

有趣的是,31%的回答错误地认为当页面被标记为“加密”时,页面可能被修改或者他们的信息可能被窃取,而对“HTTPS”选项来说,这一比例只有24%。这就对大多数互联网用户不理解“HTTPS”是什么的假设构成了挑战。

“安全”将是一个糟糕的选择,因为它的含义过于宽泛。这里的整个问题是,在一般情况下,我们把“稳固”和“安全”当做同义词使用,但在互联网上它们是完全不相关的概念。

浏览器安全和UI团队一直在有意地试图将以下观念分离开来:安全的连接意味着站点总体上是安全的。讽刺的是,“安全”标识被很多人视为威胁(问题2)。

“稳固、私密”和“安全站点”都会因为它们的大小而造成问题。浏览器在正确显示URL方面已经有难度了,而伴随着每一个安全页面的长文本字符串更不会带来帮助。仅凭这一点不可能排除它们,但它们也未能在调查中表现出任何突出的效果。

这让我们回到了Chrome浏览器团队确定的两个候选文本:“HTTPS”和“稳固”。

在重新设计之前,当连接安全时,Chrome浏览器已经在地址栏中显示了“https://”。这是一个已经存在多年的标识,可能已经被用户理解了。“HTTPS”的一些调查结果是很有希望的——尤其是与技术含量较低的候选文本相比——但考虑到它出现的时间已经很长了,所以对它的认可比它应得的要低得多。

Chrome浏览器团队“更喜欢‘稳固’,因为它专业性弱一些”。

未来我们可能会看到,当Chrome浏览器尝试简化用户界面时,“https://”方案被移除。

有益还是有害?

在这篇文章的顶部,我说“稳固”标签是有争议的。即使在看了这些数据之后,问题依然存在:

“稳固”标签是否可能无意中伤害了用户?

Chrome团队的研究并没有试图回答这个问题。虽然我们可以从这项研究中得出一些关于用户感知的一般性结论,但从如此广泛的证据中得出这样一个明确的结论是有误导性的。

不可否认的是,部分用户将“稳固”标签解释为一个站点是完全安全合法的,因此他们做出了不安全的选择。但我们只是不知道这样的用户所占比例有多大。

同样不可否认的是,“稳固”标识——以及与它完全相反的“不稳固”标识——正在鼓励更多的网站采用HTTPS。而这些文本标识正在帮助和教育一些不太喜欢挂锁图标的用户。我们还不知道这样的用户所占比例有多大。

现实情况是,人们还不能得出这样的结论,因为它还没有被真正研究过。

但是,本文的目的并不是要让你确信“稳固”标签到底是好是坏,只是为了阐明使用它以及它被选中的原因。正如数据向我们展示的那样,通常建议的“加密”和“私密”选项也都经过了测试,并有一些较大的缺点,对于Chrome的团队来说,这抵消了他们的优势。

最终,Chrome浏览器的目标是将HTTPS作为web的默认状态,而“稳固”标签(以及挂锁)将被移除,以实现对HTTP站点的更强的警告。因此,即使你相信“稳固”标识对用户安全来说是最糟糕的事情,你也可以感受它不可避免的消亡。

 

稿源:本文由Vincent Lynch发布在The ssl store blog. 原文出处在,欢迎指正!

七月SSL行业新闻回顾

Jesdoit阅读(209)评论(0)

大事件一:被泄露的私钥和基于假私钥进行的撤回

上个月,我们报告说Spotify和Cisco在应用程序中捆绑了有效证书的私钥。这些证书将根据基准要求被撤销,但应用程序不是泄露私钥的唯一来源。Koen Rouwhorst发现了各种属于GitHub存储库中的有效证书的私钥。你甚至能通过标准文件名(如server.key)在相应的网站上下载这些密钥。根据规定,所有被泄露的私钥都必须在24小时内由证书颁发机构撤回。于是如何彻底地测试这种密钥泄露成为了难题。(比方说,本文作者成功使用山寨密钥请求赛门铁克撤回证书。)(赛门铁克做出了如下回应。)

大事件二:TLS拦截引发争议

TLS工作组目前正在讨论Matthew Green关于如何使用静态Diffie-Hellman允许被动TLS解密的建议。这个讨论是由某银行组织抱怨TLS1.3移除了旧的RSA密钥交换而引发的。

近来,TLS邮件列表上的那些冗长的讨论以及布拉格IETF会议上的辩论都由此展开。然而至今仍没有达成什么明确的共识。斯蒂芬·切科维(Stephen Chekoway)撰写了辩论的总结。 来自Cloudflare的Nick Sullivan在发言中涵盖了争议。

本月短新闻

稿源: Feisty Duck

Mozilla将响应谷歌的赛门铁克证书计划

Jesdoit阅读(255)评论(0)

两大主流浏览器厂商将采用相同的时间表进行规范......

在上周谷歌提出针对赛门铁克证书事件的一系列解决方案后,管理Firefox和NSS(一组开源加密库)的根程序的Mozilla也在近日宣布将采纳谷歌的大部分决定。该计划的大致结果是:

  • Symantec的现有根证书将被停用。新根将提交给根方案。
  • 赛门铁克将通过合作的证书颁发机构继续发布证书,因为它经过新的根审核和分发的过程。
  • 2016年6月1日之前颁发的赛门铁克证书(当他们开始证书透明度记录时)将需要通过重新发放证书(免费)来取代,或者可以提早更新。
  • 2018年10月,所有从当前根源发布的赛门铁克证书将需要更换。

在Mozilla的根程序上工作的Gervase Markham表示:“我们已经决定将Google提出的针对Chrome的日期进行匹配(在几周内,确切的Firefox版本将在更接近的时间确定)。

由于Firefox和Chrome的发布时间表完全不匹配,Mozilla可能会在Chrome之前或之后实施其更改。浏览器版本只是估计,保证日期不会提前发布。因而为了迎合Firefox的要求,提前采取措施是很有必要的。

那么苹果和微软呢?

苹果和微软也管理自己的平台的根证书商店。按照惯例,两家公司都没有公开评论他们将如何处理赛门铁克。

不像谷歌和Mozilla,习惯以很大程度的透明度来操作他们的根程序,苹果和微软不会主持公开讨论或接受评论。这两个厂商一如既往地动作缓慢。

但别担心,这很正常。通常情况下他们会征求同事的意见,或者干脆不怎么变化。

至于受到赛门铁克证书事件影响的组织和网站,大可放心地针对Google宣布的计划来安排证书的更替。

除非苹果和微软的计划更早生效,否则不应与Google和Mozilla冲突。

 

稿源:The ssl store