一文详解 HTTPS 与 TLS证书链校验

向右看齐 2024-04-01 02:14 81阅读 0赞

前一段时间在看`X.509证书结构` 与 `TLS证书校验链`相关知识，到今天感觉基本了解清楚，想着写一篇文章记录学习心得。

在实际工作中，涉及到`X.509证书结构`与 `TLS证书校验链`的场景便是 `HTTPS` 网络请求。  
这篇文章从`HTTPS`网络请求开始，详细介绍`HTTPS秘钥协商`的详细流程、`TLS证书`的`校验`流程、`TLS证书链`的`校验`流程。

*  HTTPS  
    HTTPS简介。
 *  TLS握手  
    HTTPS秘钥协商流程详细说明。
 *  TLS证书 校验
 *  TLS证书链 校验

### 一、HTTPS简介 ###

`HTTPS` （Secure Hypertext Transfer Protocol）安全超文本传输协议，是一种通过计算机网络进行安全通信的传输协议。  
`HTTPS` 利用 `SSL/TLS` 来加密数据包，经由 `HTTP` 进行通信。  
其设计的主要目的是，提供对网站服务器的身份认证、保护交换数据的隐私与完整性。

![https][]

#### TLS/SSL ####

TLS 与 SSL某种程度上指的是同一个概念：

*  `SSL`（Secure Socket Layer） 1994年由 浏览器开发商`Netscape`（美国网景通信公司） 率先倡导研发，为数据通讯提供安全支持，开发了最初的几个版本SSL 1.0、SSL 2.0、SSL 3.0。
 *  `TLS`（Transport LayerSecurity）前身为SSL，1999年从 3.1 开始被 `IETF`（Internet Engineering Task Force，Internet 工程任务组）标准化并改名，发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。

`SSL3.0`、`TLS1.0`由于存在安全漏洞，已经很少被使用到。`TLS 1.3` 因改动会比较大，目前尚处在草案阶段。当前被广泛使用的是是`TLS 1.1`、`TLS 1.2`；

![3f9fa0c2bbb8457599655d93391abb94.png][]

如上图所示，`TLS/SSL`是介于TCP和HTTP之间的一层安全协议。

#### HTTP ####

`HTTP`（HyperText Transfer Protocol）超文本传输协议。  
`HTTP`是一个客户端（用户）和服务端之间请求和应答的标准，其最初的设计目的是为了提供一种发布和接收HTML页面的方法。

*注：Http协议不是本文重点，感兴趣的同学可参考文章：*  
[HTTP 协议详解：][HTTP]  
[一文详解 HTTP 协议\_bjxiaxueliang的博客-CSDN博客\_一文搞懂http协议][HTTP]

### 二、SSL/TLS 握手 ###

`SSL/TLS`握手过程 用一句话总结就是：用`非对称加密`的手段`传递密钥`，然后`用密钥`进行`对称加密传递`数据。  
`SSL/TLS`握手，秘钥协商的过程大致可分为以下几个步骤：

*  1、Client Hello  
    Client——>Server 客户端向服务端发送 Client Hello 消息。
 *  2、Server Hello  
    Server——>Client 服务端向客户端发送 Server Hello 消息。
 *  3、Certificate  
    Server——>Client 服务端下发`公钥证书`。
 *  4、Server Key Exchange  
    Server——>Client 服务端下发秘钥交换的额外数据。
 *  5、Server Hello Done  
    Server——>Client 服务端握手信息发送完毕。
 *  6、证书合法性校验  
    Client 对 Server下发的公钥证书进行合法性校验。
 *  7、协商加密秘钥  
    Client——>Server 协商计算客户端、服务端通信的`加密秘钥enc_key`。
 *  8、Change Cipher Spec Protocol  
    Server——>Client 服务端告知客户端后续的通信都采用协商的`秘钥enc_key`与`算法`进行加密通信。
 *  9、Encrypted Handshake Message  
    Server——>Client 服务端用`秘钥enc_key`加密，发出的第一条加密消息。
 *  10、Application Data  
    Client——>Server SSL/TLS 握手完成，所有后续通信均 采用`秘钥enc_key`加密。

`SSL/TLS`握手，秘钥协商的流程图 如下图所示：  
![SSL/TLS握手过程][SSL_TLS]

