TLs握手过程5次握手过程

扫码添加渲大师小管家，免费领取渲染插件、素材、模型、教程合集大礼包！

大家好，今天来介绍TLs握手过程5次握手过程(请教意思是什么)的问题，以下是渲大师小编对此问题的归纳和整理，感兴趣的来一起看看吧！

HTTPS握手过程

我很早之前写过一篇关于 HTTP 和 HTTPS 的文章，但对于 HTTPS 介绍还不够详细，只讲了比较基础的部分，所以这次我们再来深入一下 HTTPS，用 实战抓包 的方式，带大家再来窥探一次 HTTPS。

对于还不知道对称加密和非对称加密的同学，你先复习我以前的这篇文章 「硬核！30 张图解 HTTP 常见的面试题」， 本篇文章默认大家已经具备了这些知识。

HTTP 由于是明文传输，所谓的明文，就是说客户端与服务端通信的信息都是肉眼可见的，随意使用一个抓包工具都可以截获通信的内容山闹。

所以安全上存在以下三个风险：

HTTP S 在 HTTP 与 TCP 层之间加入了 TLS 协议，来解决上述的风险。

[图片上传失败...(image-93bbca-1618813708342)]

TLS 协议是如何解决 HTTP 的风险的呢？

可见，有了 TLS 协议，能保证 HTTP 通信是安全的了，那么在进行 HTTP 通信前，需要先进行 TLS 握手。TLS 的握手过程，如下图：

上图简要概述来 TLS 的握手过程，其中每一个「框」都是一个记录（ record ），记录是 TLS 收发数据的基本单位，类似于 TCP 里的 segment。多个记录可以组合成一个 TCP 包发送，所以 通常经过「四个消息」就可以完成 TLS 握手，也就是需要 2个 RTT 的时延 ，然后就可以在安全的通信环境里发送 HTTP 报文，实现 HTTPS 协议。

所以可以发现，HTTPS 是应用层协议，需要先完成 TCP 连接建立，然后走 TLS 握手过程后，才能建立通信安全的连接。

事实上，不同的密钥交换算法，TLS 的握手过程可能会有一些区别。

这里先简单介绍下密钥交换算法，因为考虑到性能的问题，所以双方在加密应用信息时使用的是对称加密密钥，而对衫源称加密密钥是不能被泄漏的，为了保证对称加密密钥的安全性，所以使用非对称加密的方式来保护对称加密密钥的协商，这个工作就是密钥交换算法负责的。

接下来，我们就以最简单的 RSA 密钥交换算法，来看看它的 TLS 握手过程。

传统的 TLS 握手基本都是使用 RSA 算法来实现密钥交换的，在将 TLS 证书部署服务端时，证书文件中包含一对公私钥，其中公钥会在 TLS 握手阶段传递给客户端，私钥则一直留在服务端，一定要确保私钥不能被窃取。

在 RSA 密钥协商算法中，客户端会生成随机密钥，并使用服务端的公钥加密后再传给服务端。根据非对称加密算法，公钥加密的消息仅能通过私或唯态钥解密，这样服务端解密后，双方就得到了相同的密钥，再用它加密应用消息。

我用 Wireshark 工具抓了用 RSA 密钥交换的 TLS 握手过程，你可以从下面看到，一共经历来四次握手：

对应 Wireshark 的抓包，我也画了一幅图，你可以从下图很清晰地看到该过程：

那么，接下来针对每一个 TLS 握手做进一步的介绍。

客户端首先会发一个「 Client Hello 」消息，字面意思我们也能理解到，这是跟服务器「打招呼」。

消息里面有客户端使用的 TLS 版本号、支持的密码套件列表，以及生成的 随机数（ Client Random），这个随机数会被服务端保留，它是生成对称加密密钥的材料之一。

当服务端收到客户端的「Client Hello」消息后，会确认 TLS 版本号是否支持，和从密码套件列表中选择一个密码套件，以及生成 随机数（ Server Random）。

接着，返回「 Server Hello 」消息，消息里面有服务器确认的 TLS 版本号，也给出了随机数（Server Random），然后从客户端的密码套件列表选择了一个合适的密码套件。

可以看到，服务端选择的密码套件是 “Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256”。

这个密码套件看起来真让人头晕，好一大串，但是其实它是有固定格式和规范的。基本的形式是「 密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法 」， 一般 WITH 单词前面有两个单词，第一个单词是约定密钥交换的算法，第二个单词是约定证书的验证算法。比如刚才的密码套件的意思就是：

就前面这两个客户端和服务端相互「打招呼」的过程，客户端和服务端就已确认了 TLS 版本和使用的密码套件，而且你可能发现客户端和服务端都会各自生成一个随机数，并且还会把随机数传递给对方。

那这个随机数有啥用呢？其实这两个随机数是后续作为生成「会话密钥」的条件，所谓的会话密钥就是数据传输时，所使用的对称加密密钥。

然后，服务端为了证明自己的身份，会发送「 Server Certificate 」给客户端，这个消息里含有数字证书。

随后，服务端发了「 Server Hello Done 」消息，目的是告诉客户端，我已经把该给你的东西都给你了，本次打招呼完毕。

在这里刹个车，客户端拿到了服务端的数字证书后，要怎么校验该数字证书是真实有效的呢？

在说校验数字证书是否可信的过程前，我们先来看看数字证书是什么，一个数字证书通常包含了：

那数字证书的作用，是用来认证公钥持有者的身份，以防止第三方进行冒充。说简单些，证书就是用来告诉客户端，该服务端是否是合法的，因为只有证书合法，才代表服务端身份是可信的。

我们用证书来认证公钥持有者的身份（服务端的身份），那证书又是怎么来的？又该怎么认证证书呢？

为了让服务端的公钥被大家信任，服务端的证书都是由 CA （ Certificate Authority ，证书认证机构）签名的，CA 就是网络世界里的公安局、公证中心，具有极高的可信度，所以由它来给各个公钥签名，信任的一方签发的证书，那必然证书也是被信任的。

之所以要签名，是因为签名的作用可以避免中间人在获取证书时对证书内容的篡改。

如下图图所示，为数字证书签发和验证流程：

CA 签发证书的过程，如上图左边部分：

客户端校验服务端的数字证书的过程，如上图右边部分：

但事实上，证书的验证过程中还存在一个证书信任链的问题，因为我们向 CA 申请的证书一般不是根证书签发的，而是由中间证书签发的，比如百度的证书，从下图你可以看到，证书的层级有三级：

对于这种三级层级关系的证书的验证过程如下：

在这四个步骤中，最开始客户端只信任根证书 GlobalSign Root CA 证书的，然后 “GlobalSign Root CA” 证书信任 “GlobalSign Organization Validation CA - SHA256 - G2” 证书，而 “GlobalSign Organization Validation CA - SHA256 - G2” 证书又信任 baidu.com 证书，于是客户端也信任 baidu.com 证书。

总括来说，由于用户信任 GlobalSign，所以由 GlobalSign 所担保的 baidu.com 可以被信任，另外由于用户信任操作系统或浏览器的软件商，所以由软件商预载了根证书的 GlobalSign 都可被信任。

操作系统里一般都会内置一些根证书，比如我的 MAC 电脑里内置的根证书有这么多：

这样的一层层地验证就构成了一条信任链路，整个证书信任链验证流程如下图所示：

最后一个问题，为什么需要证书链这么麻烦的流程？Root CA 为什么不直接颁发证书，而是要搞那么多中间层级呢？

这是为了确保根证书的绝对安全性，将根证书隔离地越严格越好，不然根证书如果失守了，那么整个信任链都会有问题。

客户端验证完证书后，认为可信则继续往下走。接着，客户端就会生成一个新的 随机数 ( pre-master) ，用服务器的 RSA 公钥加密该随机数，通过「 Change Cipher Key Exchange」消息传给服务端。

服务端收到后，用 RSA 私钥解密，得到客户端发来的随机数 (pre-master)。

至此， 客户端和服务端双方都共享了三个随机数，分别是 Client Random、Server Random、pre-master 。

于是，双方根据已经得到的三个随机数，生成 会话密钥（Master Secret） ，它是对称密钥，用于对后续的 HTTP 请求/响应的数据加解密。

生成完会话密钥后，然后客户端发一个「 Change Cipher Spec 」，告诉服务端开始使用加密方式发送消息。

然后，客户端再发一个「 Encrypted Handshake Message（Finishd） 」消息，把之前所有发送的数据做个摘要，再用会话密钥（master secret）加密一下，让服务器做个验证，验证加密通信是否可用和之前握手信息是否有被中途篡改过。

可以发现，「Change Cipher Spec」之前传输的 TLS 握手数据都是明文，之后都是对称密钥加密的密文。

服务器也是同样的操作，发「 Change Cipher Spec 」和「 Encrypted Handshake Message 」消息，如果双方都验证加密和解密没问题，那么握手正式完成。

最后，就用「会话密钥」加解密 HTTP 请求和响应了。

使用 RSA 密钥协商算法的最大问题是不支持前向保密 。因为客户端传递随机数（用于生成对称加密密钥的条件之一）给服务端时使用的是公钥加密的，服务端收到到后，会用私钥解密得到随机数。所以一旦服务端的私钥泄漏了，过去被第三方截获的所有 TLS 通讯密文都会被破解。

为了解决这一问题，于是就有了 DH 密钥协商算法，这里简单介绍它的工作流程。

客户端和服务端各自会生成随机数，并以此作为私钥，然后根据公开的 DH 计算公示算出各自的公钥，通过 TLS 握手双方交换各自的公钥，这样双方都有自己的私钥和对方的公钥，然后双方根据各自持有的材料算出一个随机数，这个随机数的值双方都是一样的，这就可以作为后续对称加密时使用的密钥。

DH 密钥交换过程中， 即使第三方截获了 TLS 握手阶段传递的公钥，在不知道的私钥的情况下，也是无法计算出密钥的，而且每一次对称加密密钥都是实时生成的，实现前向保密 。

但因为 DH 算法的计算效率问题，后面出现了 ECDHE 密钥协商算法，我们现在大多数网站使用的正是 ECDHE 密钥协商算法，关于 ECDHE 握手的过程，将在下一篇揭晓，尽情期待哦。

请教SSL/TLS的握手过程

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

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

TLS加密过程

## SSL 证书类型

certbot

域名验证（domain validated, DV证书）

组织验证（organization validated,OV 证书）：验证组织是否正确

扩展验证（extended validation EV证书）：显示友好

根证书-》二级证书-》主站点

## TLS加密过程

1. 验证身份

2. 达成安全套件共识

3. 传递密钥

4. 加密通讯

HTTPS采用混合加密算法，即共享秘钥加密（对称加密）和公开秘钥加密（非对称加密）。

通信前准备工作：

A、数字证书认证机构的公开秘钥（CA公钥）已事先植入到浏览器里；

B、数字证书认证机构用自己的私有密钥对服务器的公开秘钥做数字签名，生成公钥证书，并颁发给服务器。

1、client hello

握手第一步是客户端向服务端发送 Client Hello 消息，这个消息里包含了一个客户端生成的随机数 Random1、客户端支持的加密套件（Support Ciphers）和 SSL Version 等信息。

2、server hello

服务端向客户端发庆笑渗送 Server Hello 消息，这个消息会从 Client Hello 传过来的 Support Ciphers 里确定一份加密套件，这个套件决定了后续加密和生成摘要时具体使用哪些算法，另外还会生成一份随机数 Random2。注意，至此客户端和服务端都拥誉脊有了两个随机数（Random1+ Random2），这两个随机数会在后续生成对称秘钥时用到。

3、Certificate

这一步是服务端将自己的公钥证书下发给客户端。

4、Server Hello Done

Server Hello Done 通知客户端 Server Hello 过程结束。

5、Certificate Verify

客户端收到服务端传来的公钥证书后，先从 CA 验证该证书的合法性（CA公钥去解密公钥证书），验证通过后取出证书中的服务端公钥，再生成一个随机数 Random3，再用服务端公钥非对称加密 Random3生成 PreMaster Key。

6、Client Key Exchange

上面客户端根据服务器传来的公钥生成了 PreMaster Key，Client Key Exchange 就是将这个 key 传给服务端，服务端再用自己的私钥解出这个 PreMaster Key 得到客户端生成的 Random3。至此，客户端和服务端都拥有 Random1 + Random2 + Random3，两边再根据同样的算法就可以生成一份秘钥，握手结束后的应用层数据都是使用这个秘钥进行对称加密。

为什么要使用三个随机数呢？这是因为 SSL/TLS 握手过程的数据都是明文传输的升橡，并且多个随机数种子来生成秘钥不容易被破解出来。

HTTPS协议的SSL握手过程

HTTPS常被定义为为 HTTP over SSL ，超文本传输安全协议。
以往HTTP通讯直接使用的明文传输，容易被人抓包，破解数据包，而 HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包。

HTTP的URL由“http://”起始且默认使用端口80，
HTTPS的URL由“https://”起始且岁祥默认使用端口443。

注意：

SSL是一个介于HTTP协议与TCP之间的一个可选层，为数据通讯提供安全支持。SSL协议可分为两层：

如果用右边的TCP/IP协议来划分，SSL是属于应用层与传输层之间的协议，如果还是用OSI七层协议划分，SSL是属于表示层与会话层的。

以下是SSL协议握手的一个主要过程，主要分为4个阶段。

此时，client和server都持有3个随机数，客户端和服务端用商定的算法利用3个随机数生成一个 对话密钥（session key） ，随后的通信就用这个密钥进行加密解密。之所以用3个随机数，因为证书是静态的，增加随机数可以使得密钥更加有随机性。SSL协议传输过程中，使用的是由相同的3个随机数生成的 对话密钥（session key） ，而生成的规则是client与server商议好的算法，所以这个 对话密钥（session key） 是相同的，这个加密方法称为 对称加密 。

HTTPS通讯也不一定是绝对安全的，有可能会被人劫持，如路由，代理，防火墙，通常是中间人攻击。所谓中间人，就是攻击端欺骗服务端，伪造成客户端。反过来欺骗客户端，伪造成服务端。

简单过程如下

中间人攻击一般发生在SSL握手协议中，协商密钥的时候（非对称加密阶段），中间人攻击的主要目的是要欺骗客户端，与客户端协商生成最后的对话密钥（3个随机数生成），这样客户端的数据经过这个对话密钥加密后，就可以被中间人轻易解密出来。所以中间人攻击必须得使用自己证书（包含公钥）进行握手，这样才能有自己的私钥解密出客户端发过来的随机数。

如果客户端与服务端会话初始化完成，开始进行数据通讯（对称加密阶段），想要完成中间人攻击是非常困难的。

防御中间人攻击的手段是做好证书的校验，一般来说，客户端收到了服务端下发的证书，对证书的颁发机构、有效期等进行严格校验（证书是验证服务端身份合法与否的唯一方式）:

Charles其实是扮演一个中间人的角色，就是上述的中间人攻击。客户端选择信任并安装Charles的慎李CA证书，否则客户端就会“乎孝搏报警”并中止连接。这样看来，HTTPS还是很安全的。
大概示例图如下

如果需要App进行抓包调试，一般需要设置Mode为AFSSLPinningModeNone。

加密和解密可以使用不同的规则，只要这两种规则之间存在某种对应关系即可，这样就避免了直接传递密钥。这种加密模式被称为"非对称加密算法"。RSA算法一直是最广为使用的"非对称加密算法"，2048位的密钥极其安全。SSL握手过程，客户端使用服务端的公钥解密随机数，服务端使用私钥解密出随机数的过程就是非对称加密。

http://www.nsfocus.net/index.php?act=magazine&do=view&mid=841
https://www.jianshu.com/p/9c52693a09dc
https://www.jianshu.com/p/405f9d76f8c4