HTTPS 的七次握手

前面就知道，HTTP是基于TCP的，而TCP建立连接需要3次握手，而印象中HTTPS建立连接需要7次握手，对这一部分比较模糊，就对HTTPS的握手过程进行了一下梳理。

HTTPS的7次握手，其实是包含TCP建立连接的三次握手，加上SSL/TLS建立连接的四次握手，且SSL/TLS建立连接是基于TCP的连接进行的。

TCP的连接建立一般都比较熟悉，这里只介绍下TLS的建立过程。

四次交互，每次交互可能会发多条消息给对方

111 ClientHello Message

客户端向服务端发送client key，TLS版本、加密组件列表、压缩算法

client key: 用于后续对称加密的计算因子

TLS 版本：告诉服务端，当前client支持的TLS协议版本，服务端会从中选择一个，在下次交互时告诉客户端。

加密组件: 告诉服务端，当前client支持的加密组件，服务端会从中选择一个，在下次交互时告诉客户端。

压缩算法：告诉服务端，当前client支持的压缩算法，服务端会从中选择一个，在下次交互时告诉客户端。

121 ServerHello Message

发送随机数server key、TLS 版本、服务端选择的加密组件、服务端选择的压缩算法

server key : 用于后续对称加密的计算因子

TLS 版本 ：服务端从客户端支持TLS版本列表中选择的协议版本，一般会优先选择安全性较高的版本

加密组件 : 服务端从客户端支持加密组件列表中选择的加密组件，一般会优先选择安全性较高的组件

压缩算法 ：服务端从客户端支持压缩算法列表中选择的压缩算法

122 Server Certificate

发送服务端证书

客户端在受到证书后，会对其证书的有效性进行验证，从而确认服务端身份。

123 CertificateRequest Message

发送客户端证书验证请求（可选）

对于服务端需要验证客户端身份的场景，发送此请求，让客户端将客户端证书发给服务端。

124 ServerHelloDone message

告诉客户端此次发送的内容已完成

在发送消息前，客户端会对122发送的服务端证书进行校验，校验通过后，发送后面的消息。

131 Client Certificate

发送客户端证书（可选）

如果收124的CertificateRequest Message，则将客户端证书发给对方

132 ClientKeyExchange message

发送第三个密钥 Pre-master Secret，用服务端证书公钥加密过的一个随机数

133 ChangeCipherSpec Message

告诉服务端，以后的通信都适用协商好的加密方法和密钥进行加密

134 Finished Message

客户端握手结束通知，用对称密钥加密。这个报文也是验证消息，是前面发送的所有内容的哈希值，用来供服务器校验。

141 ChangeCipherSpec message

加密约定改变通知

告诉客户端，以后的通信都适用协商好的加密方法和密钥进行加密

142 Finished Message

服务端握手结束通知，用对称密钥加密。这个报文也是验证消息，是前面发送的所有内容的哈希值，用来供客户器校验。

对称加密的加密因子通过三次交互来协调的，分别如下:

[明文] ClientHello Message中的client key

[明文] ServerHello Message中的server key

[RSA] ClientKeyExchange Message中的Pre-master Secret，客户端发送时使用服务端证书包含的公钥对其进行加密，服务端在收到此消息后使用私钥解密

两端分别通过client key，server key和Pre-master Secret生成master secret，用于加密后续通信内容。

参考文章：

Traffic Analysis of an SSL/TLS Session

对称加密算法与TLS

HTTPS是什么相信大家都知道，如果你不知道。。。请关闭此文！！！

HTTP的数据是明文传输的，没有安全性可言。HTTPS是秘文传输，那么HTTPS是怎么实现数据的安全(加密)传输的？那是因为HTTPS比HTTP多了个'S'。 即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。

SSL/TLS协议是网络安全通信的重要基石，本文将简单介绍SSL/TLS协议，主要关注SSL/TLS协议的安全性，特别是SSL规范的正确实现。 本系列的文章大体分为几个部分：

1、SSL/TLS简介

2、SSL/TLS协议的基本流程

3、从SSL到TLS

4、SSL/TLS的流行实现库

SSL全称是Secure Sockets Layer，安全套接字层，它是由网景公司(Netscape)设计的主要用于Web的安全传输协议，目的是为网络通信提供机密性、认证性及数据完整性保障。如今，SSL已经成为互联网保密通信的工业标准。

SSL最初的几个版本(SSL 10、SSL20、SSL 30)由网景公司设计和维护，从31版本开始，SSL协议由因特网工程任务小组(IETF)正式接管，并更名为TLS(Transport Layer Security)，发展至今已有TLS 10、TLS11、TLS12这几个版本。

如TLS名字所说，SSL/TLS协议仅保障传输层安全。同时，由于协议自身特性(数字证书机制)，SSL/TLS不能被用于保护多跳(multi-hop)端到端通信，而只能保护点到点通信。

SSL/TLS协议能够提供的安全目标主要包括如下几个：

认证性——借助数字证书认证服务器端和客户端身份，防止身份伪造

机密性——借助加密防止第三方窃听

完整性——借助消息认证码(MAC)保障数据完整性，防止消息篡改

重放保护——通过使用隐式序列号防止重放攻击

为了实现这些安全目标，SSL/TLS协议被设计为一个两阶段协议，分为握手阶段和应用阶段：

握手阶段也称协商阶段，在这一阶段，客户端和服务器端会认证对方身份(依赖于PKI体系，利用数字证书进行身份认证)，并协商通信中使用的安全参数、密码套件以及MasterSecret。后续通信使用的所有密钥都是通过MasterSecret生成。

在握手阶段完成后，进入应用阶段。在应用阶段通信双方使用握手阶段协商好的密钥进行安全通信。

Handshake协议：包括协商安全参数和密码套件、服务器身份认证(客户端身份认证可选)、密钥交换;

ChangeCipherSpec 协议：一条消息表明握手协议已经完成;

Alert 协议：对握手协议中一些异常的错误提醒，分为fatal和warning两个级别，fatal类型的错误会直接中断SSL链接，而warning级别的错误SSL链接仍可继续，只是会给出错误警告;

Record 协议：包括对消息的分段、压缩、消息认证和完整性保护、加密等。

图2、图3都是表示的协议流程，大同小异。可以对比着看加深理解。

