背景

https协议对于我们做开发的小伙伴往往是一种既熟悉又朦胧的存在：对基本的概念有大致的了解包括加密，证书等等但是由于HTTP协议本身已经有了很好的封装所以对于通信细节往往缺乏全面的了解，笔者也是由于工作中正好碰到了相关的证书问题出于解决问题的需要对协议本身有了一些分析和了解。在查询文献过程中发现网上文章多而杂所以结合https抓包整理成简书文章分享给大家，希望能给大家带来帮助。

1.HTTPS协议的通信过程概述

HTTPS的通信一般使用非对称加密进行秘钥传递然后使用对称加密进行后面的业务数据的传输。过程如下图所示：

首先，是著名的TCP三次握手，然后是客户端和服务端的通信协议协商服务端会从客户端发送的协议中选择一种作为加密算法协议，再然后是服务端发送CA证书到客户端验证身份，验证通过后客户端会将私钥最后一段通过服务端公钥非对称加密传送到服务端，后面客户端会利用协商好的机密算法和对称秘钥进行加密通信。

关键词：TCP三次握手，CA证书，证书链，加密协议协商

2.TCP三次握手

tcp的三次握手主要流程是SYN>>>SYN,ACK>>>ACK相信大家都比较熟悉了。这里主要说下为什么是三次握手，三次握手都握了什么。

要理解tcp握手的三次过程就要先有一个背景知识就是tcp通信中的seq number，next seq number以及acknowledgment number的概念。简单来说就是B收到A发送的数据包中就会有seq+数据包长度len就可以计算出next seq number。next seq number作用有两个：1、B如果再接收到A的下一个数据包后就可以将下一个数据包的seq和本次的next seq number比较来判断中间是否有丢包 2、B通过将计算出的next seq number作为acknowledgment number返回给A来和A确认包的接收情况。（参见下图）

有了以上背景我们就能理解tcp的三次握手内容是啥了，其实就是A和B在交换各自的初始seq number。首先A将seq作为SYN发给B为，B在该seq上加1作为ACK返回A同时将自己的seq作为SYN发给A，A校验通过后在B的seq上加1作为ACK返回给B。如果A和B都能校验通过则连接建立，如上描述TCP的握手最少为三次（B将ACK和SYN合并为一次）。

A>>>>B

B>>>>A

3.加密协议协商

在加密过程中首先客户端发送ClientHello消息携带支持的加密算法（图中Cipher Suites）和一段随机数字Random1到服务端。其中随机数字Random1会在后面的对称加密中用到。

Client Hello Message

然后服务端会在客户端加密算法中选择一个自己也支持的加密算法作为后面通信的加密算法（本次实验中服务端选择TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 作为加密算法）和随机数Random2。

Server Hello Message

4.证书验证

服务端如果能够支持客户端的协议，则服务端发送证书到客户端进行身份验证。关于证书验证个人感觉主要需要掌握两点：证书链和防伪。如果以介绍信作为类比可以这样形容张三拿着李四开的介绍信去别的地方办事，这时候别人就会有两个疑问第一这个介绍信是不是李四开的（防伪），凭什么李四的介绍信说你是张三你就是张三呐（证书链）？

关于防伪有一个非对称加密的背景知识需要理解（关于非对称加密现在网上将的最明白的一篇文章就是卡卡罗2017大神的文章）简单来说非对称加密的一个核心就是六点：1，公钥和私钥成对出现 2，公开的密钥叫公钥，只有自己知道的叫私钥3，用公钥加密的数据只有对应的私钥可以解密4，用私钥加密的数据只有对应的公钥可以解密5，如果可以用公钥解密，则必然是对应的私钥加的密6，如果可以用私钥解密，则必然是对应的公钥加的密。回到本题中，则证书颁发过程其实就是上级证书颁发机构通过持有的私钥为证书请求Server信息通过私钥进行加密签名，客户端证书验证则是收到Server证书后通过证书颁发机构的公钥对签名进行解密如果能够解密则一定是证书颁发机构颁发的证书如果解密后信息与Server信息一致则确实是颁发给该Server的，综上校验通过。

如果理解了防伪则证书链就好理解了，Server将自己证书发送到客户端时候会连同颁发机构证书一同发往客户端，通过和Server证书验证同样的过程通过内嵌在浏览器或者JDK中的根证书验证下中级证书的合法性就好了。因为根证书是内嵌的具有绝对的合法性，如果根证书信任该中级机构，则该中级证书颁发的证书也是可信的这就是证书链了。所以写到这里你就知道随便安装根证书的危害了，以后只要是该根证书信任的证书就都能为客户端信任了。

主要在本次消息中的两个证书：中级证书和server证书。

certification verify

5.秘钥传递

证书验证通过后，则生成随机数Random3通过server证书中的公钥（同时也是Server非对称加密算法公钥）加密并传递给服务端。Random3只有服务端利用存储的秘钥才能解密得到，这样对称算法最后一段传递完成。

6.加密通信

由于非对称加密的运算成本较高，所以一般只用来进行秘钥传递所以完成秘钥传递之后则客户端一般会使用之前协商的加密算法并将Random1+Random2+Random3作为对称加密算法的秘钥进行加密通信。

7.总结

关于非对称加密非常重要的一点就是私钥和公钥成对出现，如果能用私钥解密则一定是用公钥加密如果能用公钥解密则一定为私钥加密这个前提对于理解证书签名认证非常重要

参考文献：

https://www.jianshu.com/p/7615d036969f

https://juejin.im/entry/5904345ab123db3ee4755ebb

https://cattail.me/tech/2015/11/30/how-https-works.html

https://www.aneasystone.com/archives/2016/04/java-and-https.html?tdsourcetag=s_pctim_aiomsg

https://www.zhihu.com/question/24853633