SSL TLS 握手過程

2021-09-25 03:59:15 字數 3629 閱讀 1583

transport layer security

傳輸層安全協議

high performance browser networking

|  o'reilly: transport layer security (tls)

defined

protocol

year

ssl 1.0

n/assl 2.0

1995

ssl 3.0

1996

tls 1.0

1999

tls 1.1

2006

tls 1.2

2008

tls 1.3

tbd對於 tls 的發展過程以及涉及的基本概念可以參考 wiki 

1、客戶端傳送 clienthello 訊息,包括 最高支援的 tls 協議版本,隨機數,加密套件,壓縮演算法。如果希望下次重用握手,可以包含 session id。如果客戶端使用 alpn,可以包括應用層的協議列表,比如http2

2、伺服器回乙個 severhello 訊息,包括選擇的協議版本,隨機數,選擇的加密套件和壓縮演算法。伺服器確認或者允許重用握手可能需要傳送乙個 session id。選擇的協議版本應該是客戶端和服務端都支援的最高版本

3、服務端傳送 certificate 訊息

4、伺服器傳送 serverkeyexchange 訊息,使用rsa進行金鑰交換無需交換任何臨時引數,所以可以沒有 serverkeyexchange 階段,

5、伺服器傳送 serverhellodone 訊息,表示握手協議完成

6、客戶端生成 premastersecret 並用伺服器的公鑰加密,回應 clientkeyexchange 訊息,包括 premastersecret,可能包括客戶端的公鑰。

7、客戶端和服務端利用兩個隨機數和 premastersecret 生成 master secret,也就是接下來使用的對稱秘鑰(session key)

8、客戶端傳送 changecipherspec 告訴對方接下來所有的訊息都是經過加密的

9、最後客戶端傳送加密的 finished 訊息,並且包含 mac。伺服器解密並且驗證 mac,如果解密或者驗證失敗,握手失敗

10、服務端傳送 changecipherspec 告訴對方接下來所有的訊息都是經過加密的

11、服務端傳送加密的 finished 訊息,客戶端解密並驗證

12、握手完成

有時候客戶端需要驗證,這就導致比基本的tls握手多了兩個步驟。客戶端在 serverhellodone 訊息之後傳送 certificate 訊息,攜帶自己的證書。並且傳送 certificateverify 訊息,攜帶經過自己私鑰加密的簽名。伺服器收到證書和簽名之後用客戶端的公鑰做驗證。

迪菲-赫爾曼金鑰交換

這裡其實主要是多了乙個步驟,serverkeyexchange 交換 dh parameter,使用 diffie-hellman parameters 生成 premastersecret

一般現在web伺服器的架構是nginx+openssl(假設是),nginx只支援單機多程序間共享的session cache,所以為了可靠性一般需要有全域性的分布式session cache,這樣就能保證在多台web伺服器之間共享使用session id。

session cache 的方案需要在伺服器做快取,會導致服務端需要較大的記憶體。

session ticket  是不需要消耗伺服器的記憶體的,但必須保證 nginx 集群使用相同的 session ticket 加解密演算法,不然就會導致 session ticket 在不同的 nginx 機器上解密錯誤而不能重用。

參考 wiki: tls record

optimizing the tls record size:optimizing tls record size & buffering latency

幾種常見的加密套件:

kx 為 rsa 時候,au 也必須為 rsa,且可以省略

rsa:由client生成 premaster secrete,用 server 的公鑰加密後在 clientkeyexchange 包中傳給 server,server再用自己的私鑰解密。rsa秘鑰的長度,至少應大於2048位才是安全的,較長的秘鑰使得rsa解密乙個256位的 premaster secrete 需要2ms左右,比較消耗服務端cpu資源。

ecdhe (elliptic curve diffie–hellman exchange) = ecc + dh + e,是在dh演算法的基礎上,加入了橢圓曲線演算法,使得所需秘鑰的長度變短,最後的e表示每次動態生成引數和key,其中引數使用了證書中公鑰對應的私鑰進行了簽名。

因為使用了rsa 2048位的私鑰進行簽名,引數簽名後長度變成了256位元組。如果使用金鑰為256位的ecdsa證書,則只需32個位元組。

client 使用動態引數、自己的臨時私鑰和server的臨時公鑰來生成乙個premaster secret。

server 使用動態引數、自己的臨時私鑰和client的臨時公鑰(在clientkeyexchange包中傳出)生成相同的premaster secret。

ecdhe 演算法有更短的金鑰,能更快地得到對稱加密的金鑰,相比rsa消耗更少的服務端cpu資源。而且搭配ecdsa證書會有更好的效果。

待續~~~

互動應用層資料時使用的對稱加密演算法

message authentication code 互動應用層資料時使用的hash演算法,檢驗資料的完整性

md5 以及 sha-1 已被攻破

tls false start是google提出來的優化方法,其做法是:在tls協商階段,客戶端傳送 changecipherspec 和 finished 後,立即傳送加密的應用層資料,而無需等待伺服器端的確認。

客戶端在傳送 changecipherspec 和 finished 後,並沒有等待伺服器端的確認就立即傳送了加密應用資料。這樣就省去了乙個rt。

SSL TLS握手過程

ssl secure socket layer 最初是由netscape公司開發的乙個協議,其目的在於為網際網路提供乙個安全的通訊機制。netscape最早對外公布的版本是ssl2.0,但是由於ssl2.0有一些安全方面的缺陷,所以後來又重新設計了ssl3.0。ssl後來被ietf ineterne...

SSL TLS 握手過程詳解

我們知道,http 協議都是明文傳輸內容,在早期只展示靜態內容時沒有問題。伴隨著網際網路的快速發展,人們對於網路傳輸安全性的要求也越來越高,https 協議因此出現。如上圖所示,在 https 加密中真正起作用的其實是 ssl tls 協議。ssl tls 協議作用在 http 協議之下,對於上層應...

SSL TLS 握手過程詳解

我們知道,http 協議都是明文傳輸內容,在早期只展示靜態內容時沒有問題。伴隨著網際網路的快速發展,人們對於網路傳輸安全性的要求也越來越高,https 協議因此出現。如下圖所示,在 https 加密中真正起作用的其實是 ssl tls 協議。ssl tls 協議作用在 http 協議之下,對於上層應...