備注：學(xué)習(xí) SSL/TLS 是為更深刻地理解 HTTPS 作知識儲備。

一、SSL/TSL協(xié)議的產(chǎn)生背景

1> 目前互聯(lián)網(wǎng)常用的 'HTTP協(xié)議' 是非常不安全的明文傳輸協(xié)議。
2> 'SSL協(xié)議'及其繼任者'TLS協(xié)議'，是一種實現(xiàn)網(wǎng)絡(luò)通信加密的安全協(xié)議。
3> 通過 SSL/TSL協(xié)議，可在客戶端（瀏覽器）和服務(wù)器端（網(wǎng)站）之間建立一條加密通道，保證數(shù)據(jù)在傳輸過程中不被竊取或篡改。
4> 'SSL證書'，也稱為 '服務(wù)器SSL證書'，是遵守SSL協(xié)議的一種數(shù)字證書。
5> 'SSL證書'由全球信任的證書頒發(fā)機構(gòu)(CA)驗證服務(wù)器身份后頒發(fā)。將SSL證書安裝在網(wǎng)站服務(wù)器上，可實現(xiàn)網(wǎng)站身份驗證和數(shù)據(jù)加密傳輸雙重功能。

二、SSL/TLS協(xié)議的作用

HTTP協(xié)議不使用 SSL/TLS，所以HTTP通信是不加密的通信，也就是說: HTTP通信過程中的所有信息都是明文傳輸?shù)摹?/p>

HTTP通信是明文傳輸，所以具有以下3大風(fēng)險:
1> 竊聽風(fēng)險(Eavesdropping)：'第三方可以竊聽(截獲)通信內(nèi)容'。
2> 篡改風(fēng)險(Tampering): '第三方可以修改通信的內(nèi)容'。
3> 冒充風(fēng)險(Pretending): '第三方可以冒充他人身份參與通信'。

SSL/TLS就是為了解決上述三大風(fēng)險而誕生的，目的是達(dá)到

1> 所有信息都是'加密傳播'，第三方無法竊聽(截獲)。
2> 具有'校驗機制'，一旦被篡改，通信雙方會立刻發(fā)現(xiàn)。
3> 配備'身份證書'，防止身份被冒充。

眾所周知，在互聯(lián)網(wǎng)上，通信雙方的身份都是未知的，這就為協(xié)議的設(shè)計帶來了很大的難度。而且，協(xié)議還必須能夠經(jīng)受所有匪夷所思的網(wǎng)絡(luò)攻擊，這就使得SSL/TLS協(xié)議變得非常復(fù)雜。

三、SSL/TLS的概念

1> SSL：(Secure Sockets Layer) '安全套接層',
2> TLS：(Transport Layer Security) '傳輸層安全'，TLS是SSL的繼任者。
3> SSL/TLS都是為網(wǎng)絡(luò)通信提供'安全'及'數(shù)據(jù)完整性'的一種安全協(xié)議。
4> TLS與SSL在'傳輸層'對網(wǎng)絡(luò)連接進(jìn)行加密。

四、SSL/TLS的歷史

1> 1994年，NetScape(網(wǎng)景)公司設(shè)計了SSL協(xié)議（Secure Sockets Layer）的1.0版，但是未發(fā)布。
2> 1995年，NetScape公司發(fā)布SSL 2.0版本，很快發(fā)現(xiàn)有嚴(yán)重漏洞。
3> 1996年，SSL 3.0版問世，得到大規(guī)模應(yīng)用。
4> 1999年，互聯(lián)網(wǎng)標(biāo)準(zhǔn)化組織ISOC接替NetScape公司，發(fā)布了SSL的升級版TLS 1.0版。
5> 2006年和2008年，TLS進(jìn)行了兩次升級，分別為TLS 1.1版和TLS 1.2版。最新的變動是2011年TLS 1.2的修訂版。
6> 目前，應(yīng)用最廣泛的是 TLS1.0版，接下來是 SSL3.0。但是，主流瀏覽器都已經(jīng)實現(xiàn)了對TLS1.2的支持。
注: TLS1.0通常被標(biāo)示為SSL3.1，TLS1.1為SSL3.2，TLS1.2為SSL3.3

五、SSL/TLS的基本運行過程

SSL/TLS協(xié)議的基本思路是: 采用公鑰加密法。

基本流程如下:

1> 客戶端先向服務(wù)器索要公鑰
2> 客戶端用公鑰加密信息
3> 服務(wù)器接收到秘文之后，用自己的私鑰解密

但是，存在兩個問題

1> 如何保證公鑰不被篡改?
解決辦法: 將公鑰放在'數(shù)字證書'中。'只要證書是可信的，公鑰就是可信'的。
2> 公鑰加密計算量太大，如何減少耗用的時間？
解決辦法: 
* 每一次對話(session)，客戶端和服務(wù)器都會生成一個'對話密鑰'(session key)，用它來加密信息。
* 由于'對話密鑰'是對稱加密，所以運算速度非常快，而服務(wù)器公鑰只用于加密'對話密鑰'本身，這樣就減少了加密運算的消耗時間。

因此，SSL/TLS協(xié)議的基本過程如下

1> 客戶端向服務(wù)器端索要并驗證公鑰。
2> 雙方協(xié)商生成'對話密鑰'。
3> 雙方采用'對話密鑰'進(jìn)行加密通信。
 注: 前兩步又稱為'握手階段'(handshake)

六、握手階段詳解

握手階段.png

