前言
先說看了一天各種博客讓我惡心的地方，惡心死了，發現每個人說的第一次發送的內容，數字證書里面包含啥，都有各種不一樣！到了最后忽然想起來直接搜着報文就行了。
比如這個博客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 //這個博客后變推薦的幾個博客很贊！！！