关注网络安全
和行业未来

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

本文由  于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:炙手可热还是濒临死亡?

评论 抢沙发