关注网络安全
和行业未来

九月SSL行业新闻回顾

Jesdoit阅读(94)评论(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阅读(115)评论(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阅读(207)评论(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阅读(191)评论(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阅读(161)评论(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阅读(160)评论(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阅读(163)评论(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

谷歌和赛门铁克公司达成协议 推迟原定于8月8日的截止日期

Jesdoit阅读(200)评论(0)

今年三月,谷歌的Chrome浏览器团队提出了赛门铁克违反SSL证书颁发相关行业标准的问题。为了达成一个共赢的方案,谷歌、赛门铁克及互联网社区的其他成员在过去的四个月内不断进行着协商和讨论。而就在近日,Chrome浏览器团队和赛门铁克公司宣布了他们的最终推进计划。起初设定的2017年8月8日的截止日期不再适用。

如果你的网站正在使用赛门铁克的SSL证书,本文将会为你解答,查看Chrome的未来版本是否会影响您的特定证书,以及如何在一切生效之前替换该证书(免费)。

我会受这个协议的影响吗?

如果你目前是赛门铁克公司证书的用户,或计划在2017年要购买他们的证书,那么这可能会对你产生影响。

作为证书颁发机构中的大佬,受影响的赛门铁克SSL证书的数量比预想的要多。注意,赛门铁克公司运营着不同的品牌,所有这些品牌都会受影响:

  • Symantec
  • GeoTrust
  • Thawte
  • RapidSSL

Mozilla的火狐浏览器也在酝酿一系列措施,但目前还没有制定出任何计划。

值得庆幸的是,在2018年来临之前,你仍有很多时间来做准备。

Chrome对赛门铁克问题证书取消信任的计划分为两步。第一阶段,2016年6月1日以前颁发的证书将受到影响。第二阶段,所有从赛门铁克公司目前的根证书颁发的证书都会受影响(包括还未颁发的证书)。

为了遵守谷歌的计划,你需要通过一个免费的重新颁发和重新安装过程来替换现有的赛门铁克证书,但过程并不繁琐。

为什么谷歌不信任赛门铁克证书?

由于赛门铁克公司违反了行业标准,谷歌Chrome浏览器决定,赛门铁克目前的根证书(这是该公司SSL产品受信任的根本)需要由Chrome浏览器重新审核。由一系列测试证书的错误颁发引起的“血案”,促使谷歌提出对所有赛门铁克证书的怀疑。

由于谷歌所处的位置,很多赛门铁克SSL证书最终将不再被Chrome浏览器信任,如果使用HTTPS的用户未采取适当行动的话,还将收到报错。

这一过程将分为两个阶段,第一阶段从2018年4月开始,第二阶段将会在2018年10月(我们将在下一节详细讲讲这些变化的细节)。

然而,请注意,赛门铁克公司仍将可以通过使用不同的技术架构继续颁发可信证书

赛门铁克公司将首先与另一家妥善管理的证书颁发机构合作,该机构将从今年12月开始以赛门铁克公司的名义颁发证书。在赛门铁克公司向浏览器提交新的根证书期间,这个合作伙伴将继续处理证书颁发有关事务。

这将允许赛门铁克公司在谷歌宣布做出这些改变期间不间断地继续颁发可信证书。

长期来看,赛门铁克公司新的根证书将广泛发放给各种设备,这会使他们开始自己颁发证书。

我该怎么办?

Chrome提出的两个阶段将以Chrome 66和Chrome 70两个版本的发布为节点。目前的版本是61。

Chrome 66发布时(预计在2018年4月中旬)如果未采取适当措施,所有2016年6月1日前颁发的赛门铁克证书都将不再受信。

这意味着Chrome浏览器66版本以上的用户将不能与你的网站建立HTTPS连接,并将收到一个警告。

第二阶段将从Chrome浏览器70版本发布(预计在2018年10月末)开始。如果未采取适当措施的话,那么所有由赛门铁克目前的根证书颁发的证书都将从这一天开始不受信任。

根据你当前证书的颁发和失效日期,你可能需要替换你的赛门铁克证书,以在此期间保持证书可信。这可能取决于赛门铁克公司未来的PKI改进措施的时效。

为便于了解这一系列事件,我们把这些信息分解成一个时间表。Chrome浏览器不再信任的两个阶段是截止日期,它们被加粗了,以清楚地显示一般信息和可操作步骤的区别。

(大约的) 日期 Chrome 浏览器版本 会发生什么? 怎样做准备?
2017年10月24日 62 Chrome浏览器62版本将在开发人员工具中显示一条消息,以帮助确认在Chrome浏览器66版本中将不再受信的证书。 在打开开发人员工具面板的情况下访问你的网站——这将使你明确哪个站点会在Chrome浏览器66版本中不再受信。
2017年12月1日 N/A 一家合伙证书颁发机构将开始为赛门铁克公司颁发证书。 作为终端用户,你可能会注意到颁发过程中一些微小的变化。

 

从技术角度看,该日期意义重大,因为这标志着“新的”赛门铁克证书的开始。

 

在此日期之后颁发的证书将会由不同的根证书颁发,不会受Chrome浏览器的不信任的影响。

2018417 66 所有在2016年6月1日前颁发的赛门铁克证书将不再被Chrome浏览器信任。

 

2016年6月1日后颁发的证书在这一版本中将不受影响。

在此日期之前替换所有2016年6月1日颁发的赛门铁克证书。

 

可以由你的证书提供商免费重新颁发和安装,以替换旧的证书。

 

如果你的证书在此期间(4-6月)失效,你可能需要考虑更新它,而不需要重新颁发,以避免短期内进行两次替换。

20181028 70 所有赛门铁克公司以其现有架构颁发的证书都将不再被Chrome浏览器信任。 从今年12月1日起,你将可以从赛门铁克公司的合伙证书颁发机构那里收到新的证书。

 

从技术角度看,这些证书将有另一个证书颁发机构颁发,会继续受到Chrome浏览器信任。

从Chrome浏览器62稳定版开始,当遇到一个Chrome浏览器66版本不再信任的证书时,在开发人员工具面板中,将会出现一个消息提示。开发人员可以依靠这一功能来确认他们网站中将受到影响的证书。

你还可以下载Chrome Canary版本来预览即将出现的新功能。预计Chrome 66将在明年1月推送到Canary。

或许可以这么做

为减少中断和需要做的工作,我们建议采取以下措施:

如果你的证书在2017年12月前失效···

我们建议你在12月前更新(而不是重新颁发)你的证书。这会使你在假期中拥有一个可信证书,直到2018年10月所有由赛门铁克公司现有的根证书颁发的证书都会出现问题并需要替换。

如果你的证书在12月当月失效···

我们建议你现在就考虑替换证书以避免出现中断。目前,赛门铁克公司希望在12月1日(一个星期五)前找到合伙证书颁发机构。如果你可以等到那时重新颁发和替换你的证书,你将很可能在下一次自然失效日前前不需要再替换一次证书了。

但是,注意可能会发生延迟,这就会使赛门铁克公司预估的12月1日发生问题,这可能会导致那时需要进行超常的大量证书颁发工作,从而引发技术问题。

如果出现这种情况且你现在的证书失效日期过于接近那个日期,你的证书可能会有中断的风险。“假期冻结”也可能使你不需要在这个月替换证书。

如果你必须要在赛门铁克合伙证书颁发机构做好颁发证书的准备之前替换你的证书,那么在Chrome 70发布(预计在2018年10月末)之前可能需要再一次替换你的证书。

如果你的证书在2017年12月31日后失效···

我们建议你等到赛门铁克公司的合伙证书颁发机构开始颁发证书(预计在2017年12月1日)再替换你的任何证书。

在此日期之后,你可以开始根据需要重新颁发和替换证书。

如果你的证书在2018年3月30日前失效···

早点更新证书将会是最简单的做法。这样你只需替换一次证书。赛门铁克公司的合伙证书颁发机构颁发的证书将不会受Chrome浏览器变化的影响,在其自然有效期结束前也不需要替换。

特殊情况:如果你的证书是在2016年6月1日前颁发并在2018年4月17日后失效···

你处于一种特殊情况。你的证书必须在Chrome浏览器66版本发布(预计会在2018年4月17日)前重新颁发和替换,以保持Chrome浏览器的信任。

但是,你应该2017年12月1日以后再重新颁发你的证书。在这一天,赛门铁克公司的合伙证书颁发机构将开始颁发证书。在此之前,你将只需要替换一次你的证书。

如果你在赛门铁克公司的合伙证书颁发机构出现之前重新颁发你的证书,那么你的证书将来自赛门铁克公司当前的一个根证书,它在2018年10月后仍需要被替换。

 

稿源:The ssl store

Let's Encrypt与DNS轮循

Jesdoit阅读(216)评论(1)

本文由网络安全研究员、securityheaders.ioreport-uri.io创始人Scott Helme发布在其个人博客中。描述了如何使用Let's Encrypt的同时兼容DNS轮循。

早些时候,我所经营的securityheaders.io经历了一段负载特别高的时期。在那段时间里,我尝试研究并整理其根本原因,想在网站后端投入更多的云资源来强化它。

DNS轮循

我想转移另一台服务器,将负载从当前的securityheaders.io运行的单个实例中分离出来。计划很简单:创建服务器,向DNS添加IP地址。 DNS循环允许您在同一个域中拥有2个(或更多)IP地址,并以不同的顺序返回,以便客户端使用不同的IP地址。这个想法最终达到了相当基本的负载平衡,使得每个服务器均分50%的流量。这么做在解决了我的负载问题同时,引入了一个新问题——更新证书。

Let's Encrypt

我使用了Let's Encrypt的证书,他们通过在你主机里的某个特殊路径里放一个简单的HTML文件,来实现DV challenge。这个工作机制在仅针对一个服务器时效果拔群,但问题是,我现在有两个。要是我其中一个服务器请求证书、托管这个HTML文件,结果Let's Encrypt将我的IP地址解析成另一个服务器的IP,但这个服务器上没有响应文件,那岂不是很尴尬?证书请求失败,那就玩不下去了?幸好,我们可以用Nginx来解决!

Nginx命名地点

在Nginx中,我们通常定义一个位置块和路径。 以下是我常用的接受ACME challenge的位置信息:

location /.well-known/acme-challenge/ {
alias /home/acme/challenges/;
try_files $uri;
}

该路径将匹配/.well-known/acme-challenge/,我已将其别名到写入challenge文件的文件系统文件夹中,try_files将检查文件的存在。 这一切都很好,直到该文件可能在另一个服务器上,这就是所在的位置。try_files指令可以采用多个参数,Nginx会遍历它们,直到匹配。 我们现在可以引入另一个参数并创建一个命名的位置:

location /.well-known/acme-challenge/ {
alias /home/acme/challenges/;
try_files $uri @proxy;
}

这告诉Nginx在本地查找该文件,如果没有找到,那么将其传递给@proxy。 我们现在需要定义命名的位置:

location @proxy {
proxy_pass http://162.243.159.108:8080;
}

在这个位置,我正在使用proxy_pass指令将请求传递给另一个服务器。 第二台服务器正在监听端口8080,专门针对已经通过的ACME challenge:

server {
listen 192.241.216.219:8080;
server_name 192.241.216.219;

location / {
return 301 https://securityheaders.io$request_uri;
}

location /.well-known/acme-challenge/ {
alias /home/acme/challenges/;
try_files $uri =404;
}
}

第二台服务器被配置为监听IP,并回答ACME challenge,或将流量重定向并返回到securityheaders.io域。 我还向UFW添加了一条规则,只允许每个服务器根据其IP地址与端口8080上的其他服务器进行通信。

解决这个问题的最佳方法可能是使用DNS challenge而不是HTTP。 之前Let's Encrypt增加了对此的支持。不过可惜的是,我是用的客户端acme_tiny并不支持这项功能,而我只想走一条快速简洁的捷径。因而上述做法仅适用于几台服务器之间周转,扩展性不佳。但如果你和我一样只想快速搞定,这个方法可以一试!

稿源:scotthelme.co.uk

 

六月SSL行业新闻回顾

Jesdoit阅读(188)评论(0)

大事件一:思科和Spotify在应用程序中发送私钥

2017年6月度发生的几起应用程序传输私钥事件引发了业界关注。包括思科、Spotify、Github、Dropbox和 Discord在内的多个知名应用均被发现把私钥传给了客户端。 所幸这些证书都是之前已知且已被撤销的。

在大多数情况下,证书的意图是为了让应用程序打开本地Web服务器,以便公司的Web服务可以在浏览器中与服务器进行通信。随着越来越多的网页移动到HTTPS,如果本地服务器没有有效的证书,则此过程将被阻止。

人们对于浏览器是否应将本地主机IP(例如127.0.0.1)视为安全来源的问题进行了讨论。就算本地主机使用的是未加密的HTTP协议传输也能称作“安全”吗?未来的浏览器可能允许这种做法,而不需要运送证书和密钥。但是,CA或浏览器的基准要求禁止这种做法。如果私钥公开,则相应的证书会被撤销。

短新闻

稿源:The Feisty Duck