理解SSL/TLS系列 (三) 证书和PKI

一、为什么需要证书

在上一篇文章中我们谈到了数字签名，数字签名可以识别篡改或者发送者身份是否被伪装，也就是验证消息的完整性，还可以对消息进行认证。还可以防止抵赖。也谈到了数字签名无法抵御中间人攻击，那么什么是中间人攻击呢？

如图所示，攻击者位于发送者和接收者中间，对发送者伪装成接收者，对接收者伪装成发送者。以此来进行欺上瞒下。

 这里的关键问题就是发送者Alice没办法确认收到的公钥就是Bob的，我们需要有一种方式来完成这种认证，证书就是解决这个问题的一种方法。

二、什么是证书

公钥证书(Public-Key Certificate，PKC)记录着个人信息(姓名、组织、邮箱地址等个人信息)和个人公钥，并由证书颁发机构(Certification Authority、Certifying Authority，CA)施加数字签名。公钥证书也简称为证书(certificate)。由于我们信任证书颁发机构 (为什么要信任证书颁发机构？这其实是一个社会工程学问题了，就像为什么我们信任银行一样)，所以就可以信任证书。

三、什么是PKI

公钥基础设施(Public-Key Infrastructure)是为了能够更有效的运用公钥而制定的一系列规范和规格的总称。英文缩写PKI。PKI 是一个总称，并非指某一个单独的规范或规格。RSA 公司制定的 PKCS(Public-Key Cryptography Standards，公钥密码标准)系列规范也是 PKI 的一种，互联网规格 RFC(Request for Comments)也是 PKI 的一种，X.509 也是 PKI 的一种。每个公司编写的 API(Application Programming Interface，应用程序编程接口)和规格设计书也可以算是 PKI 的相关规格。

公钥基础设施 PKI 不能误解为“面向公众的权威认证机构只有一个”，“全世界的公钥都是由一个根 CA 来认证”。这些都是不正确理解。认证机构只要对公钥进行数字签名就可以了，所以任何人都可以成为认证机构。

PKI的组成要素

• 订阅人

订阅人(或者说最终实体)是指那些需要证书来提供安全服务的团体。

• 登记机构

登记机构(registration authority，RA)主要是完成一些证书签发的相关管理工作。例如， RA会首先对用户进行必要的身份验证，然后才会去找CA签发证书。在某些情况下，当 CA希望在用户附近建立一个分支机构时(例如在不同的国家建立当地登记中心)，我们 也称RA为本地登记机构(local registration authority，LRA)。实际上，很多CA也执行RA 的职责。

• 证书颁发机构

证书颁发机构(certification authority，CA)是指我们都信任的证书颁发机构，它会在确认申请用户的身份之后签发证书。同时CA会在线提供其所签发证书的最新吊销信息，这样信赖方就可以验证证书是否仍然有效。

• 信赖方

信赖方(relying party)是指那些证书使用者。技术上来说，一般是指那些执行证书验证的网页浏览器、其他程序以及操作系统。他们是通过维护根可信证书库来执行验证的， 这些证书库包含某些CA的最终可信证书(信任密钥，trust anchor)。更广泛地说，信赖方 是指那些需要通过证书在互联网上进行安全通信的最终用户。

证书颁发机构 

证书颁发机构(certification authority，CA)是当前互联网信任模型最重要的部分，他们可以签发任何域名的证书，所以是非常权威的。表面上看来似乎是一门稳赚的生意，前提是你的根证书要内置到尽可能多的设备中。那么具体需要做什么才能成为一个公开的CA?

•  建立CA组织。

1. 在PKI和CA的运营上非常专业。
2. 需要设计一个健壮、安全、隔离的网络，以便在支持商业运作的同时，能够保护根证书以及二级证书密钥的安全。
3. 支持证书生命周期管理流程。
4. 符合Baseline Requirements的规定。
5. 符合EV SSL证书指导规范。
6. 提供全球化的CRL和OCSP基础服务。

