专栏首页包罗万想GCAC61 13.8 Certificates and the public-key infrastructure

GCAC61 13.8 Certificates and the public-key infrastructure

13.8 Certificates and the public-key infrastructure(PKI)证书和公钥基础设施

  • 获得证书(Obtaining a certificate)
  • X.509证书(X.509 certificates)
  • 证书链(Certificate chains)
  • 证书链和基本约束(Certificate chains and basic constraints)

13.8.1 Coping with malicious or negligent certificate authorities应对恶意或疏忽的证书颁发机构

  • 证书固定(Certificate pinning)
  • 证书透明度(Certificate transparency)

13.8.2 Certificate revocation

  • 短期证书(Short-lived certificates)
  • 证书吊销列表(Certificate revocation lists (CRLs))
  • 在线证书状态协议(The online certificate status protocol (OCSP))

13.8 Certificates and the public-key infrastructure(PKI)证书和公钥基础设施

参考之前写过的一篇结构更清晰的笔记:Day3证书、SSL/TLS

接下来,我们转向数字签名的主要应用之一,即它们在证书和公钥基础设施中的使用。证书最简单 的形式是将公钥绑定到身份的数据块。该绑定由称为证书颁发机构(CA)的第三方声明。我们首先讨论如何颁发证书的机制,然后讨论在管理证书方面的一些实际问题,特别是如何应对行为不当的CA以及如何吊销证书。

获得证书(Obtaining a certificate)

Alice希望获得其域名alice.com的证书。她向CA发送了证书签名请求certificate signing request(CSR),其中包含Alice的身份,她的电子邮件地址以及她希望绑定到其域名的公钥。

CA收到CSR后,便会检查Alice是否是她声称的身份。在某些情况下,此检查与向Alice的地址发送挑战电子邮件并验证她可以阅读该电子邮件一样简单。在其他情况下,通过要求经过公证的证明Alice身份的文件来完成的。我们强调,证明Alice的真实身份是CA提供的主要服务。如果所有检查都成功,则CA将相关数据组装成证书结构,并使用CA的签名私钥对其进行签名。生成的是将CSR中的公钥绑定到Alice的身份的签名证书。一些CA免费提供证书,而另一些CA则需要Alice付款以颁发证书。

可以将生成的签名证书发送给需要与Alice安全通信的任何人。拥有CA验证密钥的任何人都可以验证证书,并可以确信已认证的公钥属于Alice。

X.509证书(X.509 certificates)

证书是根据称为X.509的标准格式化的。图13.4给出了一个示例X.509证书,该证书将公钥绑定到主题字段中标识的实体。在这里,该实体恰好是FacebookInc.,其公钥是(椭圆曲线)ElGamal公钥,如图所示。证书是由称为DigiCert Inc.的CA颁发的,CA使用RSA签名密钥使用SHA256作为哈希函数的PKCS1标准对证书进行签名。 CA签名的一部分显示在该图的右下方。要验证此证书,需要DigiCertInc.的公钥。

每个X.509证书都有一个序列号,该序列号在证书吊销中起作用,如下面的13.8.2节所述。证书还具有一个有效期窗口:证书激活的时间和证书到期的时间。证书在其有效期之外被视为无效,应由验证者拒绝。有效期通常为一年或两年,但可以更长或更短。例如,图13.4中的证书的有效期约为17个月。限制证书生存期的原因是为了确保如果私钥被攻击者窃取,则该攻击者只能在有限的时间内滥用密钥。有效期越长,攻击者就可以越长时间滥用被盗的密钥。我们将在13.8.2节中进一步讨论此问题,在此我们讨论证书吊销。

拥有该CA公钥的任何人都可以验证由CA颁发的证书。如果世界上只有一个CA,那么每个人都可以存储该CA的公钥的副本,并使用它来验证所有证书。但是,单个全局CA效果不佳。首先,每个国家都希望为其所在地区的本地企业运行CA。其次,为了保持证书的价格低廉,最好使多个CA竞争颁发证书的业务。当前有数千个活动的CA颁发证书。

证书链(Certificate chains)

