基于Wireshark的TLS協(xié)議分析

鄧逸銘 郭旭

摘要：傳輸層安全協(xié)議（TLS）是安全通信中普遍運用的傳輸協(xié)議，為安全通信提供保密性、完整性和可靠服務(wù)。該文通過對TLS協(xié)議的詳細描述，采用Wireshark分析工具在實時網(wǎng)絡(luò)中獲取網(wǎng)絡(luò)通信數(shù)據(jù)包，逐一分析TLS的工作過程，并比較了其版本迭代的差異，對深入理解TLS協(xié)議及其安全通信過程具有重要意義。

關(guān)鍵詞：傳輸層安全協(xié)議；Wireshark；安全通信

中圖分類號：TP311? ? ?文獻標(biāo)識碼：A

文章編號：1009-3044（2022）27-0064-03

開放科學(xué)（資源服務(wù)）標(biāo)識碼（OSID）：

1 緒論

傳輸層安全協(xié)議（TLS）是在安全套接字層協(xié)議（SSL）的基礎(chǔ)上標(biāo)準(zhǔn)化之后的產(chǎn)物，目的是保證加密通信的信息完整性，確保其保密性，以實現(xiàn)服務(wù)端和客戶端之間的安全通信。通過Wireshark網(wǎng)絡(luò)協(xié)議分析工具，對實時網(wǎng)絡(luò)中的通信過程抓取并進行分析，展開詳細的TLS工作流程解析，對于學(xué)習(xí)TLS協(xié)議在安全通信中的顯著作用有所裨益。

2 Wireshark 協(xié)議分析工具簡介

Wireshark是一個用來抓取和解析網(wǎng)絡(luò)數(shù)據(jù)包的工具，對新手學(xué)習(xí)非常友好，支持圖形化界面，對各個字段的數(shù)據(jù)分析非常詳細，可以用來學(xué)習(xí)和驗證傳輸協(xié)議，以提升學(xué)習(xí)效率。Wireshark并不具有預(yù)警和風(fēng)險監(jiān)測功能，若產(chǎn)生異常流量行為，Wireshark并不能及時作出響應(yīng)。可以通過Wireshark檢測網(wǎng)絡(luò)問題，保證網(wǎng)路通信中的安全性，排除差錯，降低風(fēng)險[1]。Wireshark的功能十分強大，對于截取網(wǎng)絡(luò)數(shù)據(jù)包有其獨到的便捷性，使用過程中，需要先選擇連接到網(wǎng)絡(luò)的接口，設(shè)置捕獲過濾器將捕獲文件初步過濾，以免獲取過多文件，再通過顯示過濾器二次過濾，篩選出符合研究對象的數(shù)據(jù)。Wireshark還支持對會話進行著色突出，以標(biāo)記不同數(shù)據(jù)，另外，Wireshark也可以通過重組不同數(shù)據(jù)包，將離散的多個數(shù)據(jù)包重新組合，以還原原本的文件[2]。

3 TLS協(xié)議簡介

3.1 TLS協(xié)議簡介

TLS協(xié)議是工作在傳輸層的安全協(xié)議，使用的是公開密鑰技術(shù)，以保證網(wǎng)絡(luò)安全服務(wù)的可靠性，便于數(shù)據(jù)傳輸。TLS協(xié)議分為兩層：上層即是TLS握手協(xié)議，主要用于協(xié)商密鑰，描述雙方如何安全協(xié)商會話密鑰以便安全通信，對于身份認證、交換密鑰等方面都有重要作用。下層是TLS記錄協(xié)議，用于對上層傳來的數(shù)據(jù)加密后傳輸，對于向高層協(xié)議提供加密解密等功能。TLS協(xié)議中的身份認證屬于端到端協(xié)議，無須防火墻支持。TLS是一個混合加密系統(tǒng)，采用的是非對稱加密和對稱加密結(jié)合的形式，同時，TLS也支持多種密鑰交換算法和加密算法，TLS通信的建立在客戶端和服務(wù)端完成TCP三次握手建立連接之后，即開始建立TLS握手過程[3]。

3.2 TLSv1.2與TLSv1.3

TLS的發(fā)展歷程是一個不斷前進，不斷迭代的過程，通過對舊版本的修補以兼容更多更新的功能。TLSv1.2主要存在的問題諸如安全問題和性能問題。TLSv1.2的安全問題依然為人詬病，被發(fā)掘出許多漏洞，在交換算法的選擇和數(shù)字簽名等各個方面都存在較嚴(yán)重的安全問題。另外，高版本的TLS協(xié)議降級為低版本時，由于不兼容性，也存在較大的漏洞。再者，TLSv1.2對于傳輸?shù)膿p耗也很大，即使加入了許多的技術(shù)改善，TLSv1.2仍然需要2RTT的時延。Client端和Server端仍然需要來回兩次的通信才能建立起TLS傳輸。

