HTTPS协议、TLS协议、证书认证过程解析

- 日理万妓 2022-01-12 02:51 786阅读 0赞

# #

### 一、HTTPS 协议 ###

HTTPS协议其实就是HTTP over TSL，TSL(Transport Layer Security) 传输层安全协议是https协议的核心。

TSL可以理解为SSL (Secure Socket Layer)安全套接字层的后续版本。

TSL握手协议如下图所示

![1244495-20171108204533294-1339745312.png][]

（注：图片来源于google图片）

在建立TCP连接后，开始建立TLS连接。下面抓包分析TLS握手过程，抓包图片来源于[传输层安全协议抓包分析之SSL/TLS][SSL_TLS] (自己没抓到这么完整的包，只能搬运过来了，摔)

(1) client端发起握手请求，会向服务器发送一个ClientHello消息，该消息包括其所支持的SSL/TLS版本、Cipher Suite加密算法列表（告知服务器自己支持哪些加密算法）、sessionID、随机数等内容。

![1244495-20171108210913731-381290333.png][]

(2) 服务器收到请求后会向client端发送ServerHello消息，其中包括：

SSL/TLS版本；

session ID，因为是首次连接会新生成一个session id发给client；

Cipher Suite，sever端从Client Hello消息中的Cipher Suite加密算法列表中选择使用的加密算法；

Radmon 随机数。

![1244495-20171108211404888-25605470.png][]

(3) 经过ServerHello消息确定TLS协议版本和选择加密算法之后，就可以开始发送证书给client端了。证书中包含公钥、签名、证书机构等信息。

![1244495-20171108212037372-893214258.png][]

(4) 服务器向client发送ServerKeyExchange消息，消息中包含了服务器这边的EC Diffie-Hellman算法相关参数。此消息一般只在选择使用DHE 和DH\_anon等加密算法组合时才会由服务器发出。

![1244495-20171108212528247-743481578.png][]

(5) server端发送ServerHelloDone消息，表明服务器端握手消息已经发送完成了。

![1244495-20171108212652544-470476594.png][]

(6) client端收到server发来的证书，会去验证证书，当认为证书可信之后，会向server发送ClientKeyExchange消息，消息中包含客户端这边的EC Diffie-Hellman算法相关参数，然后服务器和客户端都可根据接收到的对方参数和自身参数运算出Premaster secret，为生成会话密钥做准备。

![1244495-20171108212742997-638983083.png][]

(7) 此时client端和server端都可以根据之前通信内容计算出Master Secret（加密传输所使用的对称加密秘钥），client端通过发送此消息告知server端开始使用加密方式发送消息。

![1244495-20171108213240841-1040450792.png][]

(8) 客户端使用之前握手过程中获得的服务器随机数、客户端随机数、Premaster secret计算生成会话密钥master secret，然后使用该会话密钥加密之前所有收发握手消息的Hash和MAC值，发送给服务器，以验证加密通信是否可用。服务器将使用相同的方法生成相同的会话密钥以解密此消息，校验其中的Hash和MAC值。

![1244495-20171108213303466-1978167763.png][]

(9) 服务器发送ChangeCipherSpec消息，通知客户端此消息以后服务器会以加密方式发送数据。

![1244495-20171108213315263-1721933592.png][]

(10) sever端使用会话密钥加密（生成方式与客户端相同，使用握手过程中获得的服务器随机数、客户端随机数、Premaster secret计算生成）之前所有收发握手消息的Hash和MAC值，发送给客户端去校验。若客户端服务器都校验成功，握手阶段完成，双方将按照SSL记录协议的规范使用协商生成的会话密钥加密发送数据。

![1244495-20171108213325309-1347694901.png][]

### 二、session ID的复用 ###

根据[rfc5246][]，client和server建立TLS握手过程如下所示：

Client                                               Server
    
          ClientHello                  -------->
                                                          ServerHello
                                                         Certificate*
                                                   ServerKeyExchange*
                                                  CertificateRequest*
                                       <--------      ServerHelloDone
          Certificate*
          ClientKeyExchange
          CertificateVerify*
          [ChangeCipherSpec]
          Finished                     -------->
                                                   [ChangeCipherSpec]
                                       <--------             Finished
          Application Data             <------->     Application Data
    
                 Figure 1.  Message flow for a full handshake

* Indicates optional or situation-dependent messages that are not
       always sent.

