互聯(lián)網(wǎng)時代，我們無時不刻沉浸在網(wǎng)絡(luò)的浪潮。不知道大家是否注意到，在訪問一寫涉及到支付/金融/登錄/網(wǎng)購等敏感業(yè)務(wù)時，會發(fā)現(xiàn)這些網(wǎng)站都會被重定向到https:// 的 URL ，比如：

• 地址為綠色, 表示使用了加密傳輸，安全且可信任;
• 地址為紅色, 則表示雖然開啟了加密, 但網(wǎng)站身份未驗證, 不保證中間不會被人篡改。

從我們在地址欄敲下 https:// 網(wǎng)站那一剎那, 到內(nèi)容顯示到我們面前, 中間經(jīng)過了哪些過程了? 瀏覽器根據(jù)什么來判斷, 當(dāng)前網(wǎng)站網(wǎng)址是安全的還是未驗證的? 今天就跟大家一起探索互聯(lián)網(wǎng)外交安全策略SSL/TLS協(xié)議運行機制。

SSL/TLS協(xié)議的由來

由來

最早期的通信是不使用SSL/TLS的HTTP通信，也就是沒有加密的通信。在人們的信息傳遞過程中存在了很多的問題：被第三方竊聽，被第三方修改通信內(nèi)容，被第三方冒充他人身份參與通信。種種信息安全問題得到大家的重視。大家都希望能有一種加密的信息傳輸，能夠保證信息安全，SSL/TLS協(xié)議誕生。

歷史發(fā)展

互聯(lián)網(wǎng)加密通信協(xié)議的歷史，幾乎與互聯(lián)網(wǎng)一樣長：

1994年，NetScape公司設(shè)計了SSL 1.0版，但是未發(fā)布；

1995年，NetScape公司發(fā)布SSL 2.0版，很快發(fā)現(xiàn)有嚴(yán)重漏洞；

1996年，SSL 3.0版問世，得到大規(guī)模應(yīng)用；

1999年，互聯(lián)網(wǎng)工程任務(wù)組（IETF）標(biāo)準(zhǔn)化了一種名為TLS的新協(xié)議，這是SSL的升級版本；

2006年和2008年，TLS兩次升級，分別更新至TLS 1.1和TLS 1.2。緊接著2011年發(fā)布了TLS 1.2的修訂版；

TLS 1.3的最終版本于2018年8月發(fā)布，包含許多安全性和性能改進。

由此可見，SSL和TLS簡單地可以理解為是同一種協(xié)議的不同版本，故它們總是成對出現(xiàn)。

SSL/TLS在TCP/IP參考模型中的位置

SSL/TLS其實是一個協(xié)議族而非單個協(xié)議，由SSL/TLS握手協(xié)議、修改密文協(xié)議、報警協(xié)議以及記錄協(xié)議四部分組成。

SSL/TLS協(xié)議自身可分為兩層：主要的有SSL記錄協(xié)議和SSL握手協(xié)議。

SSL記錄協(xié)議建立在可靠的傳輸協(xié)議，如TCP之上，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等基本功能的支持。

SSL握手協(xié)議建立在SSL記錄協(xié)議之上，用于在實際的數(shù)據(jù)傳輸開始前，通信雙方進行身份認(rèn)證、協(xié)商交換密鑰等。

SSL/TLS如何實現(xiàn)安全保障呢

使用SSL/TLS協(xié)議，能夠使我們在互聯(lián)網(wǎng)上的通信做到“看不懂、改不掉、仿不了”，這組安全協(xié)議真的很復(fù)雜！分別對信息安全的機密性、完整性和可認(rèn)證性做了確認(rèn)。

機密性：當(dāng)通信雙方確信沒有人能夠理解他們的對話內(nèi)容時，通信被認(rèn)為是保密的。使用對稱加密可以實現(xiàn)通信的機密性。

完整性：SSL/TLS具有校驗機制，握手協(xié)議中定義了MAC，一旦信息被篡改，通信雙方會立即發(fā)現(xiàn)并采取措施。

可認(rèn)證性：為防止惡意攻擊者冒充合法網(wǎng)站，網(wǎng)站需要通過證書和公鑰加密來向Web瀏覽器證明自己的身份，在此過程中，瀏覽器需要兩件事情來信任證書：證明另一方是證書的持有者，并證明證書是可信的。