每一个SSL/TLS链接都是从握手开始的，握手过程包含一个消息序列，用以协商安全参数、密码套件，进行身份认证以及密钥交换。握手过程中的消息必须严格按照预先定义的顺序发生，否则就会带来潜在的安全威胁。今年顶级安全会议CCS 有文章提出了建立综合状态机来检查SSL链接中消息序列……

21 握手过程中的消息序列

ClientHello：ClientHello通常是握手过程中的第一条消息，用于告知服务器客户端所支持的密码套件种类、最高SSL/TLS协议版本以及压缩算法。

ClientHello中还包含一个随机数，这个随机数由4个字节的当前GMT UNIX时间以及28个随机选择的字节组成，共32字节。该随机数会在密钥生成过程中被使用。

另外，ClientHello中还可能包含客户端支持的TLS扩展。(TLS扩展可以被用来丰富TLS协议的功能或者增强协议的安全性)

ServerHello：服务器接受到ClientHello后，会返回ServerHello。服务器从客户端在ClientHello中提供的密码套件、SSL/TLS版本、压缩算法列表里选择它所支持的项，并把它的选择包含在ServerHello中告知客户端。接下来SSL协议的建立就基于服务器选择的密码套件类型、SSL/TLS协议版本以及压缩算法。

ServerHello中同样会包含一个随机数，同样4+28 字节类型，由服务器生成。

Certificate：客户端和服务器都可以发送证书消息来证明自己的身份，但是通常客户端证书不被使用。 服务器一般在ServerHello后会接一条Certificate消息，Certificate消息中会包含一条证书链，从服务器证书开始，到Certificate authority(CA)或者最新的自签名证书结束。下图形象地描述了证书链：

SSL中使用的证书通常是X509类型证书，X509证书的内容如下表所示：

在用的X509证书包含Version 1和Version 3两种版本，其中v1版本的证书存在安全隐患，同时不支持TLS扩展，被逐渐弃用。现在大多数在用的SSL证书都是V3版本。

同时证书会附带与协商好的密钥交换算法对应的密钥。密钥交换算法以及它们所要求的密钥类型如下表所示。

ServerKeyExchange：该消息仅当以下密钥交换算法被使用时由服务器发出：

RSA_EXPORT(仅当服务器的公钥大于512bit时)、DHE_DSS、DHE_DSS_EXPORT、DHE_RSA、DHE_RSA_EXPORT、DH_anon 使用其它密钥交换算法时，服务器不能发送此消息。

ServerkeyExchange消息会携带这些密钥交换算法所需要的额外参数，以在后续步骤中协商PreMasterSecret。这些参数需要被签过名。

CertificateRequest：这个消息通常在要求认证客户端身份时才会有。消息中包含了证书类型以及可接受的CA列表。

ServerHelloDone：服务器发送这条消息表明服务器部分的密钥交换信息已经发送完了，等待客户端的消息以继续接下来的步骤。这条消息只用作提醒，不包含数据域。

ClientKeyExchange：这条消息包含的数据与所选用的密钥交换算法有关。

如果选择的密钥交换算法是RSA，那么消息包含的参数为用服务器RSA公钥(包含在之前证书中的或者是ServerKeyExchange中的)加密过的PreMasterSecret，它有48个字节，前2个字节表示客户端支持的最高协议版本，后46个字节是随机选择的。

如果选择的密钥交换算法是DH或者DHE，则可能有两种情况：

隐式DH公开值：包含在Certificate消息里;

显示DH公开值：公开值是本消息的一部分。

CertificateVerify：这条消息用来证明客户端拥有之前提交的客户端证书的私钥。

Finished：表明握手阶段结束。这是第一条用协商的算法和密钥保护的消息。

因为是用协商好的密钥加密的消息，它可以用来确认已经协商好的密钥。

同时Finished消息包含一个verify_data域，可以用来校验之前发送和接收的信息。

Verify_data域是一个PRF函数的输出(pseudo-random function)。这个伪随机函数的输入为：(1)两个hash值：一个SHA-1，一个MD5，对之前握手过程中交换的所有消息做哈希;(2)the MasterSecret，由预备主密钥生成;(3)finished_label，如果客户端发送的则是”client finished”，服务器发送的则是”server finished”。关于这个PRF的细节在33节中会具体描述。 此外，Finished 消息不能够在ChangeCipherSpec前发送。

22 不同密钥交换算法对应的握手过程

不同的密钥交换算法对应的握手过程中的消息序列是不同的，相应的实现方式也不同，本节介绍几个常见密钥交换算法对应的握手过程。

TLS-RSA：在这个场景下，PreMasterSecret是由客户端指定的，并用RSA公钥加密发送给服务器。服务器不影响PReMasterSecret的生成。

TLS-DH：基于DH的密钥交换也被称为静态Diffie-Hellman。在这种场景下，可能是双方各自提交一个证书包含DH公开值，或者服务器端提交证书包含DH公开值，客户端在每次会话中选择一个值。协商好的DH值被用作PreMasterSecret。显然证书中的参数是固定的，那么每次链接的PreMasterSecret也是相同的。

TLS-DH不能提供前向安全性。

TLS-DHE：基于DHE的TLS握手中会有ServerKeyExchange消息。握手过程中交换参数的认证通过数字签名来实现，支持的签名算法包括RSA和DSS。DH参数会有它的数字签名一起被包含在ServerKeyExchange中被发送出去。客户端在ClientKeyExchange中返回它的公开DH参数，但没有签名保护。同样协商出来的DH密钥被用作PreMasterSecret。

23 密钥生成

Pseudo-random Function(PRF)：伪随机函数是SSL协议中的一个重要组成部分，它被用来秘密扩展以及生成密钥。在31节讲解Finished消息时已经简单提及PRF，在这里我们详细讨论PRF的工作原理。SSL/TLS协议中的PRF如下图所示：

这个PRF基于两个hash函数：MD5和SHA-1，它有3个输入，一个Secret(比如PreMasterSecret)，一个标志符(比如”client finished”, “server finished”)，还有一个种子值(比如客户端随机数+服务器端随机数)。

Secret在使用时被分为长度相同的两半：S1和S2，分别作为P_MD5和P_SHA-1的输入。

PRF的输出按如下方式处理得到：

P_MD5和P_SHA-1都是扩展函数，用来扩展秘密值以用于密钥生成，它们的计算方式如下：

其中A(0) = seed, A(i) = HMAC hash( secret, A( i −1) )