由于存在多个颁发证书的CA,并且新证书可以随时出现,因此面临的挑战是将CA公钥分发给需要验证证书的最终用户。该解决方案称为证书链,旨在允许一个CA认证另一个CA的公钥。此过程可以递归重复,从而形成证书链,其中证书链中的每个证书都将验证证书链中下一个CA的公钥。

顶级CA的公共密钥(称为根CA)已预安装在所有需要验证证书的客户端上。每个标准操作系统都附带有数百个此类根CA。根CA可以向中间CA颁发证书,而中间CA可以向另一个中间CA颁发证书。继续这种方式,我们获得了从根开始并包含一个或多个中间CA的证书链。最后,位于链底部的CA颁发用于最终身份的客户端证书,例如图13.4中的Facebook。

Facebook证书的证书链如图13.5所示。根CA是DigiCert Inc.,但其私钥保持在线状态,以减少被盗的风险。根密钥仅用于一件事:为中间CA颁发证书,该证书也由DigiCert Inc.拥有。然后,该中间CA使用其私钥向Facebook之类的客户颁发客户端证书。如果中间CA的密钥丢失或被盗,则可以撤销相应的证书,并且根CA可以为中间CA颁发新证书。

为了验证此长度为三的证书链,验证者需要根CA的公钥的本地受信任副本。该公钥使验证者可以检查颁发给中间CA的证书的有效性。如果有效,则可以确保可以信任中间CA。验证者然后检查由中间CA颁发给Facebook的证书的有效性。如果有效,验证者可以保证它具有适用于Facebook的正确公钥。

证书链和基本约束(Certificate chains and basic constraints)

X.509证书包含许多领域,我们在上面的讨论中仅涉及表面问题。在证书链的上下文中,我们提到了两个在安全性方面起着重要作用的字段。在图13.5中,我们看到颁发给Facebook的证书链的长度为三。 alice.com如何防止Facebook表现得像CA,并为另一个身份生成长度为四的证书链?这种证书链是Alice所不知道的,它将使Facebook扮演“中间人”,从而冒充alice.com甚至窃听alice.com的流量,类似于我们在10.7节中看到的。

Facebook无法颁发证书的原因是由于每个CA必须在其颁发的证书中嵌入一个基本约束字段。如果允许被认证的实体充当CA,则将该字段称为“ CA”字段设置为true,否则设置为false。为了使长度为l的证书链有效,必须是该链中前1-1个证书的CA基本约束设置为true。如果不是,则该链必须被验证者拒绝。 Facebook的证书的CA字段设置为“ false”,从而阻止Facebook充当中间CA。

证书验证包括许多其他这样的细微检查,通常很难正确实施。发现许多实现自定义证书验证的系统都是不安全的,从而使其容易受到模拟和中间人攻击。

13.8.1 Coping with malicious or negligent certificate authorities应对恶意或疏忽的证书颁发机构

到现在为止,应该清楚的是,CA具有强大的功能。任何CA都可以颁发恶意证书,并将错误的公钥绑定到Facebook。如果放任不管,流氓证书将使攻击者能够对发往Facebook的流量进行中间人攻击,并窃听Facebook与毫无戒心的用户之间的所有流量。在讨论了TLS会话建立机制之后,我们将在第21章中详细讨论这些攻击。有几种商业工具使之在实践中非常容易做到。

当前,Internet上有成千上万个中间CA,并且都可以颁发证书。由于大量的CA,因此经常发现错误的证书也就不足为奇了。这是事件的一小部分:

  • Diginotar是荷兰的证书颁发机构,2011年遭到黑客攻击。攻击者获得了* .google.com以及其他许多域名的Diginotar签名证书,从而使攻击者可以在所有这些域名上进行中间人攻击。作为响应,主要的网络浏览器供应商撤销了对Diginotar CA颁发的所有证书的信任,导致Diginotar于2011年9月宣布破产。
  • India NIC在2013年错误地为多个Google和Yahoo域名颁发了证书。该中间CA已通过印度CCA认证,印度CCA是Microsoft Windows信任的根CA。因此,Chrome浏览器不再信任印度NIC颁发的证书。此外,在此事件之后,仅信任印度CCA根CA为以.in结尾的域名(例如google.co.in)颁发证书。
  • Verisign在2001年错误地向伪装成Microsoft员工的个人颁发了Microsoft代码签名证书。该证书使该人能够分发合法地看起来像是由Microsoft编写的代码。作为响应,Microsoft发布了Windows软件补丁程序,该补丁程序撤消了对该证书的信任。