由圖可知: 『握手階段』涉及4次通信，我們一一來解讀。需要注意的是，『握手階段』的所有通信都是明文的。

6.1 客戶端發(fā)出請求(ClicentHello)

首先，客戶端(通常是瀏覽器)先向服務(wù)器發(fā)出需要加密通信的請求，這被叫做ClientHello請求。

在這一步，客戶端主要向服務(wù)器提供以下信息:

1> 客戶端支持的協(xié)議版本，比如 TLS1.0版。
2> 一個客戶端生成的隨機數(shù)，稍后用于生成'對話密鑰'。
3> 客戶端支持的加密算法，比如RSA公鑰加密。
4> 客戶端支持的壓縮方法。

這里需要注意:

1> 客戶端發(fā)送的信息中不包括服務(wù)器的域名。
2> 也就是說，理論上服務(wù)器只能包含一個網(wǎng)站，否則就會分不清應(yīng)該向客戶端提供哪一個網(wǎng)站的數(shù)字證書。這就是為什么通常一臺服務(wù)器只能有一張數(shù)字證書的原因。
3> 對于虛擬主機的用戶來說，這當(dāng)然很不方便。2006年，TLS協(xié)議加入了一個Server Name Indication擴展，允許客戶端向服務(wù)器提供它所請求的域名。

6.2 服務(wù)器響應(yīng)(ServerHello)

服務(wù)器接收到客戶端的請求后，向客戶端發(fā)出響應(yīng)，這叫做ServerHello。
服務(wù)器的響應(yīng)包含以下內(nèi)容:

1> 確認(rèn)服務(wù)器自己使用的加密通信協(xié)議的版本，比如TLS1.0版本。如果客戶端和服務(wù)器支持的版本不一致，服務(wù)器就會關(guān)閉加密通信。
2> 一個服務(wù)器生成的隨機數(shù)，稍后用于生成'對話密鑰'。
3> 確認(rèn)使用的加密算法，比如RSA公鑰加密。
4> 服務(wù)器證書。

除了上面的信息，如果服務(wù)器需要確認(rèn)客戶端的身份，就會再包含一項請求，

5> 要求客戶端提供'客戶端證書'。
比如: 金融機構(gòu)往往只允許認(rèn)證客戶連入自己的網(wǎng)絡(luò)，就會向正式客戶提供USB密鑰，里面就包含了一張客戶端證書。

6.3 客戶端回應(yīng)

• 客戶端收到服務(wù)器回應(yīng)以后，首先驗證服務(wù)器證書。
• 如果證書不是可信機構(gòu)頒布、或者證書中的域名與實際域名不一致、或者證書已經(jīng)過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續(xù)通信。
• 如果證書沒有問題，客戶端就會從證書中取出服務(wù)器的公鑰。然后，向服務(wù)器發(fā)送下面三項信息。

1> 一個隨機數(shù)。該隨機數(shù)用服務(wù)器公鑰加密，防止被竊聽。
2> 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
3> 客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束。這一項同時也是前面發(fā)送的所有內(nèi)容的hash值，用來供服務(wù)器校驗。

• 上面第一項的隨機數(shù)，是整個握手階段出現(xiàn)的第三個隨機數(shù)，又稱"pre-master key"。有了它以后，客戶端和服務(wù)器就同時有了三個隨機數(shù)，接著雙方就用事先商定的加密方法，各自生成本次會話所用的同一把"會話密鑰"。

那么，為什么一定要用3個隨機數(shù)，來實現(xiàn)'會話密鑰'

1> 不管是客戶端還是服務(wù)器，都需要隨機數(shù)，這樣生成的密鑰才不會每次都一樣。
2> 由于SSL協(xié)議中證書是靜態(tài)的，因此十分有必要引入一種隨機因素來保證協(xié)商出來的密鑰的隨機性。
3> 對于RSA密鑰交換算法來說，pre-master-key本身就是一個隨機數(shù)，再加上hello消息中的隨機，三個隨機數(shù)通過一個密鑰導(dǎo)出器最終導(dǎo)出一個對稱密鑰。
pre master的存在在于SSL協(xié)議不信任每個主機都能產(chǎn)生完全隨機的隨機數(shù)，如果隨機數(shù)不隨機，那么pre master secret就有可能被猜出來，那么僅適用pre master secret作為密鑰就不合適了，因此必須引入新的隨機因素，那么客戶端和服務(wù)器加上pre master secret三個隨機數(shù)一同生成的密鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的可不是一。

此外，如果前一步，服務(wù)器要求客戶端證書，客戶端會在這一步發(fā)送證書及相關(guān)信息。

6.4 服務(wù)器的最后響應(yīng)

服務(wù)器收到客戶端的第三個隨機數(shù)pre-master key之后，計算生成本次會話所用的"會話密鑰"。然后，向客戶端最后發(fā)送下面信息。

1> 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
2> 服務(wù)器握手結(jié)束通知，表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項同時也是前面發(fā)送的所有內(nèi)容的hash值，用來供客戶端校驗。

至此，整個握手階段全部結(jié)束。接下來，客戶端與服務(wù)器進(jìn)入加密通信，就完全是使用普通的HTTP協(xié)議，只不過用"會話密鑰"對通信內(nèi)容進(jìn)行加密。

握手協(xié)議.png

參考鏈接

MicroSoft TechNet, SSL/TLS in Detail
Jeff Moser, The First Few Milliseconds of an HTTPS Connection
Wikipedia, Transport Layer Security
StackExchange, How does SSL work?