iOS-HTTPS 温故知新（一） — 开篇

清疚 2023-10-18 14:28 242阅读 0赞

**一、为什么需要 HTTPS**

HTTP1.1 有以下安全性问题：

1.  使用明文(不加密)进行通信，内容可能会被窃听；
2.  不验证通信方的身份，通信方的身份有可能遭遇伪装；
3.  无法证明报文的完整性，报文有可能遭篡改。

由于 HTTP 设计之初没有考虑到这几点，所以基于 HTTP 的这些应用都会存在安全问题。

**1. 数据没有加密**

基于 TCP/IP 的网络，网络各处都会存在被监听的风险。而且如果用 HTTP 协议进行通信，HTTP 本身没有加密功能，所以也无法做到对通信整体(使用 HTTP 协议通信的请求和响应的内容)进行加密。即，HTTP 报文使用明文(指未经过加密的报文)方式发送。

![image.png][]

像上图表示的那样，在互联网各个环节都可能被监听。就算是加密通信，也能被监听到通信内容，只不过监听者看到的是密文。要解决 HTTP 上面 3 个大的安全问题，第一步就是要先进行加密通信。于是在传输层增加了一层 SSL（Secure Sockets Layer 安全套接层）/ TLS (Transport Layer Security 安全层传输协议) 来加密 HTTP 的通信内容。

HTTPS (HTTP Secure) 并不是新协议，而是 HTTP 先和 SSL（Secure Sockets Layer 安全套接层）/ TLS (Transport Layer Security 安全层传输协议) 通信，再由 SSL/TLS 和 TCP 通信。也就是说 HTTPS 使用了隧道进行通信。

这个时候可能有同学会有疑问了，为什么不直接对 HTTP 报文进行加密，这样就不需要 SSL/TLS 这一层了。确实，如果直接对 HTTP 报文进行加密也可以做到加密通信，但是虽然解决了第一条，但是后面 2 条就不好解决了。

![image.png][image.png 1]

就算直接对 HTTP 进行加密，HTTP 头部也没有加密，而头部信息也会导致信息不安全。

**2. 无法验证通信对方的身份**

基于 TCP 的 HTTP 虽然可以保证数据能完整的传输给对方，但是无法验证通信对方的身份。HTTP 也由于协议的灵活性，应用的非常广泛。通信的双方无须验证身份，服务器只要接收到能识别的请求，就会返回一个响应，一个 request 就一定会有一个 response。由于不确认通信对方，就会导致一些隐患：

服务器无法验证请求来自谁，是否是合法的客户端。

客户端收到响应，也无法验证是否是来自合法的服务器。

无法阻止海量请求下的 Dos 拒绝攻击（Denial of Service，拒绝服务攻击）

**3. 无法防止数据被篡改**

HTTP 协议是无法保证数据的完整性的。所谓完整性指的是信息的准确度。若无法证明信息的完整性，也就意味着无法判断信息是否准确。

客户端和服务端面对收到的响应和请求，都只能无条件接受，HTTP 也无法知道请求或响应在传输过程中是否已经被篡改了，例如遭到了中间人攻击(Man-in-the-Middle attack，MITM)。

HTTP 也有可以验证报文完整性的方法，但是还是不可靠。比如利用 MD5 和 SHA-1 等散列值校验的方法，用来确认文件的数字签名。（MD5 和 SHA-1 低位数的已经不再安全了，会遭到碰撞攻击，这个之后的文章再细致分析）

有下载服务的 Web 网站也会提供 PGP (Pretty Good Privacy，完美隐私)创建的数字签名及 MD5 算法生成的散列值。PGP 用来证明创建文件的数字签名，MD5 是由单向函数生成的散列值。在 HTTP 的协议下，浏览器是无法知晓数据被篡改了，还是需要用户自己查看。但是如果 PGP 和 MD5 在传输前就被篡改了，用户拿到以后验证对比发现是一致的，这种情况也没法保证数据的完整正确性。