client在向server发送ClientHello消息的时候，会传送Session ID给server端，server端收到session Id后会去session缓存中查找是否有相同值。如果找到相同值，则server直接发送一个具有相同session ID的ServerHello消息给client端（此时不必新建Session ID），然后双方各发一次ChangeCipherSpec消息后直接进入Finished消息互发阶段，具体如下图所示：

Client                                                Server
    
          ClientHello                   -------->
                                                           ServerHello
                                                    [ChangeCipherSpec]
                                        <--------             Finished
          [ChangeCipherSpec]
          Finished                      -------->
          Application Data              <------->     Application Data
    
              Figure 2.  Message flow for an abbreviated handshake

client和server通过缓存Session ID可以快速建立TLS握手，但是这么做也有一些弊端，例如：1）负载均衡中，多机之间往往没有同步 Session 信息，如果客户端两次请求没有落在同一台机器上就无法找到匹配的信息；2）服务端存储 Session ID 对应的信息不好控制失效时间，太短起不到作用，太长又占用服务端大量资源。而 Session Ticket（会话记录单）可以解决这些问题，Session Ticket 是用只有服务端知道的安全密钥加密过的会话信息，最终保存在浏览器端。浏览器如果在 ClientHello 时带上了 Session Ticket，只要服务器能成功解密就可以完成快速握手。

### 三、数字证书的验证 ###

client端收到server端发过来的证书，首先必须要做的事验证证书是否可信。如何验证证书是否可信呢？为了解决这个问题，我们先来了解下证书的组成

![1244495-20171108221111716-1100586299.png][]

从这里面我们能看到证书包含以下内容：

(1) Validity也即有效期，有效期包含生效时间和失效时间，是一个时间区间；

(2) 公钥信息Subject Public Key Info，包括公钥的加密算法和公钥内容；

(3) Fingerprints信息，fingerprints用于验证证书的完整性，也就是说确保证书没有被修改过。 其原理就是在发布证书时，发布者根据指纹算法(此处证书使用了SHA-1和SHA-256算法)计算整个证书的hash值(指纹)并和证书放在一起，client在打开证书时，自己也根据指纹算法计算一下证书的hash值(指纹)，如果和刚开始的值相同，则说明证书未被修改过；如果hash值不一致，则表明证书内容被篡改过；

(4) 证书的签名Certificate Signature Value和Certificate Signature Algorithm，对证书签名所使用的Hash算法和Hash值；

(5) 签发该证书的CA机构Issuer；

(6) 该证书是签发给哪个组织/公司信息Subject；

(7) 证书版本Version、证书序列号Serial Number以及Extensions扩展信息等。

![1244495-20171109201108247-971868063.png][]

如上图所示，为签名过程和client端验证过程。中间方框为一个数字证书，在制作数字证书时，会将证书中的部分内容进行一次Hash得到一个Hash值，然后证书认证机构简称CA会使用私钥将该Hash值加密为Certificate Signature。

当证书发送给Client端之后，Client端首先会使用同样的Hash算法获得一个证书的hash值H1。通常浏览器和操作系统中集成了CA机构的公钥信息，浏览器收到证书后可以使用这些公钥解密Certificate Signature内容，得到一个hash值H2。

比较H1和H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。

自己通过openssl生成的自签发证书只是使用自己的私钥去加密上图左侧计算出的Hash Value，这个时候client端得到server端发过来的证书之后，仍然会尝试使用浏览器或系统内置的CA机构的公钥去解密，解密出来的hash值H2当然不可能与H1相同，因此浏览器认为该证书不受信任。但是如果我们选择相信该证书并且继续访问该web，访问并不会出现任何问题，这是因为证书中的公钥并未加密，使用该公钥也确实能和server端的私钥进行TLS握手。

### 四、证书信任链 ###

在证书认证过程中还存在一个证书信任链的问题，因为我们从CA机构申请到的证书基本不可能是根证书签发。还是以百度的证书为例，如下图所示，百度证书层级为三层，认证过程如下：

![1244495-20171109202015216-514052730.png][]

(1) 当client端访问baidu.com的时候，baidu的server会将baidu.com证书发送给client端。

(2) client端的操作系统或者浏览器中内置了根证书，但是client端收到baidu.com这个证书后，发现这个证书不是根证书签发，无法根据本地已有的根证书中的公钥去验证baidu.com证书是否可信。

于是client端根据baidu.com证书中的Issuer找到该证书的颁发机构GlobalSign Organization Validation CA - SHA256 - G2，去CA请求baidu.com证书的颁发机构GlobalSign Organization Validation CA - SHA256 - G2的证书。

