《HTTPS权威指南》-公钥基础设施（PKI）学习笔记

握手中的身份验证的流程：

由《HTTPS权威指南》-协议学习笔记知道了握手协议中身份验证流程，这里再摘出一遍：
1、Client向Server say hello
2、Server将明文信息（包含publicKey_server）用协商的散列算法散列、编码然后用privateKey_server加密制作成了签名。将签名以及明文信息发送给Client。
3、Client用协商的散列算法计算明文的散列，使用publicKey_server解密服务器的签名，对比自己计算出的散列是否和服务器给的散列一致。从而实现服务器的身份验证。

这样做的危险：
危险1：
1、如果Attacker截获了Client的say hello，可以把publicKey_attacker返回给Client，取得Client的信任，至此Attacker与Client建立了安全连接。
2、Attacker冒充Client向Server发送say hello，至此Attacker与Server建立了安全连接。
3、这样，Client对Server发送的信息都被Attacker截获并解密了。
危险2：
1、服务器可以否认自己发送过的消息。

如何避免？
Client信任一些第三方权威机构（CA），然后由这些CA对Server的证书（包含了publicKey_Server）进行签名，Server提供这个被CA签名的证书给Client验证。
这样就形成了信任流：Client 信任 CA， CA信任Server，So Client信任Server。从而达到Server的身份验证。
PKI（public key infrastructure公钥基础设施）就是用来解决如何使用和验证证书的。当前使用的是基于可信的第三方机构，也就是证书颁发机构CA签发证书。

实现流程图：

屏幕快照 2016-12-21 09.53.21.png

所涉及到的新名词：

• 订阅人：需要证书来提供安全服务的团体（例如服务器）
• 登记机构（RA）：完成证书签发的相关管理工作，例如对订阅人身份验证，然后才会去找CA签发证书。
• CSR文件：订阅者的证书签名申请，主要目的是携带公钥信息，并且证明订阅人拥有对应的私钥（通过签名证明），CSR还设计携带额外的元数据，但实际中并非所有的都用到了，CA一般都会覆盖CRS文件中的一些内容并且将其他信息内置到证书里面。
• CA：我们都信任的证书颁发机构，它会在确定申请用户的身份之后签发证书
• 信赖方：执行证书验证的网页浏览器，其他程序及操作系统（例如iOS）
• CRL,OCSP：当出现私钥泄密或者不再需要使用时，就需要吊销证书，CRL和OCSP是两种吊销标准。
  • CRL（certificate revocation list,证书吊销列表）：是一组为过期但是却已经被吊销的列表，CA维护了一个或多个这样的列表，每一张证书需要在CRL分发点扩展中包含对应的CRL地址。CRL的最大问题在于它越来越大，实时查询起来会很慢
  • OCSP（online certificate status protocol，在线证书状态协议），支持实时查询

证书，中间CA证书，证书链，根证书

证书：包含公钥，订阅人相关信息，以及证书颁发者数字签名的数字文件。证书让我们可以交换，存储和使用公钥，是整个PKI体系的基础组成元素。

中间CA证书：根CA是非常重要的，如果根CA的密钥被泄漏了，那么就可以签发任意虚假证书，这时如果把根CA吊销掉，所有使用过这个CA签发的证书的网站都将无法访问。所以直接由根证书签发最终实体证书是不允许的。证书发行商们为了安全，通常会将这些根证书对应的私钥保存在绝对断网的金库里。在金库里用这些根私钥，签发一些“中级”证书，这些中级证书的私钥拥有签发再下一级证书的权限。这些中级私钥被安装到在线服务器上，通过签发网站证书来赚钱。一旦这些服务器被黑，发行商就可以利用金库里物理隔离的根证书私钥，可以签发吊销令，消灭这些中级证书的信任，而不必让各家浏览器彻底不信任这家发行商的根证书。再签一条新的中级发行证书，又是一条能赚钱的好汉。引自：SSL证书链不完整问题：中间证书果然是个坑。

根证书：根证书是CA给自己颁发的证书,是信任链的起始点。安装根证书意味着对这个CA认证中心的信任。

证书链：CA在验证成功之后就会签发证书。除了证书本身，CA还会提供所有的中间证书，从而构成了证书链到对应的根证书上。因为信赖方只保存着根证书，所以要通过证书链找到根证书来验证。

使用证书进行身份验证的流程

身份验证流程：
1、信赖方添加可信任根证书库，根证书库中保存着可信任的CA的根证书
例如Apple：
Apple维护的根证书库主要是给iOS和OSX平台使用，如果某个CA希望加入到Apple的根证书库里面的话，就需要通过权威机构审计并且对Apple的客户有商业价值。
2、证书订阅人找到信赖方所信赖的CA的登记机构，发送CSR，申请签名。
3、登记机构通过CA颁发给证书订阅人证书。
4、信赖方要求服务器进行身份验证。
5、服务器发送证书链给信赖方。
6、信赖方通过自己的根证书库对证书链进行验证（验证签名是否正确，检查证书是否已经吊销）。
7、握手流程中的身份验证结束，开始使用证书中的公钥进行密钥交换流程。

示例场景：
对于Client：
1、根CA有一个金库，保存着自己的私钥：privateKey_CA
2、根CA把自己的根证书（使用自己的私钥自签名证书）植入到Client中，根证书包含着：publicKey_CA
3、基于上面两个步骤，Client就可以验证根CA的签名了。
对于中间CA：
1、中间CA拥有根CA中的金库的私钥的签名（获取了根CA的信任），有派发子证书的权利。
对于Server：
1、Server将自己的CSR（包含publicKey_Server，但不包含privateKey_Server）给RA，RA审核后给中间CA，请求中间CA签名（相当于获取中间CA的信任）。
2、中间CA使用自己的私钥给Server的证书签名。
对于Client验证Server：
1、在Client要求验证Server身份时，Server将由中间CA签名的证书链发给Client。
2、Client可以从证书链寻找到根证书
3、Client从自己信任的根证书库中寻找对应的根证书来验证。
4、验证通过后，使用publicKey_Server来开始握手流程中的密钥交换。

参考文章：
ATS配置官方说明
苹果强制使用HTTPS传输后APP开发者必须知道的事
SSL证书链不完整问题：中间证书果然是个坑。
关于iOS9中的App Transport Security相关说明及适配(更新于2016.7.1)
腾讯云申请SSL证书
iOS使用自签名证书实现HTTPS请求
iOS 升级HTTPS通过ATS你所要知道的
AFNetworking之于https认证