这个秘密扩展会一直进行直到得到足够多的扩展数据。 Key Derivation：主密钥(MasterSecret)是利用上述PRF从预备主密钥(PreMasterSecret)生成的。每个MasterSecret为48字节，生成方式如下：

得到MasterSecret后，它会被进一步处理最后生成4个不同的密钥和2个初始向量(IV)。处理过程如下：

处理过程一直持续到足够多的输出被生成，然后把输出分为4个key和2个IV：

下图完整阐述了SSL/TLS协议中的密钥生成过程。

本节介绍SSL/TLS协议的版本变迁，不同版本的区别以及安全特性等。

SSL 10由于从来没有被公开过，并且存在严重安全漏洞，我们就不讨论了。

SSL 20：SSL 20于1995年4月被发布。SSL 20中主要存在的问题如下：

MAC不能覆盖填充长度域，攻击者可能利用这点破坏消息完整性;

缺乏握手认证，攻击者可以篡改密码套件列表，诱骗通信双方使用较弱的密码套件;

使用较弱的或有问题的密码算法(如MD5，RC4等)，或者使用不安全的分组模式(如CBC模式);

对于不同的密码学基元使用相同的密钥，违背基本安全常识。

由于以上安全问题，RFC 6176已经明确提出避免使用SSL 20，但是现实生活中还有少量客户端和服务器支持SSL 20

SSL 30：SSL 30引入了一些新的特性和机制解决了很多之前版本存在的漏洞。此外，SSL 30中引入了ChangeCipherSpec子协议。SSL 30向后兼容SSL 20，相对于SSL 20，它的主要改变包括以下几点：

支持更多的密码套件(支持更多的密码算法如DSS，SHA-1)

在握手阶段支持密钥协商(DH和FORTEZZA)

支持密码学参数的重协商

增加了消息压缩选项

MAC能够覆盖填充长度域了，同时MAC可以使用MD5或者SHA-1

不同的密码学基元使用不同的key

Alert子协议能对任何错误给出两种提示：Warning和Fatal

中止链接的时候会用一个close_notify警告通知通信双方

支持证书链，而非单个证书

通过Finished消息认证所有发送和接收的消息

加密了的PreMasterSecret包含当前使用的协议版本，防止协议回滚

TLS 10：TLS 10和SSL 30差别非常小。实际上，TLS 10是SSL 31，在IETF接手后改名为TLS。TLS 10版本是目前使用最广泛的SSL/TLS协议版本。

TLS 10不再支持使用FORTEZZA的密码套件。

TLS 10中MAC被替换成HMAC。

之前提到ChangeCipherSpec消息必须在Finished消息前发送，在TLS 10中，如果消息序列不符合这个要求，会产生FATAL警告并终止链接。

TLS 11：这个版本相比之前改动也很小。最重要的改动是预防了针对CBC分组模式的一些攻击。现在的填充错误变的和非法MAC错误不可区分了，防止攻击者利用可区分错误响应建立解密预言机对密文进行攻击。

在每次加密过程中，使用CBC分组模式时，都需要显示给出IV，而不用再密钥生成时使用PRF生成IV。

此外，TLS 11禁止为适应之前出口限制而使用弱化的密码套件。

TLS 12：这是最新的版本，部署的还比较少。这个版本禁用了PRF中的MD5和SHA-1，而用一个可配置的hash函数取代了它们，这样的修改简化了计算过程。修改后的PRF风格如下：

此外，TLS 12的一个重要变化是支持认证加密模式(支持GCM等)。但是由于一些AEAD(Authenticated Encryption with Associated Data)密码算法要求IV为隐式的，所以IV又恢复到由MasterSecret生成，即TLS 10以前的风格。

TLS 12支持使用GCM、CCM的新密码套件。

同时SSL 20被宣布放弃，不再向后兼容SSL 20

本节简单介绍一下流行的SSL/TLS实现库，SSL协议非常复杂，由开发者自己实现常常会出错，开发者在具体实现SSL协议时通常会依赖于这些密码学库。

41 常见的SSL/TLS 实现

OpenSSL：这是非常流行的开源SSL/TLS实现。

OpenSSLim完全用C语言实现，支持SSL 20/30，TLS 10/11/12以及DTLS 10。

OpenSSL 近年来出现了很多的安全漏洞，比如2014年曝出的著名的Heartbleed漏洞等。

JSSE：这是使用Java实现的，支持SSL 30，TLS 10/11/12

Bouncy Castle：它不仅仅支持SSL/TLS，它是一个完整的密码学库，支持各种密码学算法和协议。不过它仅仅支持TLS 10版本。

Android平台主要使用这个密码学库。

GnuTLS：这是另一个用C语言实现的库，支持SSL 30，TLS 10/11/12以及DTLS 10。主要在Unix世界被使用。同时以各种安全漏洞多而闻名。

NSS：这是最初由网景公司(Netscape)开发的库，支持SSL 20/30，TLS 10/11，现在主要被浏览器和客户端软件使用，比如Firefox使用的就是NSS库，Chrome使用的是一个NSS库的修正版。

下表是一些常见软件以及它们所使用的SSL/TLS实现库的情况：

其它还有一些常用的SSL实现库，如cryptlib、CyaSSL、MatrixSSL、PolarSSL等，由于市场占有率不高，我们这里就不多做介绍了。

42 流行SSL/TLS实现库的安全研究

最近几年曝出的高风险SSL安全漏洞大多跟SSL实现库有关，比如2014年4月曝出的“心脏滴血”漏洞，存在于OpenSSL 101-101f版本中，影响全球近17%的Web服务器;同样是2014年曝出的苹果公司iOS 706版本系统中存在的“gotofail”漏洞，因为程序员的疏忽导致SSL证书校验中的签名校验失效;包括今年曝出的SSL Freak攻击也是由于SSL实现库的安全漏洞导致的攻击，我们研究小组的同学对这个攻击有详细的分析，参见《SSL Freak来袭：如何实施一个具体的SSL Freak攻击》。同时我们还开发了一个基于python的中间人代理攻击框架“风声”对某国内知名电商的服务器进行具体的攻击，并上报了漏洞。

考虑到大量SSL/TLS实现库中存在安全问题，同时这些主流的SSL/TLS实现库对开发者而言使用难度较高，比如有些SSL/TLS实现库要求开发者自己进行随机数生成或密钥管理，让缺乏系统信息安全知识培训的开发者去使用这样高度复杂的密码学库容易产生很多安全问题。我们在这里推荐一些高级密码学库：Google keycazer、NaCl、Cryptlib、GPGME。这些密码学库存在的安全问题较少，同时封装了一些底层的密码学操作，降低了开发者的使用难度。

