若是還沒嘗試過使用wiresharp
的話,能夠參照我以前寫過的文章《wireSharp的基本用法》。git
本篇文章不會詳細說TLS
的內容,請結合我上一篇文章《深刻TLS/SSL協議》一塊兒觀看。github
TLS1.2
中的握手過程主要有三個目的:算法
如圖所示:
一、客戶端發送一個Client Hello
,包含:數據庫
Client random
。二、服務器回一個Server Hello
,包括:瀏覽器
server
所選擇的安全套件。server
發送本身的數字證書-server Certificates
。server
發送本身生成的公鑰-serverKey
。三、客戶端發送本身生成的公鑰-clientKey
。
四、客戶端與服務器根據本身的私鑰與對方的公鑰生成對稱加密的密鑰。
五、進行加密通信緩存
下面抓取www.juejin.im
爲例:
安全
一、Client hello
:
服務器
Version:TLS 1.2
Random
二、Server hello
中:
session
協議版本號Version:TLS 1.2
dom
選中了一個安全套件:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
隨機數Random
發送數字證書:
發送server
的公鑰以及所用的簽名算法:
三、Client
發送本身的公鑰
四、client
與server
根據本身的私鑰與對方的公鑰生成對稱加密的密鑰
五、Change Cipher Spec
這一步是客戶端通知服務端後面再發送的消息都會使用前面協商出來的密鑰加密了並通知server
握手結束。
六、Change Cipher Spec
這一步是服務端通知客戶端後面再發送的消息都會使用加密並通知client
握手結束。
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
票據等
第一次握手後服務器會生成一個sessionID
,而後傳給瀏覽器。
在必定時間內,好比幾個小時、幾天內。瀏覽器攜帶這個sessionID
再次訪問服務器時,服務器會從緩存中提取這個sessionID
所指向的加密密鑰。沒有必要再次根據ECDH
協議生成新的密鑰,從而減小消耗的RTT
時間。
下面以百度站點爲例:
當再次訪問百度站點時,client hello
就會攜帶一個sessionID
:
而client Hello
步驟以後直接到了Change Cipher Spec
。並無進行DH
或者ECDH
密鑰交換協議
Change Cipher Spec
裏面就告訴Client
,使用以前的密鑰
與sesion
機制不一樣的是,ticket
機制不須要server
花費緩存來存放。而是基於一個獨特的密碼,這個密碼是集羣中所共享的。基於這個密碼將ticket
解密後,就能夠獲取到上一次生成的密鑰。
所謂0RTT
,指的是:第一次請求時就攜帶GET
數據,在一次RTT
後就立刻獲得RESPONSE
。握手時間就是0RTT
了。
事實上這也是第二次握手中才有的。當第一次握手時,client
與server
就會把密鑰信息緩存下來。第二次訪問時,基於第一次緩存的,基於必定時間內有效的信息對報文進行加密。
不管是session
、ticket
仍是TLS1.3
中的0RTT
都面臨着一個危險:重放攻擊
如圖所示:
若是Client
發送一個使用上一次的密鑰加密的post
請求給server
,而一般一個post
請求是會改變數據庫的。
若是這個報文被中間人獲取下來了,並且並不須要解密這份報文。而後在隨後的時間內,不斷的發送這個報文,就能夠不斷的改變數據庫以形成攻擊效果。
因此設定一個合適的過時時間是必要的。
更多文章請移步樓主github,若是喜歡請點一下star,對做者也是一種鼓勵。