这里以`客户端`向`百度主页`发起`Https`请求为例，用 **Wireshark抓包** 对SSL/TLS握手的各个环节进行介绍，抓包示意图如下图所示：  
![Https请求百度主页WireShark抓包][Https_WireShark]

#### 2.1、Client Hello ####

**Client Hello（ Client——>Server ）：** 客户端向服务端发送 Client Hello 消息。  
消息中包含客户端的 `TSL版本信息`、`秘钥随机数`、`加密套件候选列表`、`压缩算法候选列表`、`扩展字段等信息`，相关信息抓包如下：

![Client Hello][]

各字段详细描述如下：

*  Version : 支持的最高TSL协议版本，从低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2；
 *  Random：随机数 `random_C` 用于后续的密钥协商;
 *  Session ID：有或者无，有则客户端传上一次session的id可以恢复session；
 *  Cipher Suite：客户端支持的密码算法列表，供服务器选择；
 *  Compression Methods：客户端支持的压缩算法列表，用于后续的信息压缩传输；
 *  extensions：扩展字段；

#### 2.2、Server Hello ####

**Server Hello（ Server——>Client ）：** 服务端向客户端发送 Server Hello 消息。  
消息中包括服务端选择使用的`TSL协议版本`、`选择的加密套件`、`选择的压缩算法`、`服务端生成的随机数`等，相关信息抓包如下：

![Server Hello][]

*  Version：服务器选择的版本；
 *  Random：随机数 `random_S` 用于后续的密钥协商;
 *  Session ID：有或者无，有则客户端传上一次session的id可以恢复session；
 *  Cipher Suite：服务端选择的密钥算法；
 *  Compression Methods：服务端选择的压缩算法；

*注：到此 客户端 和 服务端 都拥有了两个随机数（random\_C+ random\_S），这两个随机数会在后续生成对称秘钥时会用到。*

#### 2.3、Certificate ####

**Certificate（ Server——>Client ）：** 服务端下发`公钥证书`给客户端。相关信息抓包如下：

![Certificate][]

*  `Certificate:` 服务端的公钥证书；

*注：Certificate 公钥证书的详细结构会在下文进行详细举例说明。*

#### 2.4、Server Key Exchange ####

**Server Key Exchange（ Server——>Client ）:** 该消息的目的是 携带`密钥交换`的`额外数据`。

![Server Key Exchange][]

该消息内容对于不同的协商算法套件会存在差异：

*  对于使用DHE/ECDHE非对称密钥协商算法的SSL握手，服务器发送其使用的DH参数；
 *  RSA算法不会继续该握手流程（DH、ECDH也不会发送server key exchange）。

#### 2.5、Server Hello Done ####

**Server Hello Done（ Server——>Client ）:**  
通知`客户端`，Server端已经将所有握手消息发送完毕。

![Server Hello Done][]

#### 2.6、证书校验 ####

客户端拿到`服务端`的`公钥证书`后，需对该证书的合法性进行校验。校验内容如下：

*  证书链的可信性；
 *  证书是否吊销；
 *  证书有效期；
 *  证书域名校验，核查证书域名是否与当前的访问域名匹配;

*注：证书的详细校验过程将在下文进行详细介绍*

#### 2.7、协商加密秘钥 ####

**Client——>Server：** 这一步包含三个步骤，主要是 协商计算客户端、服务端通信的加密秘钥。

![协商加密秘钥][9833467f68bd140e97ac1355b20f1e51.png]

*  Client Key Exchange  
    证书合法性验证通过之后，客户端产生随机数字`Pre-master`。  
    计算生成秘钥`enc_key` \{ enc\_key=Fuc(random\_C, random\_S, Pre-Master) \} 。  
    将`Pre-master`与`enc_key`用`证书公钥加密`（非对称加密算法）发送给服务端;
 *  Change Cipher Spec Protocol  
    `客户端`通知`服务端`后续的通信都采用协商的`密钥enc_key`和`加密算法`进行加密通信;
 *  Encrypted Handshake Message  
    客户端：客户端将之前`所有的握手数据`（包括接受、发送）生成摘要；然后用`秘钥enc_key`加密（对称加密算法），发送给对应的服务端。  
    服务端：服务端收到消息后，会用`秘钥enc_key`解密`客户端的摘要信息`；然后用与客户端相同的算法生成`服务端摘要信息`，最后对比两个摘要信息相同，则验证通过。