•  符合当地法律，这意味着可能需要按照当地的法规要求获取相应许可证。
• 通过根证书库认可的那些审计。
• 将你的根证书内置到尽可能多的设备、软件中。
• 找个已经内置的CA完成交叉证书，之后就可以开始运作了。

证书连

在大多数情况下，仅仅有最终实体证书是无法进行有效性验证的，所以在实践中，服务器需要提供证书链才能一步步地最终验证到可信根证书，如下图所示

交叉认证

交叉证书是可以让新的CA立即投入运营的唯一方式。因为想要在短期内让新的根证书部署得足够广泛是不可能的，所以新的CA都会找已经进行广泛内置的CA对他们的根密钥进行签名。随着时间的流逝，那些老的设备会逐渐淘汰掉，新的CA才能最终独立使用。

证书的申请和签发

CA会根据不同类型的证书申请，执行不同的验证流程。

• 域名验证

  域名验证(domain validated，DV)证书需要CA验证订阅人对域名的所有权之后才能进行签发。大多数情况下CA会发送一封确认邮件给域名的管理邮箱，管理员通过之后(按照邮件里面的步骤和链接)CA就会签发证书。如果无法通过邮件确认，那么CA通过别的通信手段(例如电话或者邮寄信件)或者合理的方式证明订阅人对域名的所有权之后就可以签发证书。签发IP地址证书的步骤也是类似的。

• 组织验证
  组织验证(organization validated，OV)证书会对身份和真实性进行验证。直到采用了 Baseline Requirements之后，OV证书的验证流程才标准化起来，但是在如何签发OV证书 以及如何将这些信息编码到证书中等方面，依旧存在很多前后不一致的情况。

• 扩展验证
  扩展验证(extended validation，EV)证书以更加严格的要求验证身份和真实性。它是为了解决OV证书缺乏的前后一致性而引入的，所以EV证书的验证流程非常详细，几乎不会出现前后不一致的情况。

  DV证书的签发是全自动的，所以非常快，它的签发时间主要取决于DNS管理员确认邮件所需的时间，而EV证书则相反，可能需要几天甚至几周才能拿到。

  攻击者有可能会向CA提交那些知名度高的域名的证书签名申请文件。因此CA需要具备一些高风险的域名列表，对于这类域名的证书申请采用人工方式进行验证，否则就拒绝签发证书。这也是Baseline Requirements里的规定。

  CA在验证成功之后就会签发证书。除了证书本身，CA还会提供所有的中间证书，从而构建证书链到对应的根证书上。

  在证书有效期范围内，申请者可以在他们的生产环境中使用该证书。如果证书对应的私钥泄露了，那么就需要吊销证书。

证书的吊销

当出现私钥泄露或者不再需要使用的时候，我们就需要吊销证书。 吊销协议和流程的设计是为了确保证书是有效的，否则就需要将吊销情况通知信赖方。现在有下面两种证书吊销标准。

• 证书吊销列表
  证书吊销列表(certificate revocation list，CRL)是一组未过期、但是却已经被吊销的证书序列号列表，CA维护了一个或多个这样的列表。每一张证书都需要在CRL分发点(CRL 4 distribution point)扩展中包含对应的CRL地址。CRL最大的问题在于它越来越大，实时查询起来会非常慢。

• 在线证书状态协议
  在线证书状态协议(online certificate status protocol，OCSP)允许信赖方获得一张证书的吊销信息。OCSP服务器通常称为OCSP响应程序，OCSP响应程序的地址编码在颁发机构信息访问(authority information access，AIA)证书扩展中。OCSP支持实时查询并且解决了CRL最大的缺点，但是并没有解决所有的吊销问题:因为OCSP的使用带来了性能、隐私方面的问题和新的漏洞。其中一部分问题可以通过OCSP stapling技术来解决，它允许服务器在TLS握手的过程中直接嵌入OCSP响应。