在互聯(lián)網(wǎng)通信中，通過建立共享密鑰和證明證書的所有權(quán)的過程來實現(xiàn)機密性和可認(rèn)證性，SSL/TLS協(xié)議則是通過“握手”流程來實現(xiàn)這兩點，當(dāng)中的完整性是由握手協(xié)議定義的MAC來實現(xiàn)。那么，如此至關(guān)重要的“握手”流程是怎么樣的呢？

詳解“握手”流程

'握手階段'涉及四次通信，我們一個個來看。需要注意的是，'握手階段'的所有通信都是明文的。

客戶端發(fā)出請求（ClientHello）

客戶端向服務(wù)器發(fā)出請求，會帶上以下信息：

1. 一個客戶端生成的隨機數(shù)
2. 支持的加密方式，即圖中的Cipher Suite
3. 支持SSL/TLS協(xié)議的版本號
4. Session ID，如果是之前斷開的會話，會帶上Session ID用來恢復(fù)會話。
5. 簽名使用的哈希算法

服務(wù)器回應(yīng)（SeverHello）

服務(wù)器響應(yīng)客戶端的請求，如果上一步帶上了Session ID，則直接恢復(fù)會話，否則帶上以下信息給客戶端：

1. 選擇SSL/TLS協(xié)議版本號
2. 選擇加密方式
3. 一個服務(wù)器生成的隨機數(shù)
4. 服務(wù)器證書

客戶端會在這里校驗服務(wù)器證書的合法性，包括檢測證書有效時間，以及證書中域名與當(dāng)前會話域名是否匹配，并沿著信任鏈查找頂層證書頒發(fā)者是否是操作系統(tǒng)信任的CA機構(gòu)。

客戶端回應(yīng)

客戶端校驗服務(wù)器證書的合法性，生成premaster secret，向服務(wù)器發(fā)送以下信息：

1. 用服務(wù)器證書取出的公鑰加密后的premaster secret，這里的premaster secret其實是另一個隨機數(shù)
2. 加密約定改變通知，通知服務(wù)器，以后的通信都適用協(xié)商好的加密方法和密鑰進行加密
3. 客戶端握手結(jié)束通知。這個報文也是驗證消息，是前面發(fā)送的所有內(nèi)容的哈希值，用來供服務(wù)器校驗。

服務(wù)器最后確認(rèn)

這是握手過程的最后一步，服務(wù)器會把以下信息發(fā)送給客戶端：

1. 加密約定改變通知，通知客戶端，以后的通信都適用協(xié)商好的加密方法和密鑰進行加密
2. 服務(wù)器握手結(jié)束通知，該報文也作為校驗消息，供客戶端驗證。

到這個時候，客戶端和服務(wù)器同時擁有了3個隨機數(shù)，使用這三個隨機數(shù)生成的密鑰，將被用于后續(xù)通信的對稱加密。

題外話

1.如何保證公鑰屬于被訪問的合法網(wǎng)站？

將公鑰放在數(shù)字證書中，簽發(fā)證書的CA是被信任的，故公鑰是被信任的。

2.為什么要這么復(fù)雜地產(chǎn)生會話密鑰，何不直接傳輸商定好的密鑰更方便？

隨著攻擊手段的不斷發(fā)展，任何傳輸過程都不受信任，即使將會話密鑰進行加密傳輸，都有被竊取的危險。因此采用Diffle-Hellman密鑰協(xié)商算法，在傳輸過程中能夠始終不出現(xiàn)會話密鑰本身，會話密鑰僅在握手結(jié)束時在客戶端和服務(wù)器本地各自生成。

3.既然產(chǎn)生對稱的會話密鑰很復(fù)雜，為什么不采用可避免密鑰泄露問題的公鑰加密？

因為公鑰加密相比于對稱加密，計算速度很慢，不適用于通信時的大量數(shù)據(jù)加密。

4.在握手過程中如何確認(rèn)服務(wù)器是私鑰持有者？

客戶端無法看見服務(wù)器的私鑰，那就讓服務(wù)器證明它可以使用私鑰即可，服務(wù)器使用私鑰對客戶端已知的信息進行數(shù)字簽名，若客戶端能夠用服務(wù)器的公鑰認(rèn)證該數(shù)字簽名，則可確定對方持有相應(yīng)私鑰。

今天比昨天更博學(xué)了！