前言
先说看了一天各种博客让我恶心的地方，恶心死了，发现每个人说的第一次发送的内容，数字证书里面包含啥，都有各种不一样！到了最后忽然想起来直接搜着报文就行了。
比如这个博客LS/SSL 协议详解 (9) Client hello：https://blog.csdn.net/mrpre/article/details/77867439 这个人的博客有各个报文的每个字段的详细解释！让我纳闷了一天那些博客怎么那么多矛盾，发现都错了好多！
建议搭配这个看 HTTPS工作流程.png
整理了一下我的：
https就是厉害在传输数据是安全的，传输过程中不会被其他方获取你的内容。用什么实现？SSL/TSL，也就是https就是用SSL/TSL实现http的加密传输。SSL“安全套接层”协议，TLS“安全传输层”协议，都属于是加密协议，在其网络数据传输中起到保护隐私和数据的完整性。像对称加密，非对称加密这种基本概念不说了，https主要就是双方偷偷规定一个世界上独一无二的秘钥，之后就用这套秘钥交流，就在于如和偷偷规定这个秘钥。
C：客户端 S：服务端
先来个三次握手 SYN(SYN-SENT) -> ACK+SYN+seq(SYN-RCVD) -> ACK+ack_num=seq+1(ESTABLISHED) 这个过程是客户端发请求，TCP分配到433端口。
1 client hello：
C->S 给个随机数rand1，支持的TLS版本号以及加密算法等。S->C会先回个ACK表示收到了，在这就不算个步骤了。
2 server hello & server certificent & server hello done：
回个使用哪个版本号的TLS和加密算法。还有个随机值rand2。然后发自己的数字证书，还包括签名用的hash算法。将明文hash成摘要，然后用CA的私钥加密摘要生成数字签名。 最后发个server hello done报文。 这个2我把这3个报文写一起了，从上边我说的那个png图可以更清楚的看到顺序。
3 验证证书：
C给S回个ACK表示收到了。开始验证证书，先验证明文部分，看看是否过期，网址是否正确。再用在操作系统或者浏览器上内置的CA公钥把数字签名给变回去，然后判断和证书中的明文的hash值是否相等，不相等说明被篡改了，停止交易。验证阶段还有一些其他东西，比如如果找不到这个CA证书，服务器会返回一个跟证书，让你选择是否信任。
4 client key exchange：
C->S 生成一个rand3，然后用公钥加密rand3生成一个Pre-Master Key，然后客户端发送一个Client Key Exchange报文把pre-master key发过去。服务端用私钥解密获得rand3。这个时候双方都有rand123，然后根据双方选择的加密算法算出来一个公用秘钥session-key。
5 客户端的change cipher spec & finish：
C->S 发一个change cipher spec报文表示之后会话使用秘钥来对称加密，然后发个finish报文，包含用秘钥加密的所有握手数据的摘要。
6 服务端的change cipher spec & finish：
S->C 先回一个ack，再验证一下用秘钥解密的finish报文是否和自己算出来的摘要一样。然后和客户端一样。发个两个报文。
7 搞完了：
客户端也回一个ack，表示知道了，之后就可以使用秘钥进行对称加密了。
关于4中选择哪个加密算法，在最开始的client hello报文里面的Cipher Suite里面有支持的加密算法，然后在server hello中返回的有选择使用哪一种。
这个图就是我开头提到的
思考：
其实归根结底就是如何使3个随机数只有双方知道。就是用服务器给客户的公钥，客户用这个公钥加密一个随机数，这样就只有服务端能解密。进一步就是保证服务器的公钥能够不被篡改，不被替换地到达客户端，所以用到了数字证书，保证不被篡改。
但是到这还有个问题，那么有了公钥直接以后用公私钥的非对称加密不就行了吗，还弄什么秘钥对称加密？当然不行，如果有中间人，只查看，不更改数字证书，中间人也能获得服务器的公钥，尽管不能破解客户端的信息，但有这个公钥就能知道服务端发送的信息，所以还是需要双方定一个秘钥。
参考：
(五)HTTPS抓包了解TLS握手流程：https://zhuanlan.zhihu.com/p/86304211
完全理解HTTPS如何做到传输安全： https://juejin.cn/post/6844903613479796750
HTTPS加密传输过程 ：https://www.cnblogs.com/WindrunnerMax/p/12580585.html //这个博客后变推荐的几个博客很赞！！！
