使用wireSharp分析TLS握手過程

前言

若是還沒嘗試過使用wiresharp的話,能夠參照我以前寫過的文章《wireSharp的基本用法》git

本篇文章不會詳細說TLS的內容,請結合我上一篇文章《深刻TLS/SSL協議》一塊兒觀看。github

Handshake

基本概念

TLS1.2中的握手過程主要有三個目的:算法

  • 驗證身份
  • 達成安全套件共識
  • 傳遞密鑰

如圖所示:

一、客戶端發送一個Client Hello,包含:數據庫

  • 協議版本號。
  • 客戶端生成的隨機數-Client random
  • 客戶端所支持的安全套件列表。

二、服務器回一個Server Hello,包括:瀏覽器

  • server所選擇的安全套件。
  • server發送本身的數字證書-server Certificates
  • server發送本身生成的公鑰-serverKey

三、客戶端發送本身生成的公鑰-clientKey
四、客戶端與服務器根據本身的私鑰與對方的公鑰生成對稱加密的密鑰。
五、進行加密通信緩存

使用wiresharp抓包分析

下面抓取www.juejin.im爲例:
安全

一、Client hello
服務器

  • 協議版本號Version:TLS 1.2
  • 隨機數Random
  • 支持17種安全套件的列表

二、Server hello中:
session

  • 協議版本號Version:TLS 1.2dom

  • 選中了一個安全套件:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • 隨機數Random

  • 發送數字證書:

  • 發送server的公鑰以及所用的簽名算法:

三、Client發送本身的公鑰

四、clientserver根據本身的私鑰與對方的公鑰生成對稱加密的密鑰

五、Change Cipher Spec這一步是客戶端通知服務端後面再發送的消息都會使用前面協商出來的密鑰加密了並通知server握手結束。

六、Change Cipher Spec這一步是服務端通知客戶端後面再發送的消息都會使用加密並通知client握手結束。

TLS1.3握手

TLS1.3中,大大減小了所支持的安全套件。好比在openssl1.1中只支持5種安全套件

  • TLS13-AES-256-GCM-SHA384
  • TLS13-CHACHA20-POLY1305-SHA256
  • TLS-AES-128-GCM-SHA256
  • TLS-AES-128-CCM-8-SHA256
  • TLS-AES-128-CCM-SHA256

TLS1.3握手的變化:
因爲安全套件的減小,client能夠在第一次請求中將5種安全套件所有生成一對密鑰,將5種publicKey發送給server,而後server選擇其中一種安全套件來生成本身的一對密鑰。從而相比上面說的TLS1.2的握手過程減小了一次RTT

握手過程的優化

TLS握手中消耗的那一個或兩個RTT時間是對於安全性而言的。

但對於應用層的信息傳遞而言並無意義。

因此TLS提供了許多種手段來減小握手過程當中所消耗的RTT的時間。好比:session緩存、ticket票據等

session緩存

第一次握手後服務器會生成一個sessionID,而後傳給瀏覽器。

在必定時間內,好比幾個小時、幾天內。瀏覽器攜帶這個sessionID再次訪問服務器時,服務器會從緩存中提取這個sessionID所指向的加密密鑰。沒有必要再次根據ECDH協議生成新的密鑰,從而減小消耗的RTT時間。

下面以百度站點爲例:
當再次訪問百度站點時,client hello就會攜帶一個sessionID

client Hello步驟以後直接到了Change Cipher Spec。並無進行DH或者ECDH密鑰交換協議

Change Cipher Spec裏面就告訴Client,使用以前的密鑰

ticket票據

sesion機制不一樣的是,ticket機制不須要server花費緩存來存放。而是基於一個獨特的密碼,這個密碼是集羣中所共享的。基於這個密碼將ticket解密後,就能夠獲取到上一次生成的密鑰。

TLS1.3中的0RTT握手

所謂0RTT,指的是:第一次請求時就攜帶GET數據,在一次RTT後就立刻獲得RESPONSE。握手時間就是0RTT了。

事實上這也是第二次握手中才有的。當第一次握手時,clientserver就會把密鑰信息緩存下來。第二次訪問時,基於第一次緩存的,基於必定時間內有效的信息對報文進行加密。

重放攻擊

不管是sessionticket仍是TLS1.3中的0RTT都面臨着一個危險:重放攻擊
如圖所示:

若是Client發送一個使用上一次的密鑰加密的post請求給server,而一般一個post請求是會改變數據庫的。

若是這個報文被中間人獲取下來了,並且並不須要解密這份報文。而後在隨後的時間內,不斷的發送這個報文,就能夠不斷的改變數據庫以形成攻擊效果。

因此設定一個合適的過時時間是必要的。

結尾

更多文章請移步樓主github,若是喜歡請點一下star,對做者也是一種鼓勵。

相關文章
相關標籤/搜索