刨根问底系列之https详细握手过程

前言

上一篇文章刨根问底系列之https究竟是如何防篡改的？面试必备详细解释了http为何不安全，https为何安全，并大体介绍了https通讯过程是如何加密的，以及什么是数字证书，什么是签名,若有不了解的，能够先看看上一篇文章，本篇文章主要从协议层面介绍https的详细握手过程。若是说上一篇文章是辅助你理解https的加密过程，那这一篇文章就是拿真实网络数据包来分析https的详细握手过程，若是你能和上一篇的过程一一对应上，那恭喜你，也恭喜我，你们都没有浪费时间。

进入正题以前，先解答一下上篇文章留的两个问题

1. 为何charles等抓包工具或者浏览器控制台看到的https返回是明文的？

   首先说明一下，https其实至关于http+tsl,(tsl和ssl只是不一样的版本称呼问题，暂且这么理解)，你们都知道，http是明文操做，那也就是说全部的加密解密操做都在tls这边，具体关系能够参看下面这张图

   

   浏览器是属于应用层之上的应用吧，因此浏览器控制台的输出都是已经通过tls解密过的。 那为何charles等抓包工具看到的也是明文的呢？是否是也是由于charles是应用层之上的应用呢？不尽然如此！charles在抓包过程当中是起到了中间代理的做用，浏览器=====》Charles======》服务器，charles相对于浏览器来讲，是服务端，相对于服务端来时，是客户端。charles在抓取https的包时，是须要浏览器先安装并信任本身的证书的（至关于服务器的证书），具体可看下图

   

   因此，能看出来，之因此charles能看到明文，是由于你主动信任了他的证书

2. 为何制做数字签名时须要hash一次？

   其实仔细想想，若是制做签名的时候不作hash，有什么影响吗？其实还真没有影响，仍是能正常运行，给证书明文签名和给明文的hash签名，不会给验证有任何影响。但为何要作一次hash呢？还记得上篇文章上提到过，非对称加密是很是耗时和耗性能的，对一个字符加密和对100个字符加密哪一个更快一些，掰着大拇指想想也是越短加密越快，因此缘由出来了，证书的明文基本都很长，可是通过hash以后都很短，并且基本都是固定的长度了，因此出于性能的考虑，在制做签名时须要hash一次

好，问题回答完毕，若有疑问，先冷静分析一下，接下来进入正题

https的详细握手过程

https在七层协议里面属于应用层，他基于tcp协议，因此，https握手的过程，必定先通过tcp的三次握手，tcp连接创建好以后，才进入https的对称密钥协商过程，对称密钥协商好以后，就开始正常的收发数据流程。

接下来我就拿实际网络数据包来解释https的整个详细的握手过程

因而我打开wireshark抓包工具，并随手打开命令行，怯意的输入了以下一行命令

curl https://www.baidu.com
复制代码

上面其实涉及到两个问题

1. 为何是wireshark，而不是fiddler 或者 charles

   fiddler 和charles主要是用于抓取应用层协议https/http等上层的应用数据，都是创建连接成功后的数据，而wireshark是能够抓取全部协议的数据包（直接读取网卡数据）,咱们的目的是抓取https创建连接成功前的过程，因此咱们选择wireshark

2. 为何是用curl， 而不是在浏览器打开https://www.baidu.com

   curl是只发送一个请求，若是是用浏览器打开百度，那百度页面里面的各类资源也会发送请求，容易形成不少没必要要的数据包

好，重点来了，开始上图：

上面两张图就是用curl请求https://www.baidu.com用wireshark抓到的全部数据包，是否是有点慌，哈哈

遇到凡事不要慌，接下来待我给你慢慢道来（ack消息属于tcp协议里面的确认报文，不作解释）

第一步

解释说明：tcp三次握手，这个不作解释，若是这块不清楚，好比ack，seq,mss,win都表明什么意思，这个能够在互动区留言，我视状况专门写几篇tcp的文章（这块太大了，没几篇是介绍不完的）

第二步：客户端发送client_hello

解释说明：客户端发送client_hello，包含如下内容（请自行对照上图） 1. 包含TLS版本信息 2. 随机数（用于后续的密钥协商）random_C 3. 加密套件候选列表 4. 压缩算法候选列表 5. 扩展字段 6. 其余

第三步：服务端发送server_hello

解释说明：服务端收到客户端的client_hello以后，发送server_hello，并返回协商的信息结果 1. 选择使用的TLS协议版本 version 2. 选择的加密套件 cipher suite 3. 选择的压缩算法 compression method 4. 随机数 random_S 5. 其余

第四步：服务端发送证书

解释说明：服务端发送完server_hello后，紧接着开始发送本身的证书（不清楚证书是什么的，能够移步到上一篇文章），从图可知：因包含证书的报文长度是3761，因此此报文在tcp这块作了分段，分了3个报文把证书发送完了

问本身： 1. 分段的标准是什么？ 2. 何时叫分段，何时叫分片？ 3. 什么是MTU，什么是MSS

第五步：服务端发送Server Key Exchange

解释说明:对于使用DHE/ECDHE非对称密钥协商算法的SSL握手，将发送该类型握手。RSA算法不会进行该握手流程（DH、ECDH也不会发送server key exchange）,也就是说此报文不必定要发送，视加密算法而定。SSL中的RSA、DHE、ECDHE、ECDH流程与区别能够参考此篇文章

第六步：服务端发送Server Hello Done

解释说明:通知客户端 server_hello 信息发送结束

第七步：客户端发送.client_key_exchange+change_cipher_spec+encrypted_handshake_message

解释说明: 1. client_key_exchange，合法性验证经过以后，向服务器发送本身的公钥参数，这里客户端实际上已经计算出了密钥 2. change_cipher_spec，客户端通知服务器后续的通讯都采用协商的通讯密钥和加密算法进行加密通讯 3. encrypted_handshake_message，主要是用来测试密钥的有效性和一致性

第八步：服务端发送New Session Ticket

解释说明:服务器给客户端一个会话，用处就是在一段时间以内（超时时间到来以前），双方都以协商的密钥进行通讯。

第九步：服务端发送change_cipher_spec

解释说明:服务端解密客户端发送的参数，而后按照一样的算法计算出协商密钥，并经过客户端发送的encrypted_handshake_message验证有效性，验证经过，发送该报文，告知客户端，之后能够拿协商的密钥来通讯了

第十步：服务端发送encrypted_handshake_message

解释说明:目的一样是测试密钥的有效性，客户端发送该报文是为了验证服务端能正常解密，客户端能正常加密，相反：服务端发送该报文是为了验证客户端能正常解密，服务端能正常加密

第十一步：完成密钥协商，开始发送数据

解释说明：数据一样是分段发送的

第十二步：完成数据发送，4次tcp挥手

解释说明：红框的意思是：客户端或服务器发送的，意味着加密通讯由于某些缘由须要中断，警告对方不要再发送敏感的数据,服务端数据发送完成也会有此数据包，可不关注

结语

最后用一张图来讲明如下过程