![image.png][image.png 2]

通过使用 SSL，HTTPS 不仅能保证密文传输，重要的是还可以做到验证通信方的身份，保证报文的完整性。完美的解决了 HTTP 在安全性上的三大缺陷。

**二、部署 HTTPS 有何好处**

![image.png][image.png 3]

可能读者有这样的疑惑，除去电商，金融，和钱打交道以外的网站必须要部署 HTTPS，其他的网站用不用 HTTPS 无所谓。笔者之前也有类似的想法，不过这个想法是错误的。

电商，金融，和钱打交道以外的网站必须要部署 HTTPS，这个毫无疑问，是为了防止用户金钱上的损失，但是其他的网站呢？如果不部署 HTTPS，用裸的 HTTP，很容易遭到劫持，包括可能会被 ISP 插入小广告。小广告非常影响用户体验，如果是黄色广告，还会影响用户对这个网站的印象。另外用户浏览了哪些页面，用户行为也很容易被分析出来，这种也算是泄露了用户的隐私。

部署 HTTPS 有以下的好处：

**1. 使用 HTTP/2 获得更高的性能**

内容交付网络和网络托管服务提供商正在开始推广 HTTP/2。在 Velocity 的一次会议上，Load Impact 和 Mozilla 报告说，互联网用户可以通过 HTTP/2 优化比 HTTP/1.1 上的网站性能要好 50-70％。但是想用 HTTP/2 的性能优势，必须要先部署 HTTPS，这个规定也算是对 HTTPS 的一个推广。

**2. 提高 SEO 排名**

谷歌在 2014 年宣布，支持 HTTPS 的网站将会有排名靠前的较大权重。

**3. 更好的推荐数据**

如果采用了谷歌的 Analytics 库，它目前是强制运行在 HTTPS 上的，如果还是使用 HTTP，会由于 Analytics 不会获取 HTTP 网站的 Referral 信息而导致数据不准确。

**4. 更高的安全性**

主流浏览器现在都会针对 HTTPS 网站增加小绿锁标志，没有小绿锁的网站，对用户第一印象就不会很好。

**5. 提高网站的信任和信誉**

Chrome 62 版本以后，如果网页有输入框，没有 HTTPS 的网页一律都显示为不安全。

**6. HTLM5 新特性**

在 Chrome 50版本以后，地理位置，音频视频接口必须要求运行在 HTTPS 上，目的是为了能保证数据传输安全。

**7. iOS ATS 要求**

苹果为了推广HTTPS，在 WWDC 2017 上也宣布新的 App 必须要开启 APS (App Transport Security)安全特性。

**三、HTTPS 中的密码学**

**1. 对称密钥加密**

对称密钥加密（Symmetric-Key Encryption），加密的加密和解密使用同一密钥。

*  优点：运算速度快；
 *  缺点：密钥容易被获取。

![image.png][image.png 4]

> 关于对称加密更加详细的内容，可以看笔者之前写的 [《漫游对称加密算法》][Link 1]

**2. 公开密钥加密**

公开密钥加密（Public-Key Encryption），也称为非对称密钥加密，使用一对密钥用于加密和解密，分别为公开密钥和私有密钥。公开密钥所有人都可以获得，通信发送方获得接收方的公开密钥之后，就可以使用公开密钥进行加密，接收方收到通信内容后使用私有密钥解密。

*  优点：更为安全；
 *  缺点：运算速度慢；

![image.png][image.png 5]

> 关于公开密钥加密更加详细的内容，可以看笔者之前写的 [《翱游公钥密码算法》][Link 2]

**3. HTTPS 采用的加密方式**

HTTPS 采用混合的加密机制，使用公开密钥加密用于传输对称密钥，之后使用对称密钥加密进行通信。（下图中的 Session Key 就是对称密钥）

**![68747470733a2f2f696d672e68616c66726f73742e636f6d2f426c6f672f41727469636c65496d6167652f39355f382e706e67.png][]4. 认证**