#### 2.8、Change Cipher Spec Protocol ####

**Change Cipher Spec Protocol（ Server——>Client ）:** 服务器同样发送 Change Cipher Spec Protocol 以告知客户端后续的通信都采用协商的`秘钥enc_key`与`算法`进行加密通信;

![Change Cipher Spec Protocol][]

#### 2.9、Encrypted Handshake Message ####

**Encrypted Handshake Message（ Server——>Client ）：**  
服务端：服务端会将握手过程的消息生成摘要再用`秘钥enc_key`加密，这是服务端发出的第一条加密消息;  
客户端：客户端接收后会用`秘钥enc_key`解密，能解出来说明协商的秘钥是一致的。

![Encrypted Handshake Message][]

#### 2.10、Application Data （ Client——>Server ） ####

**Application Data Client——>Server ）：** 双方已安全地协商出了同一份`秘钥enc_key`，所有的应用层数据都会用这个秘钥加密后再通过 TCP 进行可靠传输。

![Application Data][]

#### 2.11 总结 ####

SSL/TLS握手协商：用`非对称加密`的手段`传递密钥`，然后`用密钥`进行`对称加密传递`数据。

### 三、证书校验 ###

这一节对前文 `2.6证书校验`提到的证书校验流程进行详细介绍：

*  1、X.509数字证书结构举例
 *  2、客户端 如何校验服务端下发的公钥证书？

#### 3.1、X.509数字证书 ####

了解证书校验原理之前，先认识一下X.509证书的结构。

`X.509`是密码学里`公钥证书`的`格式标准`，当前`X.509`证书已应用在包括`TLS/SSL`在内的众多网络协议里。  
一个具体的X.509 v3数字证书结构大致如下 :

// X.509数字证书
    Certificate
      // 版本号
      Version Number 
      // 序列号
      Serial Number 
      // 证书签名算法ID
      Signature Algorithm ID
      // 证书发行者
      Issuer Name
      // 证书有效时间
      Validity period
      // 证书主体名称
      Subject name
      // 证书主体公钥信息
      Subject Public Key Info
        // 证书公钥算法
        Public Key Algorithm
        // 证书公钥
        Subject Public Key
      // 发行商唯一ID
      Issuer Unique Identifier (optional)
      // 主体唯一ID
      Subject Unique Identifier (optional)
      // 扩展
      Extensions (optional)
    
    // 证书签名算法
    Certificate Signature Algorithm
    // 证书签名值
    Certificate Signature

这里以`百度`的`Tls证书`进行举例：  
![百度证书举例01][01]  
![百度证书举例02][02]

