前情提要

• 使用Clion和gmssl動態庫實現服務器server和客戶端client之間的SSL通信，測試指定密碼套件_MY CUP OF TEA的博客-CSDN博客
• 在基于 Ubuntu 的 Linux 發行版上安裝 Wireshark_MY CUP OF TEA的博客-CSDN博客
• 本地搭建server和客戶端使用端口進行數據通信，使用Wireshark抓取127.0.0.1環回地址并分析通信數據_MY CUP OF TEA的博客-CSDN博客_wireshark抓127.0.0.1
• 使用wireshark抓包，本地環回測試通信數據已經通過SM4國密算法加密_MY CUP OF TEA的博客-CSDN博客_sm4 在線測試

參考鏈接

• 用wireshark抓包分析TLS協議_GEEK_BD_bro的博客-CSDN博客_wireshark 過濾tls

啟動wireshark

• 雖然配置wireshark的時候，選擇所有用戶均可進行抓包，但是在真正使用的時候，普通用戶還是會存在問題，通過鼠標點擊圖標的方式啟動wireshark，默認是當前用戶，不是root用戶，不光界面不一樣，且不允許抓包
• 開啟終端，使用命令 sudo wireshark 開啟wireshark軟件，進行抓包
• 參考上述鏈接里面的server和客戶端的代碼，指定ip地址為127.0.0.1，端口為7838，因此本文采用本地環回的方式進行數據包的抓取和分析

操作流程

• wireshark 選擇本地環回
• 在過濾欄設置過濾條件進行數據包列表過濾輸入 tls，表示只顯示TLS協議的數據包

• 開啟服務端
• 開啟客戶端

補充知識

• SSL/TLS是保護計算機網絡通訊安全的一類加密協議，它們在傳輸層上給原先非安全的應用層協議提供加密保護，如非安全的HTTP協議即可被SSL/TLS保護形成安全的HTTPS協議。
• SSL、TLS協議其實是有所差異的，TLS協議是繼承了SSL協議并寫入RFC，標準化后的產物。因此，通常使用SSL來指代SSL協議和TLS協議。
• SSL (Secure Socket Layer)安全套接字層協議
  • SSL通過互相認證、使用數字簽名確保完整性、使用加密確保私密性，以實現客戶端和服務器之間的安全通訊。
  • 分為SSL記錄協議和SSL握手協議。
• TLS(Transport Layer Security)傳輸層安全協議
  • 用于兩個應用程序之間提供保密性和數據完整性。
  • 分為TLS記錄協議和TLS握手協議。
• 區別：
  • SSL是Netscape開發的專門用戶保護Web通訊的，目前版本為3.0。
  • TLS 1.0是IETF(工程任務組)制定的一種新的協議，它建立在SSL 3.0協議規范之上，是SSL 3.0的后續版本。兩者差別極小，可以理解為SSL 3.1，它是寫入了RFC的

?服務端和客戶端通信流程

?藍色表示客戶端-->服務端；綠色表示服務端 --> 客戶端

• Client Hello：客戶端向服務端打招呼；攜帶支持的協議、支持的安全套件供服務端選擇；
• Server Hello：服務端回應客戶客戶端的招呼信息；結合客戶端的信息，選擇合適的加密套件；
• Certificate：服務端向客戶端發送自己的數字證書（此證書包含服務端的公鑰），以實現驗證身份；
• Server Key Exchange：服務端向客戶端發送基于選擇的加密套件生成的公鑰（此公鑰為橢圓曲線的公鑰，用于協商出對稱加密的密鑰）；
• Server Hello Done：服務端向客戶端表示響應結束；
• Client Key Exchange：客戶端向服務端發送自己生成的公鑰（此公鑰為橢圓曲線的公鑰，用于協商出對稱加密的密鑰）；
• Change Cipher Spec：變更密碼規范；告知服務端/客戶端，以后的通信都是基于AES加密的；
• Encrypted Handshake Message：基于協商生成的密鑰，用AES加密驗證信息讓服務端/客戶端進行認證；如果對方可以解密，則雙方認證無誤開始通信；
• New Session Ticket：是優化SSL連接的一種方法，此處不做特別說明
• 注：Certificate Request：服務器如果需要驗證客戶端的身份，那么服務器會發一個“Certificate Request”給瀏覽器，而在很多實現中，服務器一般不需要驗證客戶端的身份

