怎么徹底弄懂SSL/TLS協(xié)議

這篇文章給大家介紹怎么徹底弄懂SSL/TLS協(xié)議，內(nèi)容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

SSL/TLS是一種密碼通信框架，他是世界上使用最廣泛的密碼通信方法。SSL/TLS綜合運用了密碼學(xué)中的對稱密碼，消息認(rèn)證碼，公鑰密碼，數(shù)字簽名，偽隨機數(shù)生成器等，可以說是密碼學(xué)中的集大成者。

SSL(Secure Socket Layer)安全套接層，是1994年由Netscape公司設(shè)計的一套協(xié)議，并與1995年發(fā)布了3.0版本。

TLS(Transport Layer Security)傳輸層安全是IETF在SSL3.0基礎(chǔ)上設(shè)計的協(xié)議，實際上相當(dāng)于SSL的后續(xù)版本。

SSL/TLS的應(yīng)用

SSL/TLS是一個安全通信框架，上面可以承載HTTP協(xié)議或者SMTP/POP3協(xié)議等。

TLS協(xié)議的架構(gòu)

TLS主要分為兩層，底層的是TLS記錄協(xié)議，主要負責(zé)使用對稱密碼對消息進行加密。

上層的是TLS握手協(xié)議，主要分為握手協(xié)議，密碼規(guī)格變更協(xié)議和應(yīng)用數(shù)據(jù)協(xié)議4個部分。

• 握手協(xié)議負責(zé)在客戶端和服務(wù)器端商定密碼算法和共享密鑰，包括證書認(rèn)證，是4個協(xié)議中最最復(fù)雜的部分。

• 密碼規(guī)格變更協(xié)議負責(zé)向通信對象傳達變更密碼方式的信號

• 警告協(xié)議負責(zé)在發(fā)生錯誤的時候?qū)㈠e誤傳達給對方

• 應(yīng)用數(shù)據(jù)協(xié)議負責(zé)將TLS承載的應(yīng)用數(shù)據(jù)傳達給通信對象的協(xié)議。

握手協(xié)議

握手協(xié)議是TLS協(xié)議中非常重要的協(xié)議，通過客戶端和服務(wù)器端的交互，和共享一些必要信息，從而生成共享密鑰和交互證書。

不說話，先上圖：

接下來我們一步步的介紹每一步的含義：

1. client hello

   客戶端向服務(wù)器端發(fā)送一個client hello的消息，包含下面內(nèi)容：

• 可用版本號

• 當(dāng)前時間

• 客戶端隨機數(shù)

• 會話ID

• 可用的密碼套件清單

• 可用的壓縮方式清單

我們之前提到了TLS其實是一套加密框架，其中的有些組件其實是可以替換的，這里可用版本號，可用的密碼套件清單，可用的壓縮方式清單就是向服務(wù)器詢問對方支持哪些服務(wù)。

客戶端隨機數(shù)是一個由客戶端生成的隨機數(shù)，用來生成對稱密鑰。

2. server hello

   服務(wù)器端收到client hello消息后，會向客戶端返回一個server hello消息，包含如下內(nèi)容：

• 使用的版本號

• 當(dāng)前時間

• 服務(wù)器隨機數(shù)

• 會話ID

• 使用的密碼套件

• 使用的壓縮方式

使用的版本號，使用的密碼套件，使用的壓縮方式是對步驟1的回答。

服務(wù)器隨機數(shù)是一個由服務(wù)器端生成的隨機數(shù)，用來生成對稱密鑰。

3. 可選步驟:certificate

   服務(wù)器端發(fā)送自己的證書清單，因為證書可能是層級結(jié)構(gòu)的，所以處理服務(wù)器自己的證書之外，還需要發(fā)送為服務(wù)器簽名的證書。 客戶端將會對服務(wù)器端的證書進行驗證。如果是以匿名的方式通信則不需要證書。