Certificate:
    	Data:
    	    Version: 3 (0x2)
    	    Serial Number:
    	        72:58:78:36:6e:9f:56:e8:1d:41:88:48
    	Signature Algorithm: sha256WithRSAEncryption
    	    Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2
    	    Validity
    	        Not Before: Apr  2 07:04:58 2020 GMT
    	        Not After : Jul 26 05:31:02 2021 GMT
    	    Subject: C=CN, ST=beijing, L=beijing, OU=service operation department, O=Beijing Baidu Netcom Science Technology Co., Ltd, CN=baidu.com
    	    Subject Public Key Info:
    	        Public Key Algorithm: rsaEncryption
    	            Public-Key: (2048 bit)
    	            Modulus:
    	                00:c1:a9:b0:ae:47:1a:d2:57:eb:1d:15:1f:6e:5c:
    	                b2:e4:f8:0b:20:db:ea:00:df:29:ff:a4:6b:89:26:
    	                4b:9f:23:2f:ec:57:b0:8a:b8:46:40:2a:7e:bc:dc:
    	                5a:45:97:4f:ad:41:0e:bc:20:86:4b:0c:5d:55:21:
    	                47:e2:31:3c:57:a7:ec:99:47:eb:47:0d:72:d7:c8:
    	                16:54:75:ef:d3:45:11:0f:4b:ce:60:7a:46:5c:28:
    	                74:ae:8e:1b:be:d8:70:66:7b:a8:93:49:28:d2:a3:
    	                76:94:55:de:7c:27:f2:0f:f7:98:0c:ad:86:da:c6:
    	                ae:fd:9f:f0:d9:81:32:9a:97:e3:21:ee:04:92:96:
    	                e4:78:11:e5:c4:10:0e:10:31:7a:4a:97:a0:eb:c7:
    	                9b:c4:da:89:37:a9:c3:37:d7:56:b1:7f:52:c7:d9:
    	                26:0a:d6:af:38:16:b1:6d:fb:73:79:b1:68:79:03:
    	                90:eb:88:7b:8c:48:91:98:51:a5:07:94:86:a5:78:
    	                46:79:8f:58:9b:e9:35:59:a7:f1:7b:57:31:0a:90:
    	                cf:24:ce:0d:24:e7:92:b2:6a:e9:e6:96:37:0a:b8:
    	                7c:87:2f:74:d2:5c:e8:4b:0a:5f:66:18:a7:41:86:
    	                cf:26:a6:08:8e:a5:49:17:92:53:b3:91:a5:cf:53:
    	                b0:31
    	            Exponent: 65537 (0x10001)
    	    X509v3 extensions:
    	        X509v3 Key Usage: critical
    	            Digital Signature, Key Encipherment
    	        Authority Information Access: 
    	            CA Issuers - URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt
    	            OCSP - URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2
    
    	        X509v3 Certificate Policies: 
    	            Policy: 1.3.6.1.4.1.4146.1.20
    	              CPS: https://www.globalsign.com/repository/
    	            Policy: 2.23.140.1.2.2
    
    	        X509v3 Basic Constraints: 
    	            CA:FALSE
    	        X509v3 CRL Distribution Points: 
    
    	            Full Name:
    	              URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl
    
    	        X509v3 Subject Alternative Name: 
    	            DNS:baidu.com, DNS:baifubao.com, DNS:www.baidu.cn, DNS:www.baidu.com.cn, DNS:mct.y.nuomi.com, DNS:apollo.auto, DNS:dwz.cn, DNS:*.baidu.com, DNS:*.baifubao.com, DNS:*.baidustatic.com, DNS:*.bdstatic.com, DNS:*.bdimg.com, DNS:*.hao123.com, DNS:*.nuomi.com, DNS:*.chuanke.com, DNS:*.trustgo.com, DNS:*.bce.baidu.com, DNS:*.eyun.baidu.com, DNS:*.map.baidu.com, DNS:*.mbd.baidu.com, DNS:*.fanyi.baidu.com, DNS:*.baidubce.com, DNS:*.mipcdn.com, DNS:*.news.baidu.com, DNS:*.baidupcs.com, DNS:*.aipage.com, DNS:*.aipage.cn, DNS:*.bcehost.com, DNS:*.safe.baidu.com, DNS:*.im.baidu.com, DNS:*.baiducontent.com, DNS:*.dlnel.com, DNS:*.dlnel.org, DNS:*.dueros.baidu.com, DNS:*.su.baidu.com, DNS:*.91.com, DNS:*.hao123.baidu.com, DNS:*.apollo.auto, DNS:*.xueshu.baidu.com, DNS:*.bj.baidubce.com, DNS:*.gz.baidubce.com, DNS:*.smartapps.cn, DNS:*.bdtjrcv.com, DNS:*.hao222.com, DNS:*.haokan.com, DNS:*.pae.baidu.com, DNS:*.vd.bdstatic.com, DNS:click.hm.baidu.com, DNS:log.hm.baidu.com, DNS:cm.pos.baidu.com, DNS:wn.pos.baidu.com, DNS:update.pan.baidu.com
    	        X509v3 Extended Key Usage: 
    	            TLS Web Server Authentication, TLS Web Client Authentication
    	        X509v3 Authority Key Identifier: 
    	            keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C
    
    	        X509v3 Subject Key Identifier: 
    	            ......

#### 3.2、证书校验 ####

客户端验证服务端下发的证书，主要包括以下几个方面：