HTTPS 通过使用 证书 来对通信方进行认证。

数字证书认证机构（CA，Certificate Authority）是客户端与服务器双方都可信赖的第三方机构。服务器的运营人员向 CA 提出公开密钥的申请，CA 在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公开密钥证书后绑定在一起。

进行 HTTPS 通信时，服务器会把证书发送给客户端，客户端取得其中的公开密钥之后，先进行验证，如果验证通过，就可以开始通信。

![image.png][image.png 6]

> 关于证书更加详细的内容，可以看笔者之前写的 [《随处可见的公钥证书》][Link 3]

使用 OpenSSL 这套开源程序，每个人都可以构建一套属于自己的认证机构，从而自己给自己颁发服务器证书。浏览器在访问该服务器时，会显示“无法确认连接安全性”或“该网站的安全证书存在问题”等警告消息。

**5. 完整性**

TLS / SSL 提供报文摘要功能来验证完整性。

**四、HTTPS 中的 TLS / SSL 协议**

![image.png][image.png 7]

能让 HTTPS 带来安全性的是其背后的 TLS 协议。它源于九十年代中期在 Netscape 上开发的称为安全套接字层(SSL)的协议。到 20 世纪 90 年代末，Netscape 将 SSL 移交给了 IETF，IETF 将其重命名为 TLS，并从此成为该协议的管理者。许多人仍将 Web 加密称作 SSL，即使绝大多数服务已切换到仅支持 TLS。

![image.png][image.png 8]

*  1995: SSL 2.0. 由 Netscape 提出，这个版本由于设计缺陷，并不安全，很快被发现有严重漏洞，已经废弃。
 *  1996: SSL 3.0. 写成 RFC，开始流行。目前（2015年）已经不安全，必须禁用。
 *  1999: TLS 1.0. 互联网标准化组织 ISOC 接替 NetScape 公司，发布了 SSL 的升级版 TLS 1.0 版。
 *  2006: TLS 1.1. 作为 RFC 4346 发布。主要 fix 了 CBC 模式相关的如 BEAST 攻击等漏洞。
 *  2008: TLS 1.2. 作为 RFC 5246 发布。增进安全性。目前（2015 年）应该主要部署的版本，请确保你使用的是这个版本。
 *  2018：8月10日 RFC8446 TLS 1.3 协议正式发布，它剔除了 TLS 1.2 协议中不安全的因素，极大地增强了协议的安全性和性能。

在 IETF 中，协议被称为 RFC。TLS 1.0 是 RFC 2246，TLS 1.1 是 RFC 4346，TLS 1.2 是 RFC 5246。现在，TLS 1.3 为 RFC 8446。从 TLS 1.2 到 TLS 1.3，前前后后花了快 10 年的时间。RFC 通常按顺序发布，TLS 正式规范都是以 46 作为 RFC 编号的一部分更像是计划好的，并非巧合。

TLS/SSL 协议位于应用层和传输层 TCP 协议之间。TLS 粗略的划分又可以分为 2 层：

*  靠近应用层的握手协议 TLS Handshaking Protocols
 *  靠近 TCP 的记录层协议 TLS Record Protocol

TLS 握手协议还能细分为 5 个子协议：

*  change\_cipher\_spec (在 TLS 1.3 中这个协议已经删除，为了兼容 TLS 老版本，可能还会存在)
 *  alert
 *  handshake
 *  application\_data
 *  heartbeat (这个是 TLS 1.3 新加的，TLS 1.3 之前的版本没有这个协议)

这些子协议之间的关系可以用下图来表示：

![image.png][image.png 9]

**1. TLS 记录层协议**

记录层将上层的信息块分段为 TLSPlaintext 记录，TLSPlaintext 中包含 2^14 字节或更少字节块的数据。根据底层 ContentType 的不同，消息边界的处理方式也不同。TLS 1.3 中的规则比 TLS 1.2 中强制执行的规则更加严格。