4. 可選步驟:ServerKeyExchange

   如果第三步的證書信息不足，則可以發(fā)送ServerKeyExchange用來構(gòu)建加密通道。

   ServerKeyExchange的內(nèi)容可能包含兩種形式：

• 如果選擇的是RSA協(xié)議，那么傳遞的就是RSA構(gòu)建公鑰密碼的參數(shù)（E，N）。我們回想一下RSA中構(gòu)建公鑰的公式：$密文=明文^E\ mod\ N$， 只要知道了E和N，那么就知道了RSA的公鑰，這里傳遞的就是E，N兩個數(shù)字。具體內(nèi)容可以參考RSA算法詳解

• 如果選擇的是Diff-Hellman密鑰交換協(xié)議，那么傳遞的就是密鑰交換的參數(shù)，具體內(nèi)容可以參考更加安全的密鑰生成方法Diffie-Hellman

5. 可選步驟:CertificateRequest

   如果是在一個受限訪問的環(huán)境，比如fabric中，服務(wù)器端也需要向客戶端索要證書。 如果并不需要客戶端認(rèn)證，則不需要此步驟。

6. server hello done 服務(wù)器端發(fā)送server hello done的消息告訴客戶端自己的消息結(jié)束了。

7. 可選步驟:Certificate

   對步驟5的回應(yīng)，客戶端發(fā)送客戶端證書給服務(wù)器

8. ClientKeyExchange

   還是分兩種情況：

• 如果是公鑰或者RSA模式情況下，客戶端將根據(jù)客戶端生成的隨機數(shù)和服務(wù)器端生成的隨機數(shù)，生成預(yù)備主密碼，通過該公鑰進行加密，返送給服務(wù)器端。

• 如果使用的是Diff-Hellman密鑰交換協(xié)議，則客戶端會發(fā)送自己這一方要生成Diff-Hellman密鑰而需要公開的值。具體內(nèi)容可以參考更加安全的密鑰生成方法Diffie-Hellman，這樣服務(wù)器端可以根據(jù)這個公開值計算出預(yù)備主密碼。

9. 可選步驟:CertificateVerify

   客戶端向服務(wù)器端證明自己是客戶端證書的持有者。

10. ChangeCipherSpec(準(zhǔn)備切換密碼)

    ChangeCipherSpec是密碼規(guī)格變更協(xié)議的消息，表示后面的消息將會以前面協(xié)商過的密鑰進行加密。

11. finished(握手協(xié)議結(jié)束)

    客戶端告訴服務(wù)器端握手協(xié)議結(jié)束了。

12. ChangeCipherSpec(準(zhǔn)備切換密碼)

    服務(wù)器端告訴客戶端自己要切換密碼了。

13. finished(握手協(xié)議結(jié)束)

    服務(wù)器端告訴客戶端，握手協(xié)議結(jié)束了。

14. 切換到應(yīng)用數(shù)據(jù)協(xié)議

    這之后服務(wù)器和客戶端就是以加密的方式進行溝通了。

主密碼和預(yù)備主密碼

上面的步驟8生成了預(yù)備主密碼，主密碼是根據(jù)密碼套件中定義的單向散列函數(shù)實現(xiàn)的偽隨機數(shù)生成器+預(yù)備主密碼+客戶端隨機數(shù)+服務(wù)器端隨機數(shù)生成的。

主密碼主要用來生成稱密碼的密鑰，消息認(rèn)證碼的密鑰和對稱密碼的CBC模式所使用的初始化向量。詳見分組密碼和模式

TLS記錄協(xié)議

TLS記錄協(xié)議主要負責(zé)消息的壓縮，加密及數(shù)據(jù)的認(rèn)證：

先上圖。

消息首先將會被分段，然后壓縮，再計算其消息驗證碼，然后使用對稱密碼進行加密，加密使用的是CBC模式，CBC模式的初始向量是通過主密碼來生成的。

得到密文之后會附加類型，版本和長度等其他信息，最終組成最后的報文數(shù)據(jù)。

關(guān)于怎么徹底弄懂SSL/TLS協(xié)議就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。