以上就是本次要介绍的SSL /TLS协议基本知识，后续的文章我们会对一些典型SSL/TLS攻击进行具体介绍。

参考：

1、 http://netsecurity51ctocom/art/201505/476337htm

2、 http://wwwcnblogscom/NathanYang/p/9183300html

3、 https://wwwcnblogscom/bhlsheji/p/4586597html

TLS 为传输层安全性协议，是 MySQL 在客户端与服务器之间进行加密连接的协议。TLS 有时被称为 SSL（安全套接层），但是 MySQL 实际上并不使用 SSL 协议进行加密连接，因为它的加密很弱。TLS 协议通过加密数据来确保在两个通信应用程序之间提供隐私和数据完整性，以便任何第三方都无法拦截通信。它还会验证对等方以验证其身份。通过在两个对等点之间提供安全的通信通道，TLS 协议可以保护消息的完整性并确保其不会被篡改。MySQL 支持多种 TLS 版本协议，此次测试使用 80 的 client 为 TLSv12。

从 wireshark 中看一下 TLS 握手的步骤：

SSL (Secure Sockets Layer) 安全套接层，是一种安全协议，经历了 SSL 10、20、30 版本后发展成了标准安全协议 - TLS (Transport Layer Security) 传输层安全性协议。TLS 有 10 (RFC 2246)、11(RFC 4346)、12(RFC 5246)、13(RFC 8446) 版本。

TLS 在实现上分为 记录层 和 握手层 两层，其中握手层又含四个子协议: 握手协议 (handshake protocol)、更改加密规范协议 (change cipher spec protocol)、应用数据协议 (application data protocol) 和警告协议 (alert protocol)

只需配置浏览器和服务器相关设置开启 TLS，即可实现 HTTPS，TLS 高度解耦，可装可卸，与上层高级应用层协议相互协作又相互独立。

TLS/SSL 的功能实现主要依赖于三类基本算法：散列函数 Hash、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。

TLS 的基本工作方式是，客户端使用非对称加密与服务器进行通信，实现身份验证并协商对称加密使用的密钥，然后对称加密算法采用协商密钥对信息以及信息摘要进行加密通信，不同的节点之间采用的对称密钥不同，从而可以保证信息只能通信双方获取。

例如，在 HTTPS 协议中，客户端发出请求，服务端会将公钥发给客户端，客户端验证过后生成一个密钥再用公钥加密后发送给服务端（非对称加密），双方会在 TLS 握手过程中生成一个协商密钥（对称密钥），成功后建立加密连接。通信过程中客户端将请求数据用协商密钥加密后发送，服务端也用协商密钥解密，响应也用相同的协商密钥。后续的通信使用对称加密是因为对称加解密快，而握手过程中非对称加密可以保证加密的有效性，但是过程复杂，计算量相对来说也大。

记录协议负责在传输连接上交换的所有底层消息，并且可以配置加密。每一条 TLS 记录以一个短标头开始。标头包含记录内容的类型 (或子协议)、协议版本和长度。原始消息经过分段 (或者合并)、压缩、添加认证码、加密转为 TLS 记录的数据部分。

记录层将信息块分割成携带 2^14 字节 (16KB) 或更小块的数据的 TLSPlaintext 记录。

记录协议传输由其他协议层提交给它的不透明数据缓冲区。如果缓冲区超过记录的长度限制（2^14），记录协议会将其切分成更小的片段。反过来也是可能的，属于同一个子协议的小缓冲区也可以组合成一个单独的记录。

压缩算法将 TLSPlaintext 结构转换为 TLSCompressed 结构。如果定义 CompressionMethod 为 null 表示不压缩

流加密（BulkCipherAlgorithm）将 TLSCompressedfragment 结构转换为流 TLSCiphertextfragment 结构

MAC 产生方法如下：

seq_num（记录的序列号）、hash（SecurityParametersmac_algorithm 指定的哈希算法）

块加密（如 RC2 或 DES），将 TLSCompressedfragment 结构转换为块 TLSCiphertextfragment 结构

padding: 添加的填充将明文长度强制为块密码块长度的整数倍。填充可以是长达 255 字节的任何长度，只要满足 TLSCiphertextlength 是块长度的整数倍。长度大于需要的值可以阻止基于分析交换信息长度的协议攻击。填充数据向量中的每个 uint8 必须填入填充长度值 (即 padding_length)。

padding_length: 填充长度应该使得 GenericBlockCipher 结构的总大小是加密块长度的倍数。合法值范围从零到 255（含）。 该长度指定 padding_length 字段本身除外的填充字段的长度

加密块的数据长度（TLSCiphertextlength）是 TLSCompressedlength，CipherSpechash_size 和 padding_length 的总和加一

加密和 MAC 功能将 TLSCompressed 结构转换为 TLSCiphertext。记录的 MAC 还包括序列号，以便可以检测到丢失，额外或重复的消息。

记录协议需要一种算法，从握手协议提供的安全性参数生成密钥、 IV 和 MAC secret

主密钥 (Master secret): 在连接中双方共享的一个 48 字节的密钥

客户随机数 (client random): 由客户端提供的 32 字节值

服务器随机数 (server random): 由服务器提供的 32 字节值

握手是 TLS 协议中最精密复杂的部分。在这个过程中，通信双方协商连接参数，并且完成身 份验证。根据使用的功能的不同，整个过程通常需要交换 6~10 条消息。根据配置和支持的协议扩展的不同，交换过程可能有许多变种。在使用中经常可以观察到以下三种流程：(1) 完整的握手， 对服务器进行身份验证；(2) 恢复之前的会话采用的简短握手；(3) 对客户端和服务器都进行身份验证的握手。

握手协议消息的标头信息包含消息类型（1 字节）和长度（3 字节），余下的信息则取决于消息类型：

每一个 TLS 连接都会以握手开始。如果客户端此前并未与服务器建立会话，那么双方会执行一次完整的握手流程来协商 TLS 会话。握手过程中，客户端和服务器将进行以下四个主要步骤:

下面介绍最常见的握手规则，一种不需要验证客户端身份但需要验证服务器身份的握手:

这条消息将客户端的功能和首选项传送给服务器。

是将服务器选择的连接参数传回客户端。