*  1、校验证书是否是`受信任`的`CA根证书`颁发机构颁发；
 *  2、校验证书是否在上级证书的`吊销列表`；
 *  3、校验证书`是否过期`；
 *  4、校验证书`域名`是否`一致`。

3.2.1、证书可信性

校验证书是否可信：  
校验证书是否是由受信任的CA根证书颁发机构颁发。

为了确保`客户端`获取到的`服务端公钥`不被篡改，需引入权威的第三方CA机构。  
CA机构负责`核实`公钥`拥有者`信息、`颁发证书`(对服务端公钥进行签名)、同时为使用者`提供证书验证`服务。

![CA机构签发公钥与客户端验证][CA]

**CA机构 颁发证书的基本原理：**

*  `服务端`生成一对`公钥`、`私钥`。
 *  `服务端`将自己的公钥提供给`CA机构`。
 *  `CA机构`核实`服务端公钥`拥有者信息：  
    核实申请者提供信息的真实性：如组织是否存在、企业是否合法、是否拥有域名的所有权等。
 *  `CA机构`签发证书：  
    CA机构 计算 服务器`公钥摘要信息`，然后利用`CA机构私钥`（CA机构有一对公钥、私钥）加密`摘要信息`。  
    加密后的包含`加密摘要`信息的`服务端公钥`即`CA机构`颁发的`证书`。

**客户端 验证服务端公钥的基本原理为：**

*  `客户端`获取到服务端的`公钥`：  
    Https请求 TLS握手过程中，服务器公钥会下发到请求的客户端。
 *  `客户端`用存储在本地的`CA机构的公钥`，对 `服务端公钥`中对应的`摘要信息`进行解密，获取到`服务端公钥`的`摘要信息A`；
 *  `客户端`根据对`服务端公钥`进行摘要计算，得到`摘要信息B`；
 *  `对比`摘要信息`A与B`，相同则证书验证通过；

3.2.2、证书吊销

`CA机构`能够`签发证书`，同样也存在机制`宣布`以往签发的`证书无效`。若证书的申请主体出现：`私钥丢失`、`申请证书无效`等情况，CA机构需要废弃该证书。

主要存在两类机制：CRL 与 OCSP。

*  CRL（Certificate Revocation List）  
    证书吊销列表：是一个单独的文件，该文件包含了 CA机构 已经吊销的证书序列号与吊销日期；  
    证书中一般会包含一个 URL 地址 `CRL Distribution Point`，通知使用者去哪里下载对应的 CRL 以校验证书是否吊销。  
    该吊销方式的优点是不需要频繁更新，但是不能及时吊销证书，因为 CRL 更新时间一般是几天，这期间可能已经造成了极大损失。
 *  OCSP（Online Certificate Status Protocol）  
    证书状态在线查询协议：一个实时查询证书是否吊销的方式。  
    请求者发送证书的信息并请求查询，服务器返回正常、吊销或未知中的任何一个状态。  
    证书中一般也会包含一个 OCSP 的 URL 地址，要求查询服务器具有良好的性能。  
    部分 CA 或大部分的自签 CA (根证书)都是未提供 CRL 或 OCSP 地址的，对于吊销证书会是一件非常麻烦的事情。

3.2.3、证书过期

校验证书的有效期是否已经过期：主要判断证书中`Validity period`字段是否过期。

3.2.4、证书域名

校验证书域名是否一致：`核查` `证书域名`是否与当前的`访问域名` `匹配`。

举例中：  
我们请求的域名 www.baidu.com 是否与`证书文件`中`DNS标签`下所列的`域名`相`匹配`；

**一种错误的写法：**

Android 软件开发中，我们经常会遇到以下代码，用来忽略证书的域名验证，其实这是一种不安全的写法：

// 对于自签名证书，用以下代码来忽略证书的域名验证
    HostnameVerifier hostnameVerifier = new HostnameVerifier() {
        @Override
        public boolean verify(String urlHostName, SSLSession session) {
    		// 忽略证书的域名验证
            return true;
        }
    };

### 四、证书链校验 ###

上一节介绍证书校验场景，适用于`服务器证书`的签发机构就是`Ca机构`。  
实际证书申请中，由于权威的`CA机构`数量不多，若所有的`服务器证书`都向权威CA机构申请，那么CA机构的工作量就会非常大。因此CA机构采取`授权` `二级机构`的方式来管理证书申请，经`授权`的`二级机构`也可以签发`服务器证书`。