?協議包分析

Client Hello包

• Random Bytes:客戶端產生的28字節隨機數，用于生成最終密鑰，后面的過程還會傳遞兩個隨機數，三個隨機數做為EC Diffie-Hellman算法的相關參數，運算出會話密鑰。先把這個隨機數稱為random_c.
• Session ID:會話標識符：如果是一個新的連接，這個值為0
• Cipher Suites:加密套件（客戶端共支持17個加密套件），服務器會從中選擇一個服務器也支持的加密套件
• Compression Methods:客戶端支持的壓縮方法
• Extension: ALPN:客戶端支持的應用層協議；未找到依據
• Extension: signature_algorithms: 客戶端支持的簽名算

Cipher Suites：Unknown(0xe107)

• 客戶端內部指定了gmssl支持的密碼學套件
• 0xE1,0x07 - ECDHE-SM2-WITH-SMS4-GCM-SM3 ? ?TLSv1.2 ? ?Kx=ECDH ? ? Au=SM2 ? ?Enc=SMS4GCM(128) ? ? ? ? ? ?Mac=AEAD

        //指定密碼算法套件// gmssl ciphers -V 明確支持SSL_CTX_set_cipher_list(ctx,"ECDHE-SM2-WITH-SMS4-GCM-SM3");

?Server Hello, Certificate, Certificate Status, Server Key Exchange, Server Hello Done包

Server Hello段?

• Random Bytes:服務器生成的隨機數random_s
• Cipher Suites:服務器選擇的加密套件：0xe107
• Compression Methods:服務器選擇的壓縮算法為NULL壓縮算法。（不支持任何壓縮算法），壓縮基本由應用層來完成。

?Certificate

• Certificate: 服務器返回了兩個證書： 第一個是CA簽發的證書（Bing），本模擬實驗中，此處是指服務器證書；第二個是CA鏈的證書，本模擬實驗中，此處是指CA根證書。
• 客戶端收到這個證書后，可以根據證書鏈來驗證證書的真偽，進而判斷服務器是真是假。服務器和客戶端的證書均是由根CA進行簽名認證的
• 服務器證書中存放一個公鑰，用于加密后面生成的Premaster secret

Server Key Exchange段

• ?受限于特定的密碼算法套件

Certificate Request

• Certificate Request：服務器如果需要驗證客戶端的身份，那么服務器會發一個“Certificate Request”給瀏覽器，而在很多實現中，服務器一般不需要驗證客戶端的身份

Server Hello Done段

Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 包

Certificate

• ?服務端開啟了對于客戶端的身份認證
• 第一個是CA簽發的證書（Bing），本模擬實驗中，此處是指客戶端證書；第二個是CA鏈的證書，本模擬實驗中，此處是指CA根證書。
• 服務器收到這個證書后，可以根據證書鏈來驗證證書的真偽，進而判斷客戶端是真是假。服務器和客戶端的證書均是由根CA進行簽名認證的

Client Key Exchange段

???????

?Certificate Verify

Change Cipher Spec段?

• 變更密碼規范協議，它非常簡單，就是一條通知消息，告知對方以后的通信都是加密的；

?Encrypted Handshake Message

• ?客戶端使用生成的對話密鑰，加密之前所有收發握手消息的Hash和MAC值，發送給服務器，服務器將相同的會話密鑰（使用相同方法生成）解密此消息，校驗其中的Hash和MAC值。
• 注意：Change Cipher Spec和Encrypted Handshake Message不像Client Hello、Server Hello等是封裝在 Handshake Protocol層，而是同Handshake Protocol一樣，直接封裝在TLS Record Layer層。

Change Cipher Spec, Encrypted Handshake Message包

• Change Cipher Spec:服務器發送Change Cipher Spec消息，通知客戶端此消息以后服務器會以加密方式發送數據。服務器使用會話密鑰加密之前所有收發握手消息的Hash和MAC值，發送給客戶端去校驗。
• 若客戶端服務器都校驗成功，握手階段完成，雙方將按照SSL記錄協議的規范使用協商生成的會話密鑰加密發送數據。
• 可以看到，之后服務器開始向客戶端發送加密消息Application Data。

?Application Data包

• 客戶端開始向服務器發送加密數據

???????