TLS 1.2

TLS 1.2 - 通信過程

Client Hello

  • 客戶端發送的,屬於TLS握手協議(TLS handshake)的一部分,其內容包括客戶端的一個Unix時間戳(GMT Unix Time)、一些隨機的字節(Random Bytes),還包括了客戶端接受的算法類型(Cipher Suites),本例中Mozilla Firefox 57.0允許15種算法,瀏覽器認為這些算法是可以被信任的。這是最基本的部分,同時還有其他的擴展參數,這裡就不做介紹了。
  • Client Hello的目的就類似於SYN,客戶端對服務器公佈自己支持的算法等等,同時也附帶請求服務器證書的意思。這裡不驗證客戶端證書,所以Client Hello就只有這些內容。

Server Hello

  • 服務器發送的,同樣屬於TLS handshake,內容包括服務器的GMT Unix Time以及Random Bytes,和上面類似就不再解釋。這時候服務器會將自己支持的算法類型發送給客戶端,以便於客戶端進行驗證,這裡我的服務器使用的是TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,也就是使用AES-128的GCM模式進行對稱加密,同時以帶SHA-256的RSA作為簽名算法,用ECDHE做密鑰交換的一整套協議。我的服務器也算是主流安全啦~
  • Server Hello目的就是服務器對客戶端公佈自己的算法,以便於後續操作。

Certificate

  • 服務器或者客戶端發送的,依舊屬於TLS handshake,它一般和Server Hello在同一個TCP報文中傳送。顯然的,這裡服務器將自己的數字證書發送給客戶端,客戶端就會進行證書驗證,如果不通過的話,客戶端會中斷握手的過程。如果也要求客戶端提供證書的話,Client Hello後面也會緊跟著該報文,形式完全一樣,就不再解釋了。

Server Key Exchange

  • 服務器發送的,屬於TLS handshake,一般也和Server Hello與Certificate在一個TCP報文中。服務器將自己的公鑰參數傳輸給了客戶端,因為使用的是ECDHE,這裡傳輸的內容有:橢圓曲線域參數,以及公鑰的值。
  • 這個就是密鑰交換協議的一部分,最終協商出密鑰來。

Server Hello Done

  • 服務器發送的,屬於TLS handshake,一般也和Server Hello、Certificate和Server Key Exchange在一個TCP報文中,介於Server Hello和Server Hello之間的是服務器想要給客戶端的東西。所以這裡面客戶端沒有發送Client Hello Done

Client Key Exchange

  • 客戶端發送的,屬於TLS handshake,客戶端收到了服務器的證書進行驗證,如果驗證通過了,就會繼續密鑰交換的過程,向服務器發送自己的公鑰參數。待服務器收到之後進行數學計算,就可以協商出密鑰了,這裡客戶端實際上已經計算出了密鑰。

Change Cipher Spec

  • 客戶端或者服務器發送的,屬於TLS handshake,緊跟著Key Exchange發送,代表自己生成了新的密鑰,通知對方以後將更換密鑰,使用新的密鑰進行通信。

Encrypted Handshake Message

  • 客戶端或者服務器發送的,屬於TLS handshake,也是緊跟著Key Exchange發送。這裡是進行一下測試,一方用自己的剛剛生成的密鑰加密一段固定的消息發送給對方,如果密鑰協商正確無誤的話,對方應該可以解密。這段加密內容的明文一般是協議中規定好的,雙方都知道。

New Session Ticket

  • 服務器發送的,屬於TLS handshake,服務器給客戶端一個會話,用處就是在一段時間之內(超時時間到來之前),雙方都以剛剛交換的密鑰進行通信。從這以後,加密通信正式開始。

Application Data

  • 應用層的數據,是加密的,使用密鑰交換協議協商出來的密鑰加密。因為我們的Wireshark不知道服務器的私鑰,所以這段通信是安全的,我們在Wireshark中也無法解密這段信息。

Encrypted Alert

  • 客戶端或服務器發送的,意味著加密通信因為某些原因需要中斷,警告對方不要再發送敏感的數據。


分享到:


相關文章: