前言

继（《一个陌生女人的来信》）借名著说一些网络基础知识，小玲珑打算全面梳理网络知识，这是关于网络分享的第二篇。

没有网络基础也可以看看我前面的文章~

这一篇内容是关于HTTPS握手的内容，关于传统的秘钥交换算法和基于TLS1.2椭圆曲线算法讲解数据安全可靠传输的过程，保证您能看得懂🐱‍🏍

如果真的有不懂的地方就评论区找我就好啦，下面就先看看协议发展的过程吧😉

传输层安全协议发展

TLS传输层安全协议，前生是SSL安全套接层协议。

TSL是以SSL为原型所以有时候统称为SSL协议---《图解HTTP》

传输层安全的协议发展历程可以参考这张表格，其中TSL1.0和SSL3.0相差很小很小。

现在主流的版本是 TLS/1.2, 之前的 TLS1.0、TLS1.1 都被认为是不安全的，这篇文章会说明HTTPS握手和TLS1.2以及1.3的握手过程。

协议	年份
SSL 1.0	未知
SSL 2.0	1995
SSL 3.0	1996

协议	年份
TLS 1.0	1999
TLS 1.1	2006
TLS 1.2	2008
TLS 1.3	2018

第一节.https传统的RSA握手

《图解http》中有两句话https是身披SSL外壳的http，http+加密+认证+完整性保护=https

SSL 即安全套接层（Secure Sockets Layer），在 OSI 七层模型中处于会话层(第 5 层)。之前 SSL 出过三个大版本，当它发展到第三个大版本的时候才被标准化，成为 TLS（传输层安全，Transport Layer Security），并被当做 TLS1.0 的版本，准确地说，SSL3.1=TLS1.0。

1.对称加密

记得最开始女主和男主写信吗，

女主写了10封信之后跟男主说：hey，男主，我感觉大家都可以看到我给你写的信呢。怎么办？

男主说，我也感觉到了。不如我给你一个密码，我用这个密码把信加密你用这个密码解密别人就看不到啦。

女主想好像也还可以。应该是看不到了。但是后来感觉不对啊，你给我的密码可能被别人获取呀

用同一种秘钥进行加解密。虽然信息被加密，但是这种方法秘钥可能会被获取导致信息被篡改。

得不到信息我可以得到你的密码，嘻嘻嘻。

2.非对称加密

男主：看来密码不能公开呀。既然这样的话，那我们各自拥有两个密码，一个加密，一个解密。加密秘钥公开，解密秘钥不公开。公钥加密私钥解密不就好了吗？

女主：好主意！

利用私钥和公钥，公钥进行加密，私钥进行解密。如果A向B发送数据，就用B的公钥进行加密，然后传到B后B再用私钥进行解密。同理B向A发数据，B用A的公钥进行加密，B的私钥进行解密。

但是非对称加密的方式效率太低。

女主：hey，男主。我们现在效率好慢呀，送出的信太少了。。。

男主：是啊，别急，我正在想办法。

3.两种方式结合

男主：有啦，我们可以用前两种办法结合，我先给你非对称加密传一个密码，然后再对称加密传信件。这样我们用同样的秘钥加密解密，传输的过程中别人也不会获取到我们的密码。

女主：我也是这样想的，哈哈哈，这下应该要快多了。

先用RSA非对称加密算法传输一个秘钥，最后再用这个秘钥进行通信，为什么这个秘钥不会被劫持呢？因为之前传输过一次了，现在就不用再传输。

整个过程是客户端生成一个client_random给服务器，（1）

服务器接着生成server_random和自己公钥给客户端，（2）

客户端用公钥将pre_random加密发送给服务端，（3）

服务端`私钥解密`后拿到参数，将这三个参数合形成一个秘钥；（4）

客户端也有这三个相同的参数合成一个秘钥，然后两者有了相同的秘钥后进行对称加密传输。（5）

（重点）第三步客户端用公钥加密的pre-random只有服务端的私钥才能解开。因此攻击者没有办法获取pre-randown。进而没有办法得到秘钥。

4.中间人攻击

女主以为这会信息安全了，但是没想到男主的另外一个粉丝佳佳也想给男主写信。。。

佳佳进而冒充男主和女主送信。拿到女主的信后又冒充女主与男主通信，这样男主女主都不会发现。这就是中间人攻击。

佳佳通过DNS劫持，将目标地址转换为佳佳的地址，佳佳也生成公钥和私钥，客户端向服务端发送参数（用佳佳的公钥）发到了佳佳那，佳佳用自己的私钥进行解密，和客户端进行沟通。客户端还以为佳佳就是服务器。佳佳用服务端的公钥将信息加密，发给服务端。服务端却还以为自己是和客户端通信。

如何解决这个问题？这个问题还是因为公钥是公共的。如果客户端知道收到的公钥是来自服务器不是佳佳，那么就能解决这个问题了。

5.数字证书

男主：我给你发消息的时候证明一下自己是本人，我给你一个证书吧。然后可以通过数字签名来防止证书在传送的过程中被篡改。

女主：证书我知道，就像是你的身份证一样可以证明你自己，那什么是数字签名呢有什么用？

男主：哈哈哈，我把我的公钥和个人信息用哈希算法加密形成消息摘要，hash算法加密的消息摘要是不可逆的，可以防止被中间人修改。然后消息摘要还需要通过专门的认证中心（CA）用私钥加密形成一个数字签名。

女主：既然hash算法能够防止消息摘要不被修改，为什么还要通过认证中心加密呢？那不是多次一举？

男主：哈哈，为了防止这些中间人。没办法呀，你想虽然他们不能修改消息摘要，但是可以用hash算法重新生成一个新的消息摘要。整个原始信息都被替换了呀。

女主：我明白了，中间人不修改消息摘要，直接给我一个他的消息摘要也是可以的。所以需要AC的私钥加密消息摘要。

男主：是滴，但是还没完，我还要将数字签名和（我的公钥+个人信息）结合起来形成数字证书。我把数字证书传给你，而不是传递数字签名给你。

女主：是因为我要对数字你的信息认证吧？我把的数组证书的数字签名用CA的公钥进行解密拿到消息摘要，然后把服务器的公钥通过hash算法加密形成一个消息摘要，然后对比这两个摘要是否相同？相同就表示认证通过？

男主：没错！

以上就是数字证书有关的东西：公钥+个人信息，hash算法，CA认证中心，数字签名，数字证书是否都理清楚了呢？

数字证书和数字签名千万不要混淆。

数字签名是服务端的公钥通过hash算法进行处理成为消息摘要，消息摘要再进过AC的私钥加密成为数字签名。

数字签名只是数字证书的一部分而已。数字签名属于数字证书。数字证书包含数字签名

6.整个过程

完成交流的过程其实就是上满男女主的对话。下面看看图再说一遍，加深理解。

服务器生成数字证书的过程

浏览器验证证书的过程

完整的过程

客户端向服务器发送client_random和加密方法列表，
服务器收到后向浏览器发送数字证书，server-random，选择的加密方法
客户端对数字证书中的数字签名解密，对公钥进行加密，就得到了两个消息摘要。比较两者是否相同
若比对成功相同，生成pre-random给服务器。
服务器私钥解密获取了pre-random。
服务器联合三个随机参数生成秘钥。并确认
浏览器生成秘钥
双方通过对称加密进行传输数据，happy🐱‍💻。

说明：

CA认证中心的私钥进行签名生成数字签名，数字签名要CA的公钥进行解密，那么如何保证公钥的可靠性？CA的公钥需要更牛的CA给他签名，然后形成CA证书（这个CA证书里有公钥）。

想知道这个CA证书是否可靠，就要看更牛的CA证书的公钥能够解开CA签名。这样一层层往上查找CA，直到找到全球著名的CA，也就是root CA.
为什么是三个参数？我自己的理解是首先浏览器的client-random表示浏览器向客户端发出请求，然后服务器再做出响应发出client-random。这两个参数相当于是双方互相认证。发送私密的pre-randon随机参数是为了生成不被攻击者知道的秘钥，所以要三个参数，如果觉得我的理解不对还请指正😉
上面的pre-random在一些文章书籍中叫pre-master secret，这个影响不大。

第二节：TLS1.2的握手过程

前面说过SSL 即安全套接层（Secure Sockets Layer），在 OSI 七层模型中处于会话层(第 5 层)。之前 SSL1.0,2.0设计时候发现了很多问题，没有被使用，当它发展到第三个大版本的时候才被标准化，成为 TLS（传输层安全，Transport Layer Security），TLS1.0=SSL3.0。

主要是用ECDHE椭圆曲线算法根据client_params和server_parmas生成pre_random 最后再计算出秘钥。上一节说的是传统的秘钥交换RSA算法，这些算法的原理目前真的看不懂，密码学似玄学😂

1.客户端发起加密请求

客户端发送随机数，TLS版本和加密套件列表给服务端。

一组加密套件列表里有很多个密码套件。我们那一组套件列表中的一个密码套件为例子。

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256                          (0xc02f)

TLS：表示基于TLS协议。
ECDHE：TLS/SSL 的握手过程中使用ECDHE算法生成pre-random。
RSA：TLS/SSL 的 Authentication 使用RSA 验证证书签名。
AES_128_GCM：T使用长度128位的AES算法进行对称加密。在对称加密的过程中使用主流的GCM分组模式
HA256：哈希摘要算法使用SHA256，常见到有SHA384， SHA512。
0xc02f：加密套件的标识。每个加密套件是有唯一数字作为标识的。

2.服务端做出响应

服务端发送随机数，随机参数，确认TLS版本以及一组加密套件中选择一个加密套件，以及证书给浏览器

3.客户端验证证书，生成秘钥

客户端验证证书是否通过，如果通过生成客户端的随机参数client-params。利用client-params和sever-params这两个参数，通过椭圆曲线算法生成pre-random这个随机参数。同时传递client-params给服务端。

客户端根据pre-random，server-random，client-random和椭圆曲线算法生成秘钥

4.服务端生成秘钥

服务端也根据这三个参数生成秘钥，之后就使用这个秘钥进行对称加密解密。完整过程如下：

与传统的密钥交换RSA算发的比较

验证是双向的，客户端和服务器互相认证身份
生成秘钥之后各自都会给对方一个收尾消息，告诉之后的传输都用这个秘钥进行对称加密，图中简化成一个双向箭头了。
使用椭圆曲线算法可以抢跑，也就是说当客户端给服务端一个收尾消息后可以立即发HTTP请求，不用等到服务端的收尾消息发过来再发送HTTP请求，节约了一个往返时延。也叫TLS false start。

第三节：TSL1.3的握手

现在主流的版本是 TLS/1.2, 但是在 2018 年推出了更加优秀的 TLS1.3，大大优化了 TLS 握手过程。

1.浏览器发送client-params，client-random，TSL版本和加密套件列表。

2. 服务器确认套件列表，TSL版本，数字证书，两个随机参数

3.生成秘钥

对比

在性能和安全方面看看都有哪些改进吧。

性能：在TLS1.2中是要数字证书验证通过才生成client-params。根据client-params和server-parmas计算出pre-random进而生成秘钥。 TSL1.3一开始就生成client-params传递给服务器。和 TLS 1.2 相比少了一个 RTT。

服务端不必等待对方验证证书之后才拿到client_params，而是直接在第一次握手的时候就能够拿到, 拿到之后立即计算secret，节省了之前不必要的等待时间。同时，这也意味着在第一次握手的时候客户端需要传送更多的信息，一口气给传完。
安全在 TLS1.3 中废除了非常多的加密算法，最后只保留五个加密套件:

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_GCM_8_SHA256

对称加密算法只有 AES 和 CHACHA20，之前主流的也会这两种。分组模式也只剩下 GCM 和 POLY1305, 哈希摘要算法只剩下了 SHA256 和 SHA384 了。

之前RSA这么重要的非对称加密算法怎么不在了？

第一、2015年发现了FREAK攻击，即已经有人发现了 RSA 的漏洞，能够进行破解了。

第二、一旦私钥泄露，那么中间人可以通过私钥计算出之前所有报文的secret，破解之前所有的密文。

回到 RSA 握手的过程中，客户端拿到服务器的证书后，提取出服务器的公钥，然后生成pre_random并用公钥加密传给服务器，服务器通过私钥解密，从而拿到真实的pre_random。当中间人拿到了服务器私钥，并且截获之前所有报文的时候，那么就能拿到pre_random、server_random和client_random并根据对应的随机数函数生成secret，也就是拿到了 TLS 最终的会话密钥，每一个历史报文都能通过这样的方式进行破解。

但ECDHE在每次握手时都会生成临时的密钥对，即使私钥被破解，之前的历史消息并不会收到影响。这种一次破解并不影响历史信息的性质也叫前向安全性。

RSA 算法不具备前向安全性，而 ECDHE 具备，因此在 TLS1.3 中彻底取代了RSA。

最后

参考文章：

“历史遗留”漏洞：浅析新型SSL/TLS漏洞FREAK
（建议精读）HTTP灵魂之问，巩固你的 HTTP 知识体系。TSL/1.2,1.3就是在三元大大博客学来的，握手的流程图也来自他的文章。

如果你看到了这里说明可能是喜欢这篇文章的，希望能够给你带来一丝启发与思考，下篇文章见，比心💕