如我们所见,这些事件中的许多是由于CA的错误处理所致。每当颁发将错误的公钥绑定到域名的证书时,该证书就会对目标域名进行中间人攻击。最终结果是,攻击者可以检查和修改往返于受害域名的流量。

接下来的问题是如何识别和包含行为异常的CA。我们在下面讨论两个想法。

证书固定(Certificate pinning)

读者一定想知道如何首先发现上述事件。答案是一种称为证书固定的机制,Web浏览器现在广泛支持该机制。基本思想是对浏览器进行预配置,使其知道唯一被授权为域名facebook.com颁发证书的CA是“ DigiCert SHA2 High Assurance Server CA”,如图13.5所示。如果浏览器看到由不同CA颁发的facebook.com证书,则它将执行以下两项操作:首先,它将证书视为无效并关闭连接,其次,它有选择地向Facebook管理员发出警告,告知该流氓证书被发现。上面讨论的涉及印度NIC的事件是由于gmail.com的certificate pin而被发现的。印度的浏览器使Google警觉到gmail.com存在流氓rogue证书链。谷歌随后采取行动撤销了该链并展开了调查。流氓链中的签名提供了无可辩驳的证据,证明签发的CA出了点问题。

更详细地,证书固定如下。每个浏览器都维护一个固定数据库,大致来说,数据库中的每一行都是以下形式的元组(domain, hash0, hash1, . . .).

每个 hash i是哈希函数的输出(对于SHA256,则为32字节字符串)。每个记录的数据由域名所有者提供。例如,Facebook提供了facebook.com域名的哈希值。

当浏览器使用HTTPS连接到域名时,该域名会将其证书链发送到浏览器。如果域位于固定数据库中,则浏览器将计算链中每个证书的哈希值。令S为哈希值的结果集。令T为该域名的固定记录中的哈希值集合。如果S和T的交集为空,则证书链被拒绝,并且浏览器有选择地向域名管理员发送警报,指示遇到恶意证书链。

要查看其工作原理,请再次考虑图13.5中的示例链。域名facebook.com的固定记录只是单个哈希,即“ DigiCert SHA2 High Assurance Server CA”证书的哈希。换句话说,集合T包含单个哈希值。如果浏览器遇到facebook.com的证书链,其中链中的所有证书都没有哈希到固定值,则证书链将被拒绝。更一般而言,从多个CA购买证书的域名在其固定记录中包括所有这些CA证书的哈希。

Facebook为什么要在Facebook固定记录中写入其CA证书的哈希值?为什么不在固定记录中写入图13.4中Facebook证书的哈希值?实际上,将CA证书写入固定记录似乎并不安全;尽管存在固定记录,但DigiCert仍可以为facebook.com颁发流氓证书,该证书将被浏览器接受。如果相反,Facebook在图13.4中写了Facebook证书作为固定记录中的唯一哈希值,则DigiCert将无法为facebook.com颁发恶意证书。浏览器唯一接受的facebook.com证书将是图13.4中的证书。但是,这样做存在巨大的风险。如果Facebook以某种方式丢失了自己的私钥,那么世界上任何浏览器都将无法连接到facebook.com。固定CA证书可使Facebook只需要求DigiCert为facebook.com颁发新证书即可从密钥丢失中恢复。因此,关闭站点的风险大于DigiCert颁发恶意证书的安全风险。尽管对于像Facebook这样的大型网站而言,丢失密钥并不重要,但对于使用证书固定的小型网站而言,这却是一个重大问题。

