刨根問底系列之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揮手

解釋說明：紅框的意思是：客戶端或服務器發送的，意味着加密通訊由於某些緣由須要中斷，警告對方不要再發送敏感的數據,服務端數據發送完成也會有此數據包，可不關注

結語

最後用一張圖來講明如下過程