![证书链][5031a70ae2bfca63ec8612e63a1cf304.png]

#### 4.1、证书链校验 ####

证书签发：

*  `根证书`CA机构 使用自己的`私钥`对`中间证书`进行签名，授权`中间机构`证书；
 *  `中间机构`使用自己的`私钥`对`服务器证书`进行签名，从而授权`服务器证书`。

证书校验：

*  `客户端`通过`服务器证书` 中`签发机构信息`，获取到`中间证书公钥`；利用`中间证书公钥`进行`服务器证书`的签名验证。  
    a、中间证书公钥解密 服务器签名，得到证书摘要信息；  
    b、摘要算法计算 服务器证书 摘要信息；  
    c、然后对比两个摘要信息。
 *  `客户端`通过`中间证书`中`签发机构信息`，客户端本地查找到`根证书公钥`；利用`根证书公钥`进行`中间证书`的签名验证。

![证书链][1398b72880bb93ba3e67a81e6fffb63f.png]

#### 4.2、中间证书怎么获取？ ####

这里可能大家有一个疑问，根证书是内置在终端设备上或浏览器中的，那中间机构证书怎么获取？

这里仍以`百度`的`Tls证书`进行举例，百度`服务器证书` `签发者公钥`（中间机构公钥）通过下图中的URI获取：

![中间证书获取][63a1ac258a3f35576dd0401dfa49acb4.png]

#### 五、参考 ####

[TSL标准：][TSL]  
[RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2][TSL]

[X.509标准：][X.509]  
[RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile][X.509]

[SSL/TSL 原理：][SSL_TSL]  
[SSL/TSL 原理（ 握手原理和传输原理） - 左耳东白水泉 - 博客园][SSL_TSL]

[TLS/SSL握手过程：][TLS_SSL]  
[HTTPS协议详解(四)：TLS/SSL握手过程\_hherima的博客-CSDN博客][TLS_SSL]

[https]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/8dac2f26062d4afbaad1ab66b55632a2.png
[3f9fa0c2bbb8457599655d93391abb94.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/089b323bd4c64efeb55ccf6fad0b6e3c.png
[HTTP]: https://blog.csdn.net/xiaxl/article/details/104541274
[SSL_TLS]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/5809aa81cef24e268556797526a932eb.png
[Https_WireShark]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/41b6d248bb12478099c62ff85019a811.png
[Client Hello]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/b51f490a77e64f2a98c9a0cd90fa916d.png
[Server Hello]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/8d3fa1aaf3234d1bbcc797d6a42179a8.png
[Certificate]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/84bbb2b52d314e7a96169eefde5e209d.png
[Server Key Exchange]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/ed1b758e97fa4190beca5b7b43d5e399.png
[Server Hello Done]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/a75d6325ee3e40f1896703715beee61b.png
[9833467f68bd140e97ac1355b20f1e51.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/2633c2e1a0814d03bfe5075195f2c967.png
[Change Cipher Spec Protocol]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/2e7eb2717aec4c6abf6dea4f7ed71cae.png
[Encrypted Handshake Message]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/0c799dbfbb9744d4bafc99ab0eb248b0.png
[Application Data]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/729bf2436d704b9caca7327ffb3f64e5.png
[01]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/180a7291d9b64e9f897f90af93ec7f51.png
[02]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/f9a53388358540c580decc28738adc0d.png
[CA]: https://img-blog.csdn.net/20160908112422114
[5031a70ae2bfca63ec8612e63a1cf304.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/321c70f200554aa79a1eccf0132f094e.png
[1398b72880bb93ba3e67a81e6fffb63f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/80d0d02889b14b958dbeb61e80463757.png
[63a1ac258a3f35576dd0401dfa49acb4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/605a5e2d3ce34eefadf482505b6146af.png
[TSL]: https://tools.ietf.org/html/rfc5246
[X.509]: https://datatracker.ietf.org/doc/html/rfc5280
[SSL_TSL]: https://www.cnblogs.com/chenjingquan/p/10531305.html
[TLS_SSL]: https://blog.csdn.net/hherima/article/details/52469674