(3) 请求到证书后发现GlobalSign Organization Validation CA - SHA256 - G2证书是由根证书签发，而本地刚好有根证书，于是可以利用根证书中的公钥去验证（验证方法见上一节）GlobalSign Organization Validation CA - SHA256 - G2证书，发现验证通过，于是信任GlobalSign Organization Validation CA - SHA256 - G2证书。

(4) GlobalSign Organization Validation CA - SHA256 - G2证书被信任后，可以使用GlobalSign Organization Validation CA - SHA256 - G2证书中的公钥去验证baidu.com证书的可信性。验证通过，于是信任baidu.com证书。

在这四个步骤中，最开始client端只信任根证书GlobalSign Root CA证书的，然后GlobalSign Root CA证书信任GlobalSign Organization Validation CA - SHA256 - G2证书，而GlobalSign Organization Validation CA - SHA256 - G2证书又信任baidu.com证书，于是client端也信任baidu.com证书。这样的一个过程就构成了一条信任链路，整个证书信任链验证流程如下图所示。

![1244495-20171109204708278-1042248741.png][]

### 五、非对称加解密 ###

非对称加密包含一个密钥对：公钥和私钥。公钥可以公开，私钥必须安全保存。

![1244495-20171109093358122-1780177389.png][]

如上图所示，数据可以被公钥加密，加密后的数据只有持有私钥才能进行解密。同理私钥加密的数据，也只有对应的公钥才能解密。

建立HTTPS连接以后，client（浏览器）已经获得server段的公钥，并且经过TLS协议在握手过程中协商出一个只有双方知道的**对称密钥**，在后续的数据传输过程中都将使用该密钥进行数据加密传输。因为公钥是公开的，可以下发给所有client端的，这个时候即使其他拥有公钥的client端截获到server端发给client端的消息，也无法仅仅凭借公钥去解密这个消息，因为这个消息加密密钥是由client和server通过相同算法计算出来，并且添加了随机数，理论上这个对称密钥只有client和server才能知道。

参考文档：

https://tools.ietf.org/html/rfc5246\#page-6

http://www.freebuf.com/articles/network/116497.html

https://imququ.com/post/optimize-tls-handshake.html

http://blog.csdn.net/wzzvictory/article/details/9015155

[1244495-20171108204533294-1339745312.png]: /images/20220109/d050f5d4fac244009b1ac8b2960233ab.png
[SSL_TLS]: http://www.freebuf.com/articles/network/116497.html
[1244495-20171108210913731-381290333.png]: /images/20220109/367b12fe562a4764b8f57254dc536bd4.png
[1244495-20171108211404888-25605470.png]: /images/20220109/17560e3a5dd34c95a35df2425deb7ea7.png
[1244495-20171108212037372-893214258.png]: /images/20220109/dc068f9e5a864770b8ca42d78354d97b.png
[1244495-20171108212528247-743481578.png]: /images/20220109/e8e267a13f0d48389b49644885de04d3.png
[1244495-20171108212652544-470476594.png]: /images/20220109/d2df402ff9914b3d9a1e2b66c16d6122.png
[1244495-20171108212742997-638983083.png]: /images/20220109/b4b4ec45933742ff9caf528306dcebee.png
[1244495-20171108213240841-1040450792.png]: /images/20220109/cd0d719616964fe99094448efd948748.png
[1244495-20171108213303466-1978167763.png]: /images/20220109/00971922ee194ef3be405e7dfce3e789.png
[1244495-20171108213315263-1721933592.png]: /images/20220109/141a9ec1fa5d4319bf9815be3c0e9ae2.png
[1244495-20171108213325309-1347694901.png]: /images/20220109/a0e97f4b37d44d5a8be7121644c9d1e5.png
[rfc5246]: https://tools.ietf.org/html/rfc5246
[1244495-20171108221111716-1100586299.png]: /images/20220109/5f4245469444404d90782707b489a294.png
[1244495-20171109201108247-971868063.png]: /images/20220109/e8a5d172107946329f33f6bb41c467ea.png
[1244495-20171109202015216-514052730.png]: /images/20220109/ebe7f644360945cfb2a5c95427b64e69.png
[1244495-20171109204708278-1042248741.png]: /images/20220109/c5498f26b84445f989beb70c0fb6a37e.png
[1244495-20171109093358122-1780177389.png]: /images/20220109/5cb7efbaafbe4ca59c8ff00946ca63cb.png