*  握手消息可以合并为单个 TLSPlaintext 记录，或者在几个记录中分段，前提是：
 *  握手消息不得与其他记录类型交错。也就是说，如果握手消息被分成两个或多个记录，则它们之间不能有任何其他记录。

握手消息绝不能跨越密钥更改。实现方必须验证密钥更改之前的所有消息是否与记录边界对齐; 如果没有，那么他们必须用 "unexpected\_message" alert 消息终止连接。因为 ClientHello，EndOfEarlyData，ServerHello，Finished 和 KeyUpdate 消息可以在密钥更改之前立即发生，所以实现方必须将这些消息与记录边界对齐。

实现方绝不能发送握手类型的零长度片段，即使这些片段包含填充。

另外 Alert 消息禁止在记录之间进行分段，并且多条 alert 消息不得合并为单个 TLSPlaintext 记录。换句话说，具有 alert 类型的记录必须只包含一条消息。

应用数据消息包含对 TLS 不透明的数据。应用数据消息始终应该受到保护。可以发送应用数据的零长度片段，因为它们可能作为流量分析对策使用。应用数据片段可以拆分为多个记录，也可以合并为一个记录。

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 </td> 
 <td> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>struct&nbsp;{ </code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>ContentType&nbsp;type;</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>ProtocolVersion&nbsp;legacy_record_version;</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>uint16&nbsp;length;</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>opaque&nbsp;fragment[TLSPlaintext.length];</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>}&nbsp;TLSPlaintext;</code> </td> 
 </tr> 
 </tbody> 
</table>

![image.png][image.png 10]

type:

用于处理 TLS 握手层的高级协议。

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 </td> 
 <td> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>enum&nbsp;{ </code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>invalid(</code><code>0</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>change_cipher_spec(</code><code>20</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>alert(</code><code>21</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>handshake(</code><code>22</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>application_data(</code><code>23</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>heartbeat(</code><code>24</code><code>),&nbsp;&nbsp;</code><code>/*&nbsp;RFC&nbsp;6520&nbsp;*/</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>(</code><code>255</code><code>)</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>}&nbsp;ContentType;</code> </td> 
 </tr> 
 </tbody> 
</table>

ContentType 是对握手协议的封装，消息头类型和握手层子协议编号的对应关系如下：

![image.png][image.png 11]

*  legacy\_record\_version:
    
    对于除初始 ClientHello 之外的 TLS 1.3 实现生成的所有记录(即，在 HelloRetryRequest 之后未生成的记录)，必须将其设置为 0x0303，其中出于兼容性目的，它也可以是0x0301。该字段在 TLS 1.3 中已经弃用，必须忽略它。在某些情况下，以前版本的 TLS 将在此字段中使用其他值。

在 TLS 1.3 中，version 为 0x0304，过去版本与 version 的对应关系如下：

![image.png][image.png 12]

*  length:
    
    TLSPlaintext.fragment 的长度(以字节为单位)。长度不得超过 2 ^ 14 字节。接收超过此长度的记录的端点必须使用 "record\_overflow" alert 消息终止连接。
 *  fragment:
    
    正在传输的数据。此字段的值是透明的，它并被视为一个独立的块，由类型字段指定的更高级别协议处理。

当尚未使用密码保护时，TLSPlaintext 结构是直接写入传输线路中的。一旦记录保护开始，TLSPlaintext 记录将受到密码保护。请注意，应用数据记录不得写入未受保护的连接中。所以在握手成功之前，是不能发送应用数据的。

TLS 记录层协议在整个 TLS 协议中的定位如下：

*  封装处理 TLS 上层(握手层)中的平行子协议(TLS 1.3 中是 5 个子协议，TLS 1.2 及更老的版本是 4 个子协议)，加上消息头，打包往下传递给 TCP 处理。
 *  对上层应用数据协议进行密码保护，对其他的子协议只是简单封装(即不加密)

> 关于 TLS 记录层协议更多细节将在接下来的文章中详细分析。也会对 TLS 1.2 和 TLS 1.3 展开对比。

**2. TLS 密码切换协议**

> 注意：该协议在 TLS 1.3 标准规范中已经删除，但是实际使用中为了兼容 TLS 老版本和一些消息中间件，所以实际传输中还可能用到这个协议。

change\_cipher\_spec (以下简称 CCS 协议) 协议，是 TLS 记录层对应用数据是否进行加密的分界线。客户端或者服务端一旦收到对端发来的 CCS 协议，就表明接下来传输数据过程中可以对应用数据协议进行加密了。

TLS 记录层在处理上层 5 个协议(密码切换协议，警告协议，握手协议，心跳协议，应用数据协议)的时候，TLS 不同版本对不同协议加密的情况不同，具体情况如下：

![image.png][image.png 13]

> 关于 TLS CCS 协议更多细节将在接下来的握手文章中详细分析。也会对 TLS 1.2 和 TLS 1.3 展开对比。

协议数据结构如下：

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 </td> 
 <td> <code>&nbsp;&nbsp;&nbsp;</code><code>struct&nbsp;{ </code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>enum&nbsp;{&nbsp;change_cipher_spec(</code><code>1</code><code>),&nbsp;(</code><code>255</code><code>)&nbsp;}&nbsp;type;</code> <code>&nbsp;&nbsp;&nbsp;</code><code>}&nbsp;ChangeCipherSpec;</code> </td> 
 </tr> 
 </tbody> 
</table>

经过 TLS 记录层包装以后，结构如下:

![image.png][image.png 14]

**3. TLS 警告协议**

TLS 提供 alert 内容类型用来表示关闭信息和错误。与其他消息一样，alert 消息也会根据当前连接状态的进行加密。在 TLS 1.3 中，错误的严重性隐含在正在发送的警报类型中，并且可以安全地忽略 "level" 字段。"close\_notify" alert 用于表示连接从一个方向开始有序的关闭。收到这样的警报后，TLS 实现方应该表明应用程序的数据结束。

收到错误警报后，TLS 实现方应该向应用程序表示出现了错误，并且不允许在连接上发送或接收任何其他数据。

协议数据结构如下：

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 </td> 
 <td> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>enum&nbsp;{&nbsp;warning(</code><code>1</code><code>),&nbsp;fatal(</code><code>2</code><code>),&nbsp;(</code><code>255</code><code>)&nbsp;}&nbsp;AlertLevel;</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code>&nbsp; <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>struct&nbsp;{ </code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>AlertLevel&nbsp;level;</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>AlertDescription&nbsp;description;</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>}&nbsp;Alert;</code> </td> 
 </tr> 
 </tbody> 
</table>

经过 TLS 记录层包装以后，结构如下:

![image.png][image.png 15]

TLS 1.3 和 TLS 1.2 在这个协议上改动很小，只是新增加了几个枚举类型。

TLS 1.2 的所有警告描述信息：

TLS 1.3 的所有警告描述信息：

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 </td> 
 <td> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>enum&nbsp;{ </code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>close_notify(</code><code>0</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>unexpected_message(</code><code>10</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>bad_record_mac(</code><code>20</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>decryption_failed_RESERVED(</code><code>21</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>record_overflow(</code><code>22</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>decompression_failure_RESERVED(</code><code>30</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>handshake_failure(</code><code>40</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>no_certificate_RESERVED(</code><code>41</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>bad_certificate(</code><code>42</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>unsupported_certificate(</code><code>43</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>certificate_revoked(</code><code>44</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>certificate_expired(</code><code>45</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>certificate_unknown(</code><code>46</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>illegal_parameter(</code><code>47</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>unknown_ca(</code><code>48</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>access_denied(</code><code>49</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>decode_error(</code><code>50</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>decrypt_error(</code><code>51</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>export_restriction_RESERVED(</code><code>60</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>protocol_version(</code><code>70</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>insufficient_security(</code><code>71</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>internal_error(</code><code>80</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>inappropriate_fallback(</code><code>86</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>user_canceled(</code><code>90</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>no_renegotiation_RESERVED(</code><code>100</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>missing_extension(</code><code>109</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>unsupported_extension(</code><code>110</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>certificate_unobtainable_RESERVED(</code><code>111</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>unrecognized_name(</code><code>112</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>bad_certificate_status_response(</code><code>113</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>bad_certificate_hash_value_RESERVED(</code><code>114</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>unknown_psk_identity(</code><code>115</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>certificate_required(</code><code>116</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>no_application_protocol(</code><code>120</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>(</code><code>255</code><code>)</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>}&nbsp;AlertDescription;</code> </td> 
 </tr> 
 </tbody> 
</table>

TLS 1.3 比 TLS 1.2 新增了 9 个警告描述信息：

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 </td> 
 <td> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>inappropriate_fallback(</code><code>86</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>missing_extension(</code><code>109</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>certificate_unobtainable_RESERVED(</code><code>111</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>unrecognized_name(</code><code>112</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>bad_certificate_status_response(</code><code>113</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>bad_certificate_hash_value_RESERVED(</code><code>114</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>unknown_psk_identity(</code><code>115</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>certificate_required(</code><code>116</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>no_application_protocol(</code><code>120</code><code>),</code> </td> 
 </tr> 
 </tbody> 
</table>

**4. TLS 握手协议**

握手协议是整个 TLS 协议簇中最最核心的协议，HTTPS 能保证安全也是因为它的功劳。

握手协议由多个子消息构成，服务端和客户端第一次完成一次握手需要 2-RTT。

握手协议的目的是为了双方协商出密码块，这个密码块会交给 TLS 记录层进行密钥加密。也就是说握手协议达成的“共识”(密码块)是整个 TLS 和 HTTPS 安全的基础。

握手协议在 TLS 1.2 和 TLS 1.3 中发生了很大的变化。TLS 1.3 的 0-RTT 是一个全新的概念。两个版本在密钥协商上，密码套件选择上都有很大不同。

TLS 1.2 协议数据结构如下：

TLS 1.3 协议数据结构如下：

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 </td> 
 <td> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>enum&nbsp;{ </code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>hello_request_RESERVED(</code><code>0</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>client_hello(</code><code>1</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>server_hello(</code><code>2</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>hello_verify_request_RESERVED(</code><code>3</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>new_session_ticket(</code><code>4</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>end_of_early_data(</code><code>5</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>hello_retry_request_RESERVED(</code><code>6</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>encrypted_extensions(</code><code>8</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>certificate(</code><code>11</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>server_key_exchange_RESERVED(</code><code>12</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>certificate_request(</code><code>13</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>server_hello_done_RESERVED(</code><code>14</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>certificate_verify(</code><code>15</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>client_key_exchange_RESERVED(</code><code>16</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>finished(</code><code>20</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>certificate_url_RESERVED(</code><code>21</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>certificate_status_RESERVED(</code><code>22</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>supplemental_data_RESERVED(</code><code>23</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>key_update(</code><code>24</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>message_hash(</code><code>254</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>(</code><code>255</code><code>)</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>}&nbsp;HandshakeType;</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code>&nbsp; <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>struct&nbsp;{ </code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>HandshakeType&nbsp;msg_type;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>/*&nbsp;handshake&nbsp;type&nbsp;*/</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>uint24&nbsp;length;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>/*&nbsp;bytes&nbsp;in&nbsp;message&nbsp;*/</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>select&nbsp;(Handshake.msg_type)&nbsp;{ </code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>case</code>&nbsp;<code>client_hello:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ClientHello;</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>case</code>&nbsp;<code>server_hello:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ServerHello;</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>case</code>&nbsp;<code>end_of_early_data:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EndOfEarlyData;</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>case</code>&nbsp;<code>encrypted_extensions:&nbsp;&nbsp;EncryptedExtensions;</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>case</code>&nbsp;<code>certificate_request:&nbsp;&nbsp;&nbsp;CertificateRequest;</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>case</code>&nbsp;<code>certificate:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Certificate;</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>case</code>&nbsp;<code>certificate_verify:&nbsp;&nbsp;&nbsp;&nbsp;CertificateVerify;</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>case</code>&nbsp;<code>finished:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Finished;</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>case</code>&nbsp;<code>new_session_ticket:&nbsp;&nbsp;&nbsp;&nbsp;NewSessionTicket;</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>case</code>&nbsp;<code>key_update:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;KeyUpdate;</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>};</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>}&nbsp;Handshake;</code> </td> 
 </tr> 
 </tbody> 
</table>

经过 TLS 记录层包装以后，结构如下:

![image.png][image.png 16]

握手消息类型虽然有很多种，但是最终传到 TLS 记录层，有些会被合并到一条消息。

> 关于 TLS 握手协议更多细节将在接下来的文章中详细分析。也会对 TLS 1.2 和 TLS 1.3 展开对比。

**5. TLS 应用数据协议**

应用数据协议就是 TLS 上层的各种协议，TLS 主要保护的数据就是应用数据协议的数据。

经过 TLS 记录层包装以后，结构如下:

![image.png][image.png 17]

TLS 记录层会根据加密模式的不同在应用数据的末尾加上 MAC 校验数据。

**6. TLS 心跳协议**

这个协议是 TLS 1.3 新增的。更加细节可以看这篇文章[《TLS & DTLS Heartbeat Extension》][TLS _ DTLS Heartbeat Extension]，这篇文章是笔者根据 [\[RFC 6520\] ][RFC 6520_]翻译的。感兴趣的可以去看看这篇文章。这篇文章还涉及到了 DTLS 和 PMTU 发现。

协议数据结构如下：

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 12 </td> 
 <td> <code>&nbsp;&nbsp;&nbsp;</code><code>enum&nbsp;{ </code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>heartbeat_request(</code><code>1</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>heartbeat_response(</code><code>2</code><code>),</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>(</code><code>255</code><code>)</code> <code>&nbsp;&nbsp;&nbsp;</code><code>}&nbsp;HeartbeatMessageType;</code> <code>&nbsp;&nbsp;&nbsp;</code>&nbsp; <code>&nbsp;&nbsp;&nbsp;</code><code>struct&nbsp;{ </code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>HeartbeatMessageType&nbsp;type;</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>uint16&nbsp;payload_length;</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>opaque&nbsp;payload[HeartbeatMessage.payload_length];</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>opaque&nbsp;padding[padding_length];</code> <code>&nbsp;&nbsp;&nbsp;</code><code>}&nbsp;HeartbeatMessage;</code> </td> 
 </tr> 
 </tbody> 
</table>

经过 TLS 记录层包装以后，结构如下:

![image.png][image.png 18]

根据 [\[RFC6066\] ][RFC6066_]中的定义，在协商的时候，HeartbeatMessage 的总长度不得超过 2 ^ 14 或 max\_fragment\_length。

HeartbeatMessage 的长度为 TLS 的TLSPlaintext.length 和 DTLS 的 DTLSPlaintext.length。此外，类型 type 字段的长度是 1 个字节，并且 payload\_length 的长度是 2 个字节。因此，padding\_length 是TLSPlaintext.length - payload\_length - 3 用于 TLS，DTLSPlaintext.length - payload\_length - 3 用于 DTLS。padding\_length 必须至少为 16。

HeartbeatMessage 的发送方必须使用至少 16 个字节的随机填充。必须忽略收到的HeartbeatMessage 消息的填充。

**五. 接下来**

本篇文章作为 HTTPS 的开篇文章，分析了 HTTTPS 协议存在的必要性，HTTPS 带来的好处，HTTPS 安全的本质，以及 TLS 各个子协议之间的关系和作用。

接下来的几篇文章将会详细的对比 TLS 1.2 和 TLS 1.3 在握手协议上的差别，在记录层上的差别，在密钥导出上的差别，以及 TLS 1.3 新增的 0-RTT 到底是怎么回事。

Reference：

《图解 HTTP》  
《深入浅出 HTTPS》  
[TLS 1.3 规范 \[RFC 8446\]][TLS 1.3 _ _RFC 8446]  
[TLS 1.2 规范 \[RFC 5246\]][TLS 1.2 _ _RFC 5246]

> GitHub Repo：[Halfrost-Field][]
> 
> Follow: [halfrost · GitHub][halfrost _ GitHub]
> 
> Source:

[image.png]: http://cc.cocimg.com/api/uploads//20190122/1548133486390531.png
[image.png 1]: http://cc.cocimg.com/api/uploads//20190122/1548133514914848.png
[image.png 2]: http://cc.cocimg.com/api/uploads//20190122/1548133553723453.png
[image.png 3]: http://cc.cocimg.com/api/uploads//20190122/1548133581141767.png
[image.png 4]: http://mcenter.cocoachina.com/uploads/20190122/1548133754193001.png
[Link 1]: https://github.com/halfrost/Halfrost-Field/blob/master/contents/Protocol/HTTPS-symmetric-encryption.md
[image.png 5]: http://cc.cocimg.com/api/uploads//20190122/1548133843450910.png
[Link 2]: https://github.com/halfrost/Halfrost-Field/blob/master/contents/Protocol/HTTPS-asymmetric-encryption.md
[68747470733a2f2f696d672e68616c66726f73742e636f6d2f426c6f672f41727469636c65496d6167652f39355f382e706e67.png]: http://cc.cocimg.com/api/uploads//20190122/1548133909526270.png
[image.png 6]: http://cc.cocimg.com/api/uploads//20190122/1548133953556798.png
[Link 3]: https://github.com/halfrost/Halfrost-Field/blob/master/contents/Protocol/HTTPS-digital-certificate.md
[image.png 7]: http://cc.cocimg.com/api/uploads//20190122/1548134005702192.png
[image.png 8]: http://cc.cocimg.com/api/uploads//20190122/1548134017871992.png
[image.png 9]: http://cc.cocimg.com/api/uploads//20190122/1548134138853809.png
[image.png 10]: http://cc.cocimg.com/api/uploads//20190122/1548134178751033.png
[image.png 11]: http://cc.cocimg.com/api/uploads//20190122/1548135020907559.png
[image.png 12]: http://cc.cocimg.com/api/uploads//20190122/1548135040808702.png
[image.png 13]: http://cc.cocimg.com/api/uploads//20190122/1548135096449148.png
[image.png 14]: http://cc.cocimg.com/api/uploads//20190122/1548134490754225.png
[image.png 15]: http://cc.cocimg.com/api/uploads//20190122/1548134550807528.png
[image.png 16]: http://mcenter.cocoachina.com/uploads/20190122/1548134650863903.png
[image.png 17]: http://cc.cocimg.com/api/uploads//20190122/1548134708471648.png
[TLS _ DTLS Heartbeat Extension]: https://github.com/halfrost/Halfrost-Field/blob/master/contents/Protocol/TLS_Heartbeat.md
[RFC 6520_]: https://tools.ietf.org/html/rfc6520
[image.png 18]: http://cc.cocimg.com/api/uploads//20190122/1548134828382473.png
[RFC6066_]: https://tools.ietf.org/html/rfc6066
[TLS 1.3 _ _RFC 8446]: https://tools.ietf.org/html/rfc8446
[TLS 1.2 _ _RFC 5246]: https://tools.ietf.org/html/rfc5246
[Halfrost-Field]: https://github.com/halfrost/Halfrost-Field
[halfrost _ GitHub]: https://github.com/halfrost