最后,我们提到了创建固定记录的两种机制:静态和动态。 Static pins由浏览器供应商维护,并随浏览器一起提供。 Dynamic pins允许域名通过从服务器发送到浏览器的HTTP标头声明其自己的pins,如下所示:

这里的pin-sha256是要固定到的哈希值,max-age表示浏览器何时忘记该pin,report-uri是一个可选的地址,用于报告pin验证失败。只有通过加密的HTTPS会话发送的HTTP标头才被浏览器接受。通过未加密的HTTP发送时, header将被忽略。这样可以防止网络攻击者注入无效的pins。

证书透明度(Certificate transparency)

应对CA行为异常的完全不同的方法是基于公共证书日志。假设存在一个公共证书日志,其中包含曾经发布的所有证书的列表。然后,像Facebook这样的公司可以监视日志并了解有人为facebook.com颁发流氓证书的时间。这个称为证书透明性的想法很引人注目,但不容易实现。我们如何确保曾经颁发的每个证书都在日志中?我们如何确保日志仅是追加的,以便不能从日志中删除流氓证书?我们如何确保世界上每个人都能看到相同版本的日志?

证书透明性为所有这些问题提供了答案。在这里,我们只绘制架构图。当CA决定支持证书透明性时,它选择一个公共证书日志并扩大其证书颁发过程,如下所示:(1)在签署新证书之前,CA将证书数据发送到日志,(2)日志对证书数据进行签名并发回签名,称为签名证书时间戳signed certificate timestamp(SCT) 。(3)CA将SCT作为扩展名添加到证书数据中,并对结果结构进行签名,以获得最终颁发的证书。 SCT作为扩展嵌入在新颁发的证书中。

SCT是证书日志的承诺,可以在某个时间段(例如一天)内将证书发布到其日志中。每天中午,证书日志会将当天收到的所有新证书附加到日志中。然后,它计算整个日志的哈希值,并对哈希值和当前时间戳进行签名。日志数据和签名公开提供给任何人下载。

该体系结构的下一部分是一组审计程序,这些审计程序在世界各地运行,并确保证书日志的行为诚实—它们会按要求发布到日志中,并且永远不会从日志中删除数据。审核员每天都要下载所有最新日志及其签名,并检查是否没有从日志中删除任何证书。如果他们发现在t天的日志中缺少某天的证书,则来自t天和t +1天的日志签名可以证明该证书的日志行为不正确。

此外,每个审核员都在Internet上爬行以寻找证书。对于每个包含SCT扩展名的证书,审核员都会进行包含检查:它会验证该证书是否出现在SCT指向的日志的最新版本中。如果不是,则签名的SCT与签名的日志一起证明证书日志的行为异常。此过程可确保所有部署的带有SCT扩展名的证书都必须出现在其中一个日志中;否则,其中一个证书日志将被捕获为异常。任何人都可以运行审核程序协议。特别是,每个Web浏览器都可以选择充当审核员,并在选择信任证书之前运行包含检查。如果包含检查失败,浏览器会通知浏览器供应商,他们可以对所涉及的证书日志的做法进行调查。我们注意到,通过使用称为Merkle哈希树的数据结构,可以非常有效地完成包含检查,而不必下载整个日志。我们将在8.9节中讨论Merkle哈希树及其应用。

不幸的是,审计还不够。伪造的证书日志可能会以上述审核过程无法捕获的方式发生行为。假设CA根据需要为facebook.com颁发了恶意证书,并将其写入证书日志。现在,证书日志将创建日志的两个签名版本:一个带有流氓证书,另一个不带证书。审核员每次下载日志时,都会获得带有恶意证书的日志版本。对于审核员,一切似乎都很好。但是,当Facebook读取日志以查找流氓facebook.com证书时,将获得没有流氓证书的版本。即使所有审核员都认为该证书日志是诚实的,这也阻止了Facebook发现该恶意证书。该体系结构通过两种方式减轻了这种攻击。首先,每个证书都必须至少写入两个日志,以便两个证书日志都必须损坏才能使攻击成功。其次,存在一种广播机制,其中,将所有日志的每日哈希值广播到系统中的所有实体。与广播哈希不匹配的日志将被忽略。

