TLS抓包分析

TLS(Transport Layer Security, 傳輸層安全):用於保證Web通信以及其他流行協議的安全。
TLS的前身是安全套接字層(SSL)。
TLSv1.2版本運行在面向流的協議(如TCP)之上。

在這裏插入圖片描述

記錄協議提供分片、壓縮、完整性保護以及對客戶端與服務器之間所交換數據的加密服務。
信息交換協議負責建立身份,進行認證,提示警報,以及爲用於每一條連接的記錄協議提供唯一的密鑰材料。

TLS記錄協議:負責識別不同的消息類型,以及每條消息的完整性,安全性驗證。
記錄協議提供了一個可擴展的記錄內容類型值集合來來識別高層協議。
**記錄協議的處理流程:**先將應用層信息塊(分片)劃分爲TLS明文記錄(最長16K)。TLS明文記錄形成後就會使用一種壓縮算法進行壓縮(通常是NULL壓縮協議),形成TLS壓縮結構。
爲了防止數據被修改,加密與完整性保護算法會把TLS壓縮結構轉換爲能在底層傳輸層上傳輸的TLS密文結構。

過程如下:

在這裏插入圖片描述

TLS信息交換協議:密碼變更協議、警告協議、握手協議。
密碼變更協議:指出通信一方希望將當前狀態修改爲掛起狀態。
警告協議:傳遞狀態信息。
握手協議:建議與連接相關的運行參數。它允許端點完成以下目標:
1、協議加密算法並交換形成對稱密鑰時使用的隨機值。
2、建立算法運行參數。
3、交換證書並執行互相誰。(通常是單向認證)
4、生成特定的會話密鑰。
5、爲記錄層提供安全參數。
6、驗證所有的操作都已正確執行。握手過程:

在這裏插入圖片描述
以下對握手過程進行抓包:

在這裏插入圖片描述

先建立TCP連接(三次握手)
ClientHello包
141號包:

在這裏插入圖片描述

其中的Random Bytes是客戶端生成的28字節的隨機數,用於生成最終的會話密鑰,後面的過程還會傳遞兩個隨機數,三個隨機數做爲EC Diffie-Hellman算法的相關參數,運算出會話密鑰。先把這個隨機數稱爲random_c.
ServerHello

在這裏插入圖片描述

服務器也生成了一個隨機數發給了客戶端,此時客戶端與服務器各擁有兩個相同的隨機數。random_c, random_s。
壓縮算法爲NULL壓縮算法。(不支持任何壓縮算法)

在這裏插入圖片描述

服務器返回了兩個證書: 第一個是百度的證書,另一個應該是根證書。 客戶端收到這個證書後,可以根據證書鏈來驗證證書的真僞,進而判斷服務器是真是假。 服務器證書中存放一個公鑰,用於加密後面生成的Premaster secret

ServerKeyExchange
在這裏插入圖片描述

ServerKeyExchange(服務器密鑰交換消息):僅用於服務器發送的Certificate消息沒有足夠的信息讓客戶端來生成Premaster secret的情況(如密碼套件以TLS_DHS_anon, TLS_DHE_DSS, TLS_DHE_RSA開頭的),本次服務器選擇的密碼套件需要發送ServerKeyExchange消息來生成Permaster secret。(預置密鑰)
此消息中服務器向客戶端發送了Pubkey這個隨機數。 此時客戶端已經擁有了三個隨機數(自身生成的random_c, 服務器發送的random_s以及此處的pubkey),有了這三個參數,就可以運行Diffie-Hellman算法生成Premaster secret(最終 的會話密鑰)

在這裏插入圖片描述

表示服務器這邊握手相關的信息發送完畢。(但客戶端的消息還沒發送完,比如生成最終會話密鑰所需要的三個隨機數,此時服務器只有兩個(random_c, random_s))

在這裏插入圖片描述

三種消息一起發送, ClientKeyExchange同ServerKeyChange,客戶端向服務器發送pubkey這個隨機數。(現在服務器有了三個隨機數)
ChangeCipherSpec 表示以後客戶端要使用加密的方式發送數據。
Encrypted Handshake Message (Finished)

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章