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

最新推荐文章于 2024-09-02 18:04:06 发布

zhanyiwp

最新推荐文章于 2024-09-02 18:04:06 发布

阅读量2.2k

点赞数 1

分类专栏： TLS 文章标签： http https

本文链接：https://blog.csdn.net/zhanyiwp/article/details/105564954

版权

TLS 专栏收录该内容

5 篇文章 10 订阅

订阅专栏

一、为什么需要证书

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

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

这里的关键问题就是发送者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组织。

在PKI和CA的运营上非常专业。
需要设计一个健壮、安全、隔离的网络，以便在支持商业运作的同时，能够保护根证书以及二级证书密钥的安全。
支持证书生命周期管理流程。
符合Baseline Requirements的规定。
符合EV SSL证书指导规范。
提供全球化的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权威指南》