该体系结构的最后一部分是强制所有CA上的证书透明性。将来的某个时候,浏览器供应商可能会决定拒绝来自受信任证书日志的所有没有有效SCT的证书。这将有效地迫使所有CA普遍采用证书透明性。届时,如果颁发了恶意证书,则将在其中一个证书日志中发现该证书并将其吊销。我们注意到,许多大型CA已经支持证书透明性。

13.8.2 Certificate revocation

接下来,我们来看吊销证书的问题。证书吊销的目的是确保在吊销证书后,所有客户端都将该证书视为无效。

有很多原因可能需要吊销证书。如上一节所述,证书可能是错误签发的。对应于证书的私钥可能已被盗,在这种情况下,证书所有者将要吊销该证书,因此不能被滥用。这事儿常常发生;网站被黑,其私钥被盗。一个广为人知的例子就是Heartbleed事件。 Heartbleed是OpenSSL库中的错误,该错误于2012年引入。该错误于2014年公开发现并修复,但是在这两年(从2012年到2014年)中,远程攻击者可以轻松地从每台使用过的服务器中提取密钥。 OpenSSL,只需将特定格式错误的请求发送到服务器即可。 2014年发现此漏洞时,由于担心相应的私钥被泄露,必须撤销成千上万的证书。

鉴于需要撤消证书,我们接下来介绍一些这样做的技术。

短期证书(Short-lived certificates)

请记住,每个证书都有一个有效期,并且该证书在其到期日期后不再有效。通常,当像Facebook这样的实体购买为期一年的证书时,CA会颁发证书,该证书在颁发后的一年内到期。想象一下,取而代之的是,CA生成了365份证书,其中每份证书在当年正好一天有效。所有365个证书都使用相同的公钥。唯一的区别是有效性窗口。这些证书称为短期证书,因为每个证书仅有效一天。

CA将所有这些证书保留给自己,并在有效之前最多每星期发布一次。因此,将于1月28日使用的证书将于1月21日提供,但不会更早。Facebook每天都连接到CA提供的公共站点,并获取一周后将要使用的证书。这是一个自动化的简单过程,如果出现任何问题,则需要整整一周的时间来解决问题。

现在,当Facebook需要吊销其证书时,它仅指示CA停止发布其域名的短期证书。这样有效地使被窃取的私钥在最多一个星期后变得无用。如果需要更快的撤销,则可以告诉CA仅在有效之前一个小时释放每个短期证书,在这种情况下,密钥在撤销之后最多25小时就变得无用。

短期证书的使用是可用的最简单,最实用的证书撤销技术,但尚未广泛使用。接下来的两种技术比较麻烦,但它们是CA最常使用的技术。

证书吊销列表(Certificate revocation lists (CRLs))

一种非常不同的方法是让CA收集其所有客户的所有证书吊销请求,并每周发布一份在该周内被吊销的所有证书的签名列表。此列表称为证书撤销列表(CRL),包含该周内被撤销的所有证书的序列号。该列表由CA签名。

每个证书都包含一个特殊的扩展字段,称为CRL分发点(CRL Distribution Points),如图13.6所示。该字段指示验证者从颁发CA的位置获取CRL。CA必须运行一个公用服务器,该公用服务器将这个列表提供给要求它的任何人。

当客户需要验证证书时,期望从CRL分发点下载CRL,如果其序列号出现在CRL中,则拒绝该证书。出于性能原因,CRL的有效期为一个星期,并且客户端可以在该期限内缓存CRL。结果,从发出吊销请求到所有客户得知证书已被撤销为止可能要花一周的时间。

这种方法有两个重大困难。首先,如果CRL服务器不响应CRL下载请求,客户端应该怎么做?如果客户要接受证书,那么这将引发非常严重的攻击。攻击者可以通过简单地阻止其与CRL服务器的连接来使客户端接受吊销的证书。显然,安全的做法是拒绝证书;但是,这也是有问题的。这意味着,如果Facebook的CA运行的CRL服务器意外崩溃,那么在CA修复CRL服务器之前,没有人可以连接到Facebook。您可以想象,Facebook不能很好地解决这一问题。