而TLSv1.3是對TLSv1.2革命性的進步，在其中更新迭代了許多功能和特性。對于前文所述的安全問題和性能問題，TLSv1.3都給出了解決方案。TLSv1.3不再與之前版本兼容，同時使用安全算法加密通信，以此減少通信時間。當(dāng)請求資源包并不大時，其優(yōu)勢即被體現(xiàn)。TLSv1.3將TLSv1.2的TLS握手階段縮短為1-RTT，又由于會話復(fù)用階段發(fā)送第一個包時即可附加數(shù)據(jù)，所以引入了0-RTT概念。誠然，使用TLSv1.2和TLSv1.3在具體運用中還需要特定分析，以便在實際應(yīng)用中有的放矢[4]。

4 TLS協(xié)議工作流程分析

4.1 TLSv1.3握手過程

TLSv1.3通信過程如下：

（1）由Client端發(fā)送名為Client Hello的消息到達Server端，該消息包含客戶端支持的cipher suites以及隨機數(shù)，此時為明文傳輸。

（2）當(dāng)Server端收到Client端發(fā)來的消息后，返回自己支持的cipher suites信息和Server端的生成的隨機數(shù)和數(shù)字證書等信息。二者通過以上兩個步驟確定安全傳輸能力，協(xié)議的版本以及密碼套件，并可以通過商定的安全算法生成共享的密鑰信息，為后續(xù)進行對稱加密提供保障。

（3）Client端驗證（2）中Server端的數(shù)字證書，不斷溯源直達頂端CA，驗證證書的合法性。為了驗證Server端擁有與其數(shù)字證書對應(yīng)的私鑰，Client端還需要驗證Server端提供的Certificate Verify信息。驗證通過后，Client發(fā)送Change Cipher Spec消息，后續(xù)依據(jù)商定的安全參數(shù)進行安全通信，發(fā)送加密的Finished消息結(jié)束握手協(xié)商。

（4）Server端接收到密文Finished后，使用（2）中計算的共享密鑰進行對稱解密，解密成功后驗證握手消息的完整性和真實性。

通過以上步驟，TLS的握手過程結(jié)束，之后進行對稱加密通信。

4.2 使用Wireshark抓包分析

首先，利用Wireshark協(xié)議分析工具對目標(biāo)網(wǎng)站抓包。為了從大量的數(shù)據(jù)包中過濾出預(yù)分析的TLS交互流量，需要采用Wireshark的顯示過濾功能。可通過ping命令獲取目標(biāo)網(wǎng)站域名對應(yīng)的IP地址，例如圖2所示，yangtzeu.yuketang.cn目標(biāo)網(wǎng)站的IP地址是140.179.30.171。

通過Wireshark的過濾指令ip.addr == 140.179.30.171過濾出與對應(yīng)IP通信的流量，得到的未解密的流量如圖3所示。

圖3中可以看到由客戶端發(fā)來Client Hello消息，而在第二步中，服務(wù)端的Server Hello消息中數(shù)據(jù)被加密，顯示為Application Data。

為了獲得對應(yīng)的解密消息，需要在抓包前進行環(huán)境變量配置。例如，在Windows 10系統(tǒng)中，添加Administrator的用戶變量，新建變量名為SSLKEYLOGFILE和值為C：＼keys＼sslkey.log（保存路徑，可自定義）。并在Wireshark首選項中對TLS協(xié)議的預(yù)主密鑰日志文件名進行配置，如圖4所示。然后重新抓包，通過加載TLS密鑰解密后，得到的數(shù)據(jù)流。

對比圖3和如圖5，可以看到Server Hello階段一并傳輸?shù)腁pplication Data數(shù)據(jù)被解密，其中的Encrypted Extensions即為對應(yīng)的解密部分信息，說明此時用于檢驗對稱加密的密鑰可以正常工作。

協(xié)議具體分析如下：

（1） Client端發(fā)送的第一條消息Client Hello消息中包含了客戶端生成的隨機數(shù)和支持的密碼算法套件。如圖6所示，客戶提供了密碼套件，長度為32，例如TLS_CHACHA20_POLY1305_SHA256、TLS_AES_256_GCM_SHA384等。由于TLSv1.2存在良久，網(wǎng)絡(luò)中的部件也已經(jīng)非常老舊，很久沒有更新，若此時采用TLSv1.3，則因為未知性導(dǎo)致傳輸失敗，所以此時的version字段是TLS1.2[5]。

Client端在發(fā)送Client Hello報文時，會將公鑰存于key_share中，如圖7所示，key_share中包含Client端選擇的曲線X25519，長度為32，表示將使用ECDH密鑰交換算法建立對稱密鑰。Client端通過所要使用的ECDH算法生成公鑰和私鑰對后，將其設(shè)置于上述key_share信息中。TLSv1.3通過采用key-share信息字段，大大提高了傳輸速度及認證速度，相較于TLSv1.2解決了其性能不足的問題。