这个消息的结构与 ClientHello 类似，只是每个字段只包含一个选项，其中包含服务端的 random_S 参数 (用于后续的密钥协商)。服务器无需支持客户端支持的最佳版本。如果服务器不支持与客户端相同的版本，可以提供某个其他版本以期待客户端能够接受

图中的 Cipher Suite 是后续密钥协商和身份验证要用的加密套件，此处选择的密钥交换与签名算法是 ECDHE_RSA，对称加密算法是 AES-GCM，后面会讲到这个

还有一点默认情况下 TLS 压缩都是关闭的，因为 CRIME 攻击会利用 TLS 压缩恢复加密认证 cookie，实现会话劫持，而且一般配置 gzip 等内容压缩后再压缩 TLS 分片效益不大又额外占用资源，所以一般都关闭 TLS 压缩

典型的 Certificate 消息用于携带服务器 X509 证书链 。

服务器必须保证它发送的证书与选择的算法套件一致。比方说，公钥算法与套件中使用的必须匹配。除此以外，一些密钥交换算法依赖嵌入证书的特定数据，而且要求证书必须以客户端支持的算法签名。所有这些都表明服务器需要配置多个证书（每个证书可能会配备不同的证书链）。

Certificate 消息是可选的，因为并非所有套件都使用身份验证，也并非所有身份验证方法都需要证书。更进一步说，虽然消息默认使用 X509 证书，但是也可以携带其他形式的标志；一些套件就依赖 PGP 密钥

携带密钥交换需要的额外数据。ServerKeyExchange 是可选的，消息内容对于不同的协商算法套件会存在差异。部分场景下，比如使用 RSA 算法时，服务器不需要发送此消息。

ServerKeyExchange 仅在服务器证书消息（也就是上述 Certificate 消息）不包含足够的数据以允许客户端交换预主密钥（premaster secret）时才由服务器发送。

比如基于 DH 算法的握手过程中，需要单独发送一条 ServerKeyExchange 消息带上 DH 参数:

表明服务器已经将所有预计的握手消息发送完毕。在此之后，服务器会等待客户端发送消息。

客户端验证证书的合法性，如果验证通过才会进行后续通信，否则根据错误情况不同做出提示和操作，合法性验证内容包括如下:

由 PKI 体系 的内容可知，对端发来的证书签名是 CA 私钥加密的，接收到证书后，先读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性；然后去查询证书的吊销情况等

合法性验证通过之后，客户端计算产生随机数字的预主密钥（Pre-master），并用证书公钥加密，发送给服务器并携带客户端为密钥交换提供的所有信息。这个消息受协商的密码套件的影响，内容随着不同的协商密码套件而不同。

此时客户端已经获取全部的计算协商密钥需要的信息: 两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master，然后得到协商密钥(用于之后的消息加密)

图中使用的是 ECDHE 算法，ClientKeyExchange 传递的是 DH 算法的客户端参数，如果使用的是 RSA 算法则此处应该传递加密的预主密钥

通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信

Finished 消息意味着握手已经完成。消息内容将加密，以便双方可以安全地交换验证整个握手完整性所需的数据。

这个消息包含 verify_data 字段，它的值是握手过程中所有消息的散列值。这些消息在连接两端都按照各自所见的顺序排列，并以协商得到的主密钥 (enc_key) 计算散列。这个过程是通过一个伪随机函数（pseudorandom function，PRF）来完成的，这个函数可以生成任意数量的伪随机数据。

两端的计算方法一致，但会使用不同的标签（finished_label）：客户端使用 client finished，而服务器则使用 server finished。

因为 Finished 消息是加密的，并且它们的完整性由协商 MAC 算法保证，所以主动网络攻击者不能改变握手消息并对 vertify_data 的值造假。在 TLS 12 版本中，Finished 消息的长度默认是 12 字节（96 位），并且允许密码套件使用更长的长度。在此之前的版本，除了 SSL 3 使用 36 字节的定长消息，其他版本都使用 12 字节的定长消息。

服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数 random_C 和 random_S，同样计算得到协商密钥: enc_key = PRF(Pre_master, "master secret", random_C + random_S) ;

同样计算之前所有收发信息的 hash 值，然后用协商密钥解密客户端发送的 verify_data_C，验证消息正确性;

服务端验证通过之后，服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信（图中多了一步 New Session Ticket，此为会话票证，会在会话恢复中解释）;

服务器也结合所有当前的通信参数信息生成一段数据 (verify_data_S) 并采用协商密钥 session secret (enc_key) 与算法加密并发送到客户端;

客户端计算所有接收信息的 hash 值，并采用协商密钥解密 verify_data_S，验证服务器发送的数据和密钥，验证通过则握手完成;

开始使用协商密钥与算法进行加密通信。

HTTPS 通过 TLS 层和证书机制提供了内容加密、身份认证和数据完整性三大功能。加密过程中，需要用到非对称密钥交换和对称内容加密两大算法。

对称内容加密强度非常高，加解密速度也很快，只是无法安全地生成和保管密钥。在 TLS 协议中，最后的应用数据都是经过对称加密后传输的，传输中所使用的对称协商密钥(上文中的 enc_key)，则是在握手阶段通过非对称密钥交换而来。常见的 AES-GCM、ChaCha20-Poly1305，都是对称加密算法。

非对称密钥交换能在不安全的数据通道中，产生只有通信双方才知道的对称加密密钥。目前最常用的密钥交换算法有 RSA 和 ECDHE。

RSA 历史悠久，支持度好，但不支持 完美前向安全 - PFS(Perfect Forward Secrecy) ；而 ECDHE 是使用了 ECC（椭圆曲线）的 DH（Diffie-Hellman）算法，计算速度快，且支持 PFS。

在 PKI 体系 一节中说明了仅有非对称密钥交换还是无法抵御 MITM 攻击的，所以需要引入了 PKI 体系的证书来进行身份验证，其中服务端非对称加密产生的公钥会放在证书中传给客户端。

在 RSA 密钥交换中，浏览器使用证书提供的 RSA 公钥加密相关信息，如果服务端能解密，意味着服务端拥有与公钥对应的私钥，同时也能算出对称加密所需密钥。密钥交换和服务端认证合并在一起。

在 ECDH 密钥交换中，服务端使用私钥 (RSA 或 ECDSA) 对相关信息进行签名，如果浏览器能用证书公钥验证签名，就说明服务端确实拥有对应私钥，从而完成了服务端认证。密钥交换则是各自发送 DH 参数完成的，密钥交换和服务端认证是完全分开的。

可用于 ECDHE 数字签名的算法主要有 RSA 和 ECDSA - 椭圆曲线数字签名算法 ，也就是目前密钥交换 + 签名有三种主流选择:

比如我的网站使用的加密套件是 ECDHE_RSA，可以看到数字签名算法是 sha256 哈希加 RSA 加密，在 PKI 体系 一节中讲了签名是服务器信息摘要的哈希值加密生成的

内置 ECDSA 公钥的证书一般被称之为 ECC 证书，内置 RSA 公钥的证书就是 RSA 证书。因为 256 位 ECC Key 在安全性上等同于 3072 位 RSA Key，所以 ECC 证书体积比 RSA 证书小，而且 ECC 运算速度更快，ECDHE 密钥交换 + ECDSA 数字签名是目前最好的加密套件

以上内容来自本文: 开始使用 ECC 证书

关于 ECC 证书的更多细节可见文档: ECC Cipher Suites for TLS - RFC4492

使用 RSA 进行密钥交换的握手过程与前面说明的基本一致，只是没有 ServerKeyExchange 消息，其中协商密钥涉及到三个参数 (客户端随机数 random_C、服务端随机数 random_S、预主密钥 Premaster secret)，

其中前两个随机数和协商使用的算法是明文的很容易获取，最后一个 Premaster secret 会用服务器提供的公钥加密后传输给服务器 (密钥交换)，如果这个预主密钥被截取并破解则协商密钥也可以被破解。

RSA 算法的细节见: wiki 和 RSA算法原理（二）- 阮一峰

RSA 的算法核心思想是利用了极大整数 因数分解 的计算复杂性

而使用 DH(Diffie-Hellman) 算法 进行密钥交换，双方只要交换各自的 DH 参数(在 ServerKeyExchange 发送 Server params，在 ClientKeyExchange 发送 Client params)，不需要传递 Premaster secret，就可以各自算出这个预主密钥

DH 的握手过程如下，大致过程与 RSA 类似，图中只表达如何生成预主密钥:

服务器通过私钥将客户端随机数 random_C，服务端随机数 random_S，服务端 DH 参数 Server params 签名生成 signature，然后在 ServerKeyExchange 消息中发送服务端 DH 参数和该签名；

客户端收到后用服务器给的公钥解密验证签名，并在 ClientKeyExchange 消息中发送客户端 DH 参数 Client params；

服务端收到后，双方都有这两个参数，再各自使用这两个参数生成预主密钥 Premaster secret，之后的协商密钥等步骤与 RSA 基本一致。

关于 DH 算法如何生成预主密钥，推荐看下 Wiki 和 Ephemeral Diffie-Hellman handshake

其核心思想是利用了 离散对数问题 的计算复杂性

算法过程可以抽象成下图:

双方预先商定好了一对 P g 值 (公开的)，而 Alice 有一个私密数 a(非公开，对应一个私钥)，Bob 有一个私密数 b(非公开，对应一个私钥)

对于 Alice 和 Bob 来说通过对方发过来的公钥参数和自己手中的私钥可以得到最终相同的密钥

而第三方最多知道 P g A B，想得到私钥和最后的密钥很困难，当然前提是 a b P 足够大 (RFC3526 文档中有几个常用的大素数可供使用)，否则暴力破解也有可能试出答案，至于 g 一般取个较小值就可以

如下几张图是实际 DH 握手发送的内容:

可以看到双方发给对方的参数中携带了一个公钥值，对应上述的 A 和 B

而且实际用的加密套件是 椭圆曲线 DH 密钥交换 (ECDH) ，利用由椭圆曲线加密建立公钥与私钥对可以更进一步加强 DH 的安全性，因为目前解决椭圆曲线离散对数问题要比因式分解困难的多，而且 ECC 使用的密钥长度比 RSA 密钥短得多(目前 RSA 密钥需要 2048 位以上才能保证安全，而 ECC 密钥 256 位就足够)

关于 椭圆曲线密码学 - ECC ，推荐看下 A Primer on Elliptic Curve Cryptography - 原文 - 译文

尽管可以选择对任意一端进行身份验证，但人们几乎都启用了对服务器的身份验证。如果服务器选择的套件不是匿名的，那么就需要在 Certificate 消息中跟上自己的证书。

相比之下，服务器通过发送 CertificateRequest 消息请求对客户端进行身份验证。消息中列出所有可接受的客户端证书。作为响应，客户端发送自己的 Certificate 消息（使用与服务器发送证书相同的格式），并附上证书。此后，客户端发送 CertificateVerify 消息，证明自己拥有对应的私钥。

只有已经过身份验证的服务器才被允许请求客户端身份验证。基于这个原因，这个选项也被称为相互身份验证（mutual authentication）。

在 ServerHello 的过程中发出，请求对客户端进行身份验证，并将其接受的证书的公钥和签名算法传送给客户端。

它也可以选择发送一份自己接受的证书颁发机构列表，这些机构都用其可分辨名称来表示:

在 ClientKeyExchange 的过程中发出，证明自己拥有的私钥与之前发送的客户端证书中的公钥匹配。消息中包含一条到这一步为止的所有握手消息的签名：

最初的会话恢复机制是，在一次完整协商的连接断开时，客户端和服务器都会将会话的安全参数保存一段时间。希望使用会话恢复的服务器为会话指定唯一的标识，称为会话 ID(Session ID)。服务器在 ServerHello 消息中将会话 ID 发回客户端。

希望恢复早先会话的客户端将适当的 Session ID 放入 ClientHello 消息，然后提交。服务器如果同意恢复会话，就将相同的 Session ID 放入 ServerHello 消息返回，接着使用之前协商的主密钥生成一套新的密钥，再切换到加密模式，发送 Finished 消息。

客户端收到会话已恢复的消息以后，也进行相同的操作。这样的结果是握手只需要一次网络往返。

Session ID 由服务器端支持，协议中的标准字段，因此基本所有服务器都支持，服务器端保存会话 ID 以及协商的通信信息，占用服务器资源较多。

用来替代服务器会话缓存和恢复的方案是使用会话票证（Session ticket）。使用这种方式，除了所有的状态都保存在客户端（与 HTTP Cookie 的原理类似）之外，其消息流与服务器会话缓存是一样的。

其思想是服务器取出它的所有会话数据（状态）并进行加密 (密钥只有服务器知道)，再以票证的方式发回客户端。在接下来的连接中，客户端恢复会话时在 ClientHello 的扩展字段 session_ticket 中携带加密信息将票证提交回服务器，由服务器检查票证的完整性，解密其内容，再使用其中的信息恢复会话。

这种方法有可能使扩展服务器集群更为简单，因为如果不使用这种方式，就需要在服务集群的各个节点之间同步会话。

Session ticket 需要服务器和客户端都支持，属于一个扩展字段，占用服务器资源很少。

jdk16不支持TLS12 最多只能支持到TLS11

从17版本开始支持TLS12

具体的版本对应关系参考http://ryesuncom/jdk_tlshtml

通过这篇文章了解：

- 在TLS握手过程中到底发生了什么？

- TLS使用什么加密算法来保护数据？

- 客户端和服务器如何交换密匙？

- Diffie-Hellman Ephemeral密钥交换如何工作？

- 为什么我们需要一个数字证书？

- 为什么它需要由证书机构签署？

- 什么是数字签名？它是如何被签署和验证的？

- 完美前向保密意味着什么？

- AEAD、MAC、HKDF、0-RTT如何工作？

- 什么是椭圆曲线加密法？

- 与TLS 12相比，TLS 13有什么新内容？

SSL是安全套接字的缩写，是TLS的前身。

TLS是传输层安全的缩写，是一种加密协议，为计算机网络提供安全通信。

当然，除了传输层安全协议，还有二层隧道技术PPTP\L2TP,三层安全协议IPSec，应用层有安全协议S-HTTP,电子邮件软件加密包PGP，安全的电子交易SET等。

SSL20 在2011年已经废弃。

SSL30 在2015年已经废弃。

最近，2020年3月，TLS10 和 TLS11也已经废弃，所以，现在只有TLS 12 和 TLS13

最初，TLS广泛用在web服务。所有使用HTTPS的web服务都是使用TLS。

同样的，使用SMTPS协议的email 实际上就是SMPT 和TLS

FTPS 也是 FTP + TLS等等。

因为通过TLS可以帮助我们：

- 认证

○ TLS验证通信双方的身份，通常是客户端和服务器。

○ 在对称加密技术的帮助下，TLS确保我们将进入真实的网站，而不是一个假的网站。

- 保密性

○ TLS使用对称秘钥对数据进行加密传输。

- 诚信

TLS通过检查信息验证码在识别传输过程中的任何改动。

TLS由两个阶段/协议组成，

- 握手协议

○ 协商协议版本

○ 选择加密算法（密码套件）

○ 通过非对称加密技术认证彼此

○ 建立共享密码，用于下个阶段的对称加密

- 记录协议

○ 所有发出的消息都使用握手阶段建立的共享秘钥加密。

○ 加密消息传输到另一端。

○ 接收数据者将会验证传输过程中是否有篡改。

○ 如果没有，消息将使用相同的对称秘钥解密。

所以，通过TLS可以实现消息的保密性和完整性。

为什么不只是使用一个呢？

因为对称加密技术无法提供认证。

因为客户端和服务器都只有一个秘钥，对对方一无所知，无法验证。更不用说他们如何在不泄漏给公众的情况下得到相同的秘钥。

那如果只使用非对称技术呢？

因为非对称加密比对称加密慢得多。对称加密速度是非对称加密的100倍甚至1000倍。因此，非对称加密技术不适用于批量加密。

网络安全篇，面对复杂多变的网络环境，我们需要掌握哪些关于网络安全的相关知识，聊一聊与网络安全相关的：HTTPS、SSL、TLS 等。

《 网络安全 — HTTPS 》

《 网络安全的基石（上）— 加密 》

《 网络安全的基石（下）— 完整性与身份认证 》

《 公钥信任问题 — 数字证书与 CA 》

《 信任始于握手 — TLS 连接过程详解 》

《TLS 13 特性解析》

《 如何优化 HTTPS 连接 》- 待完善

早在 2013 年，IETF（互联网工程小组） 就对 TLS 12 的过时设计和两次往返开销心生不满，因此开始着手准备新版本的 TLS。同年 8 月由 Eirc Rescorla 提议出新版本 TLS 的 功能愿望清单 。在经过一番 辩论 后，最终该提议内容被定义为 TLS 13。推动 TLS 13 设计的主要问题大概有：

终于在 2018 年 8 月 10 日，历经 4 年时间，TLS 13 最终版本发布了 — RFC-8446 。新的协议使得互联网变得更快、更安全；随着 TLS 13 的采用率不断提高，它势必会长远影响互联网的发展；同时尽快将 TLS 13 平滑应用到线上环境无疑是势在必行。

不过在这之前， TLS 12 的应用也已经有 10 年（2008 年）的时间了，毕竟历经了种种考验，新的协议在推广和部署上必定会带来新的挑战。接下来我们就来看看新版本的 TLS 是如何做的？

由于 TLS 11/12 等协议已经出现了很多年，很多应用软件、中间代理（Middlebox）只认老的记录协议格式，更新改造很困难，甚至僵化。

可部署性

正式由于这些中间代理/软件（Middlebox）在新的更改中表现不佳，即使是对 TLS 13 协议的细微更改（例如消除冗余的 ChangeCipherSpec 消息，版本号从 0x03 升级为 0x04），也最终导致了某些设备的连接失败问题。这也是 TLS 13 从草稿到最终发布花费了这么长时间的重要原因之一。

为了保证这些被广泛部署的“旧设备”能够继续使用，TLS 13 不得不做出妥协，通过“伪装”来实现兼容：保持现有的记录格式不变，使得 TLS 13 看上去“像是” TLS 12。

扩展协议

那么，如何区分是 12 还是 13 呢？

这里用到一个新的 扩展协议 （Extension Protocol），它有点“补充条款”的意思，通过在记录末尾添加一系列的“扩展字段”来增加新的功能，旧版本的 TLS 不认识它可以直接忽略，这就实现了“向后兼容”。

TLS 13 正是利用扩展实现了许多重要的功能，比如 “supported_groups” “key_share” “signature_algorithms” “server_name” 等。

在经历十余年的实践中获得许多宝贵经验的 TLS 12 陆续发现了很多的漏洞和加密算法的弱点。因此消除潜在的危险设计来纠正以前的错误成为 TLS 13 的设计目标之一。所以新版本的 TLS 协议里要修补这些不安全的因素。

例如：

固定密钥交换

经过这样一番“减肥瘦身”之后，TLS 13 的密钥交换算法只有 ECDHE 和 DHE 了，关于椭圆曲线（ECC）也被“砍”到只剩 P-256 和 x25519 等 5 种。

首先来说下废除 RSA 和 DH 密钥交换算法的原因：

由于客户端默认会选择 ECDHE 而非 RSA 做密钥交换，这是因为它不具有“ 前向安全 ”（Forward Secrecy）：“假设有人长期记录了加密的数据，然后在后续的某个时间段获得了服务器的 RSA 私钥，那么黑客就能够使用该私钥解密出之前所有报文的 “Pre-Master”，再计算出会话密钥，破解所有密文。这便是 今日截获，明日破解 ”

而 ECDHE 算法在每次握手时都会生成一对临时公钥和私钥，每次通信的秘钥对都是不同的，也就是“一次一密”，即使黑客花大力气破解了这一次的会话密钥，也只是这次通信被攻击，之前的历史消息不会受到影响，仍然是安全的。

所以现在主流的服务器和客户端在握手阶段都已经不再使用 RSA，改用 ECDHE，而 TLS 13 在协议里明确废除了 RSA 和 DH 则在标准层面保证了“前向安全”。

固定密码

多年以来，密钥交换机制不是唯一引起安全漏洞的部分，对称密钥部分也有相当一部分问题。

同样，用于对称加密的算法在经过“减肥瘦身”之后也只保留了 AES、ChaCha20 ，分组模式只能用 AEAD 的 GCM、CCM 和 Poly1305，摘要算法也只能用 SHA 256、SHA 384。

这样原来众多的加密算法、参数组合导致密码套件非常复杂，难以选择。而经过瘦身之后的 TLS 13 只剩下 5 个套件，使得客户端或服务端在选择密码套件时变得“更加容易”。然而更重要的是，这些算法在 TLS 长期的实践过程中先后已经被证实是构成不安全的因素，从而导致安全漏洞。

修复数字签名

经过前面的学习，相信你也知道 TLS 另一个重要部分是身份验证。在每个连接中服务都是用具有公钥的数字证书向客户端提供身份认证。在 RSA 加密模式下，服务器通过解密预主密钥并通过对话记录计算 MAC 来证明其对私钥的所有权。在 Diffie-Hellman 模式下，服务器使用数字签名来证明私钥的所有权。

在 TLS 12 和更早的版本中，服务器的签名仅涵盖部分握手。用于协商使用哪种对称密码的部分没有由私钥签名。这也导致许多引人注目的漏洞 FREAK ， LogJam 等。而在 TLS 13 由于服务器对整个握手记录进行签名，因此可以避免这些情况。

HTTPS 建立连接时除了要做 TCP 握手，还要做 TLS 握手，在 TLS 12 中会多花两个消息往返（2 - RTT），这可能导致几十毫秒甚至上百毫秒的延迟，在移动网络中延迟还会更严重。

1-RTT 模式

密码套件的大幅度简化，也就没有必要再像以前那样走复杂的的协商流程了。TLS 13 压缩了以前的 “Hello” 协商过程，删除了 “Key Exchange” 消息，把握手时间减少到了 “1-RTT”，效率提高了一倍。

下面是 TLS 13 握手过程的简图，注意与前面介绍的 TLS 12 对比区别在哪里。

0-RTT 恢复

除了标准的 “1-RTT” 握手，受 QUIC 协议的启发，客户端可以在其第一条消息中将加密的数据发送到服务器，与未加密的 HTTP 相比，没有额外的延迟成本。

在 TLS 12 中，有两种恢复连接的方法：会话 ID 和会话 Ticket，而 13 则将他们组合在一起形成称为 PSK（pre-shared key，预共享密钥）恢复的新模式。

握手分析

目前 Nginx 等 Web 服务器都能够很好的支持 TLS 13，但是要求底层的 OpenSSL 必须是 111。因此如果要部署需要先升级你的 OpenSSL 版本。

首先TCP 建立连接之后，浏览器首先还是发一个 “ Client Hello ”。

由于 13 的消息要兼容 12，所以开头的版本号、支持的密码套件和随机数（Client Random）结构都是一样的（这时的随机数是 32 个字节）。

注意 “Client Hello” 里的扩展，“ supported_versions ” 表示这是 TLS 13，“ supported_groups ” 是支持的曲线，“ key_share ”是曲线对应的参数。

这有点是像是“有话尽量一口气说完”，还是按照老规矩进行“打招呼”，我这边有这些信息，考虑到版本升级，所以附带了一些信息，可能后面会用到。

服务器收到 “Client Hello” 同样返回 “Server Hello” 消息，还是要给出一个 随机数 （Server Random）和选定密码套件。

表面上看 Version 和 TLS 12 是一样的，重点是后面的扩展。“ supported_versions ” 里确认使用的是 TLS 13，然后在 “ key_share ” 扩展带上曲线和对应的公钥参数。

服务器的回应还是老套路，服务端对客户端的提供的信息作出选择，另外服务端还要再附加上几个参数，这次加密就协商定了。

可以看到相比 TLS 12 的握手过程，TLS 13 仅用两条消息就共享了 4 个信息： Client Random 和 Server Random 、 Client Params 和 Server Params 。两边就可以各自用 DH 算出 “ Pre-Master ”，再用 HKDF 生成主密钥 “ Master Secret ”，效率比 TLS 12 提高了一大截。

在计算出主密钥后，服务器立刻发出 “ Change Cipher Spec ” 消息，比 TLS 12 提早进入加密通信，后面的证书等就都是加密的了，减少握手时明文信息泄露。

TLS 13 还多了一个 “ Change Cipher Spec ” 消息，服务器用私钥把前面的曲线、套件、参数等握手数据加了签名，作用和 “ Finished ” 消息差不多。但由于是私钥签名，所以强化了身份认证和防篡改。

两个“打招呼”消息之后，客户端验证服务器证书，再发 “Finished” 消息，就正式完成了握手，开始收发 HTTP 报文。

现在已经有很多网站都支持了 TLS 13，例如 GitHub ：

今天我们主要介绍了 TLS 13 的一些新特性，简单总结下来主要包含下面几点：

TLS 13 涉及的内容很多，有关它的更详细信息请去参照 RFC-8446 ，关于这部分大家还有哪些要分享的呢？欢迎您的留言或指正。

网络安全系列专题

扩展阅读