HTTPS加密过程和TLS证书验证

前言

大家都知道，苹果在2016年WWDC上宣布了关于应用需要强制使用HTTPS的规定。这也算是个好消息吧，虽然开发者们可能需要适配下HTTPS，但是我们的应用可算是披上一个安全的保护罩了。本篇文章就算是笔者在学习HTTPS过程中的一个记录吧。

HTTPS加密过程

最近重新了解了下HTTP和HTTPS: 首先二者都是网络传输协议;HTTPS在传输过程中是可以通过加密来保护数据安全的，以免用户敏感信息被第三方获取。 可以说HTTPS是HTTP的升级版、安全版。下面我们就简单看下HTTPS的加密过程，先看下图。

1. 客户端发起HTTPS请求 这个没什么好说的，就是用户在浏览器里输入一个HTTPS网址，然后连接到服务端的443端口。
2. 服务端的配置 采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥。如果对公钥不太理解，可以想象成一把钥匙和一个锁头，只是世界上只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。
3. 传送证书 这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。
4. 客户端解析证书 这部分工作是由客户端的SSL/TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警示框，提示证书存在的问题。如果证书没有问题，那么就生成一个***随机值***。然后用证书（也就是公钥）对这个随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。
5. 传送加密信息 这部分传送的是用证书加密后的随机值，目的是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
6. 服务端解密信息 服务端用私钥解密后，得到了客户端传过来的随机值，然后把内容通过该随机值进行对称加密，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。
7. 传输加密后的信息 这部分信息就是服务端用私钥加密后的信息，可以在客户端用随机值解密还原。
8. 客户端解密信息 客户端用之前生产的私钥解密服务端传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

到了这里，HTTPS的整个加密过程也就差不多完成了，但是这个过程中是不是还有些概念还是不太清楚，比如SSL是什么，TLS又是什么，他们是怎么验证我们的证书是否有效的呢，它们的验证策略又是怎样的呢。别急，下面我们就讨论下TLS。

TLS

刚开始听到TLS的时候，你可能还不太熟悉，但是说起SSL你可能就觉得好耳熟了。其实TLS就是从SSL发展而来的，只是SSL发展到3.0版本后改成了TLS。

TLS主要提供三个基本服务

• 加密
• 身份验证，也可以叫证书验证吧~
• 消息完整性校验

第三个是网络协议中常用的一个校验和机制，我这我们就先按下不表。

加密

我们再看一遍客户端和服务端之间的加密机制：

TLS协议是基于TCP协议之上的，图中第一个蓝色往返是TCP的握手过程，之后两次橙色的往返，我们可以叫做TLS的握手。握手过程如下：

1. client1：TLS版本号+所支持加密套件列表+希望使用的TLS选项
2. Server1:选择一个客户端的加密套件+自己的公钥+自己的证书+希望使用的TLS选项+（要求客户端证书）；
3. Client2:(自己的证书)+使用服务器公钥和协商的加密套件加密一个对称秘钥（自己生成的一个随机值）；
4. Server2:使用私钥解密出对称秘钥（随机值）后，发送加密的Finish消息，表明完成握手

这里可能要提一下什么是对称加密和非对称加密： 一般的对称加密像这样：

encrypt(明文，秘钥) = 密文
decrypt(密文，秘钥) = 明文
复制代码

也就是说加密和解密用的是同一个秘钥。而非对称加密是这样的：

encrypt(明文，公钥) = 密文
decrypt(密文，私钥) = 明文
复制代码

加密和解密是需要不同的秘钥的。

经过这几次握手成功后，客服端和服务端之间通信的加密算法和所需要的**也就确定下来了，之后双方的交互都可以使用对称加密算法加密了。

证书机制/证书验证

在TLS中，我们需要证书来保证你所访问的服务器是真实的，可信的。 看这张图我们来讨论下证书的验证过程。

1. 客户端获取到了站点证书，拿到了站点的公钥；
2. 要验证站点可信后，才能使用其公钥，因此客户端找到其站点证书颁发者的信息；
3. 站点证书的颁发者验证了服务端站点是可信的，但客户端依然不清楚该颁发者是否可信；
4. 再往上回溯，找到了认证了中间证书商的源头证书颁发者。由于源头的证书颁发者非常少，我们浏览器之前就认识了，因此可以认为根证书颁发者是可信的；
5. 一路倒推，证书颁发者可信，那么它所颁发的所有站点也是可信的，最终确定了我们所访问的服务端是可信的；
6. 客户端使用证书中的公钥，继续完成TLS的握手过程。

那么，客户端是是如何验证某个证书的有效性，或者验证策略是怎样的?

证书颁发者一般提供两种方式来验证证书的有效性： CRL 和 OCSP。

CRL

CRL（Certificate Revocation List）即 证书撤销名单。证书颁发者会提供一份已经失效证书的名单，供浏览器验证证书使用。当然这份名单是巨长无比的，浏览器不可能每次TLS都去下载，所以常用的做法是浏览器会缓存这份名单，定期做后台更新。这样虽然后台更新存在时间间隔，证书失效不实时，但一般也OK。

OCSP

OCSP(Online Certificate StatusProtocol)即 在线证书状态协议。除了离线文件，证书颁发者也会提供实时的查询接口，查询某个特定证书目前是否有效。实时查询的问题在于浏览器需要等待这个查询结束才能继续TLS握手，延迟会更大。

以上是站点在证书颁发者的角度说明会提供的两种判断方式，实际情况下浏览器究竟会选择哪种方式判断，每个浏览器都会有自己的实现。下面是通过Chrome查看GitHub网站的证书信息：

到这里差不多了，有什么不对的地方，欢迎大家留言指出，一起学习进步！

笔者不才，有些地方还是理解不到位，若有不正之处，还请耐心指出，轻喷~。

参看文章

• TLS如何保证安全
• 图解HTTPS协议加密解密全过程