证书的弱点

未经域名所有者授权就可以签发证书

从原理上看，我们现在最大的问题是:任何CA都可以在未经域名所有者授权的情况下签发该域名的证书。这里关键的问题就是当前没有任何技术手段可以确保CA不会产生疏漏和安全过错。在只有几个CA的那个年代，这可能不是个问题，但是现在已经有了几百个 CA，这就成了一个大问题。如今整个PKI体系的安全级别等同于其中最薄弱的环节，而现在我们已经有了很多潜在的薄弱环节。所有的CA都需要经过审计，但是审计的质量同 样存疑。例如一家荷兰的CA公司DigiNotar，虽然经过审计，但是在2011年，其整个安全 体系依旧被完全入侵。 那么接下来的问题就是，我们能否信任CA可以做好他们自己的工作并且能够考虑公众利益?我们应该允许哪些CA有权利在缺少监督的情况下签发证书?有时候我们有正当的理 由去担心这些CA会将他们的商业利益置于我们的安全需求之上。例如，TrustWave在2012 年承认签发了一个二级CA用于流量审查，它会给任意网站签发伪造的证书。虽然 TrustWave是唯一公开承认签发这类证书的CA，但还有很多传言说这种情况并不少见。 很多人担心政府部门会滥用这个体系，伪造签发任意域名的证书。我们真的可以确定一 些CA后面没有政府的背景吗?即便真的没有，我们又如何确保他们不会被迫做政府要求的事情?唯一无法确认的是，不知道政府在商业CA中渗透得有多深。

缺少信任灵活度

还有一个理论上的问题是缺少信任灵活度。信赖方维护了包含一定数量CA证书的根证书库，这样CA要么是完全可信，要么完全不可信，没有中间情况。理论上，信赖方是可以从根证书库里移除CA的，但实际上，只有出现严重不称职或者安全泄露问题，或者CA 体量很小时，才会出现上面这种情况。一旦CA签发了大量的证书，就会出现大而不倒的情况。 某些象征性的惩罚还是有可能的。例如，过去有信赖方吊销过某些不称职CA的EV证书权限。另外一个想法(从未尝试过)就是，对于有过恶劣行为的CA，不再信任他们未来签 发的证书，只信任他们已经签发的证书。

弱域名验证

DV证书是通过不安全的WHOIS协议获取域名信息，然后基于域名所有者信息来签发证书 的。此外，验证过程经常是用邮件沟通，本身也是不安全的。如果攻击者劫持了域名或 者获得了关键邮箱的访问权限，那么要获得一张伪造的DV证书会非常容易。另外还可以通过窃听CA端的网络来攻击CA的验证过程。

吊销不生效

吊销不生效的情况比较普遍。首先在每个系统之间传播吊销信息会有延迟。Baseline Requirements允许CRL和OCSP的信息有效期最多可以是10天(中间证书则是12个月)。也就是说吊销信息的传播需要至少10天的时间。第二个问题是当前所有浏览器都已实现的软失败(soft-fail)策略;它们会尝试获取吊销信息但会忽略所有的失败。主动网络攻击者可以很容易地阻断OCSP请求，然后让其无限期地使用本已无效的证书。 浏览器厂商因此决定停止吊销检测。CRL首当其冲，紧接着是OCSP。

证书警告让加密意图完全失效

互联网PKI(准确说是Web PKI)最大的失败可能是证书验证的松散实现。很多库和应用完全绕过了验证过程。浏览器虽然会检测证书，但是当遇到无效证书时，它们却又允许用户忽略呈现给它们的警告信息。根据一些统计估计，大概有30%~70%的用户会点击跳过这些警告，这让我们的加密意图完全失效。有一种称为HTTP严格传输安全(HTTP strict transport security，HSTS)的新标准，它要求所有实现它的浏览器用错误替换警告，并且不允许忽略错误。

 参考

《图解密码技术》

《HTTPS权威指南》