（2） Server端返回的Server Hello中包含Server端生成的隨機數(shù)和選擇的密鑰算法套件即TLS_AES_256_GCM_SHA384，長度為32位。同樣，此時的version字段是TLS1.2。

Server端同樣生成公鑰和私鑰對，key_share中也包含Server端的公鑰信息。同樣地，key_share中包含Server端選擇的曲線X25519，長度為32，表示將使用ECDH密鑰交換算法建立共享密鑰。至此階段，Client和Server可以依據(jù)交換的隨機數(shù)和公鑰信息，生成對應(yīng)的預(yù)主密鑰、主密鑰和會話密鑰等共享密鑰。隨后Server端通過Change Cipher Spec協(xié)議字段將消息傳輸由明文傳輸改為加密傳輸，增強了安全性。這也是TLSv1.3相較于TLSv1.2改進的重要步驟，由于此后過程都將采用加密傳輸，安全性得到改善。

（3） 為了實現(xiàn)對Server的認證，防止中間人攻擊，一般需要Server端提供相關(guān)的認證信息，包括certificate和certificate verify，最后發(fā)送Finished信息。

Certificate消息來自服務(wù)端的數(shù)字證書，在選用ECDH算法時，內(nèi)容為服務(wù)端加密的簽名證書。Certificate Verify信息用于確保Server端擁有其所聲稱的公鑰對應(yīng)的私鑰，防止中間人攻擊，緊跟于Certificate信息之后。Finished消息指代握手結(jié)束，采用SHA384驗證握手過程的真實性，Client端或者Server端在接收后，需要保證自己收到的數(shù)據(jù)包是否完整且準(zhǔn)確。當(dāng)Client端和Server端都發(fā)送且成功接收到對方的Finished信息之后，代表數(shù)據(jù)傳輸已經(jīng)完成校驗，保證握手過程無誤。

（4） 當(dāng)Client端獲取到Server端發(fā)來的數(shù)據(jù)包后，計算出傳輸?shù)拿荑€，向Server端發(fā)送Change Cipher Spec信息和Finished信息。

至此，通信雙方都接收到了對方的Finished信息，標(biāo)志著握手完成，Server端會發(fā)送一個New Session Ticket報文給客戶端，此信息將為后續(xù)會話起到重要作用。

（5） 在有效期內(nèi)，當(dāng)客戶端想嘗試會話復(fù)用時，則需要在發(fā)送的Client Hello消息中攜帶pre-shared-key，即上一步的New Session Ticket信息。pre-shared-key信息由第一次完整結(jié)束時Server端發(fā)往Client端，所以在Client端需要發(fā)回給Server端時即可直接使用。值得注意的是，此時的pre-shared-key信息采用非對稱加密傳輸，保密性和安全性得到了保證。如圖14和圖15所示，New Session Ticket字段內(nèi)容和pre-shared-key字段內(nèi)容完全一致，即可印證結(jié)論正確性。

Server端接收成功之后，進行校驗，校驗通過后則恢復(fù)會話。

5 結(jié)語

隨著信息技術(shù)的不斷發(fā)展，網(wǎng)絡(luò)通信日益壯大的同時，其隱患和安全漏洞也不可忽視，新形勢之下也需要新的安全對策。本文通過對Wireshark的功能實現(xiàn)和TLS協(xié)議的工作流程和基本狀態(tài)進行了較為詳細的介紹，并通過Wireshark分析工具對于傳輸層安全協(xié)議TLS的網(wǎng)絡(luò)通信過程進行了詳細的分析，了解其保障安全性的原理和流程，對于學(xué)習(xí)網(wǎng)絡(luò)通信協(xié)議受益良多。

參考文獻：

[1] 王炅，張華，吳征遠，等.基于Wireshark的OSPF路由協(xié)議分析與仿真[J].閩江學(xué)院學(xué)報，2019，40（2）：62-69.

[2] 歐國成.Wireshark在網(wǎng)絡(luò)安全管理中的應(yīng)用[J].網(wǎng)絡(luò)安全技術(shù)與應(yīng)用，2020（5）：16-19.

[3] 張興隆，程慶豐，馬建峰.TLS 1.3協(xié)議研究進展[J].武漢大學(xué)學(xué)報（理學(xué)版），2018，64（6）：471-484.

[4] weixin_30780649.TLS 1.3 VS TLS 1.2，讓你明白TLS 1.3的強大.2018[2022-03-12].https：//blog.csdn.net/weixin_3078064 9/article/details/98834099.

[5] ChainingBlocks.使用wireshark分析TLSv2（詳細）[EB/OL].2016[2022-02-15].https：//blog.csdn.net/liangyihuai/article/details/53098482.

【通聯(lián)編輯：梁書】