CRL的第二个困难是,它们迫使客户端下载客户端不需要的大量吊销证书。客户只对了解单个证书的有效性状态感兴趣:它正在尝试验证的证书。客户不需要,也不需要其他证书的状态。这种低效率可以通过称为OCSP的更好机制来解决,我们将在下面讨论。

在线证书状态协议(The online certificate status protocol (OCSP))

需要验证证书的客户端可以使用OCSP协议来查询CA有关该特定证书状态的信息。为了使这项工作有效,CA在证书中包括了OCSP扩展字段,如图13.6所示。该字段告诉客户端将OCSP查询发送到哪里。此外,CA必须设置一个称为 OCSP responder的服务器,该服务器响应来自客户端的OCSP查询。

当客户需要验证证书时,它将证书的序列号发送给OCSP响应者。粗略地说,响应者会发回一条签名的消息,说“有效”或“无效”。如果“无效”,则客户端拒绝该证书。 OCSP响应可以缓存一个星期,因此,撤消仅在发出请求后的一周内生效。

与CRL一样,当OCSP responder根本不响应时,不清楚客户端应该做什么。而且,OCSP引入了另一个问题。由于客户端(例如Web浏览器)将其遇到的每个证书的序列号发送给CA,因此CA可以有效地了解用户正在访问的网站。这违反了用户隐私。通过OCSP扩展(称为OCSP stapling)可以部分缓解此问题,但是很少使用此扩展。

本文分享自微信公众号 - 包罗万想(An-mind),作者:安包

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-01-07

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • GCAC22 6.11 PMAC: a parallel MAC

    原因是各个分组之间没有加入先后顺序。改变两个分组的顺序,不改变最后的标签的值。分组交换攻击。

    安包
  • SOCKS5

    SOCKS5 是一个代理协议,它在使用TCP/IP协议通讯的前端机器和服务器机器之间扮演一个中介角色,使得内部网中的前端机器变得能够访问Inte...

    安包
  • Dan Boneh密码学笔记4

    4.modes of operation: many time key (CBC)

    安包
  • 再见,旧证书:SSL/TLS证书寿命缩短至398天

    为了提高安全性,苹果、谷歌和Mozilla将拒绝在各自的浏览器中使用创建日期已超过13个月(或398天)的公开数字证书。

    FB客服
  • 部分APP无法代理抓包的原因及解决方法

    HTTP应用层的抓包已经成为日常工作测试与调试中的重要一环,最近接触新项目突然之间发现之前的抓包手段都不好使了,顿时模块与模块之间的前端与服务之间的交互都变成了...

    lulianqi
  • 商业证书颁发机构与自签名SSL证书之间的比较

    无论是公共网站,Intranet流量还是Web应用程序的登台服务器,您都需要一个证书来保护您的数据并满足用户的安全需求。

    一步
  • Cloudflare:让SSL重新变得“无聊”

    “ 随着免费和自动化的SSL证书被不断普及,钓鱼网站使用SSL证书的数量激增。这一事实一度成为业内最热门的争论话题之一,反对声连绵不断。 明年起,Let's E...

    企鹅号小编
  • 什么是SSL预证书?

    预验证是用作证书透明度(CT)一部分的特殊类型的SSL证书。 预先证书与常规SSL证书不同,因为它们不是(也不可以)用于验证服务器或形成经过身份验证的连接(例如...

    FB客服
  • HTTPS证书申请及windows server部署

    StartSSL免费DV证书 沃通(Wosign)免费DV证书 这两个已经被苹果拉入黑名单。我10月份在StartSSL申请的证书还可以使用。但是近期申请的已经...

    forrest23
  • HTTPS 证书有效期被提议缩短至13个月

    由 Web 浏览器制造商、软件开发人员和安全证书颁发机构组成的行业团体 CA/Browser Forum,正在考虑将 HTTPS 证书的有效期从 27 个月缩短...

    Debian社区

扫码关注云+社区

领取腾讯云代金券