互聯(lián)網(wǎng)的通信安全，建立在SSL/TLS協(xié)議之上。

本文簡(jiǎn)要介紹SSL/TLS協(xié)議的運(yùn)行機(jī)制。文章的重點(diǎn)是設(shè)計(jì)思想和運(yùn)行過(guò)程，不涉及具體的實(shí)現(xiàn)細(xì)節(jié)。如果想了解這方面的內(nèi)容，請(qǐng)參閱RFC文檔。

一、作用

不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文傳播，帶來(lái)了三大風(fēng)險(xiǎn)。

（1） 竊聽(tīng)風(fēng)險(xiǎn)（eavesdropping）：第三方可以獲知通信內(nèi)容。

（2） 篡改風(fēng)險(xiǎn)（tampering）：第三方可以修改通信內(nèi)容。

（3） 冒充風(fēng)險(xiǎn)（pretending）：第三方可以冒充他人身份參與通信。

SSL/TLS協(xié)議是為了解決這三大風(fēng)險(xiǎn)而設(shè)計(jì)的，希望達(dá)到：

（1） 所有信息都是加密傳播，第三方無(wú)法竊聽(tīng)。

（2） 具有校驗(yàn)機(jī)制，一旦被篡改，通信雙方會(huì)立刻發(fā)現(xiàn)。

（3） 配備身份證書(shū)，防止身份被冒充。

互聯(lián)網(wǎng)是開(kāi)放環(huán)境，通信雙方都是未知身份，這為協(xié)議的設(shè)計(jì)帶來(lái)了很大的難度。而且，協(xié)議還必須能夠經(jīng)受所有匪夷所思的攻擊，這使得SSL/TLS協(xié)議變得異常復(fù)雜。

二、歷史

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

1994年，NetScape公司設(shè)計(jì)了SSL協(xié)議（Secure Sockets Layer）的1.0版，但是未發(fā)布。

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

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

1999年，互聯(lián)網(wǎng)標(biāo)準(zhǔn)化組織ISOC接替NetScape公司，發(fā)布了SSL的升級(jí)版TLS 1.0版。

2006年和2008年，TLS進(jìn)行了兩次升級(jí)，分別為T(mén)LS 1.1版和TLS 1.2版。最新的變動(dòng)是2011年TLS 1.2的修訂版。

目前，應(yīng)用最廣泛的是TLS 1.0，接下來(lái)是SSL 3.0。但是，主流瀏覽器都已經(jīng)實(shí)現(xiàn)了TLS 1.2的支持。

TLS 1.0通常被標(biāo)示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。

三、基本的運(yùn)行過(guò)程

SSL/TLS協(xié)議的基本思路是采用公鑰加密法，也就是說(shuō)，客戶(hù)端先向服務(wù)器端索要公鑰，然后用公鑰加密信息，服務(wù)器收到密文后，用自己的私鑰解密。

但是，這里有兩個(gè)問(wèn)題。

（1）如何保證公鑰不被篡改？

解決方法：將公鑰放在數(shù)字證書(shū)中。只要證書(shū)是可信的，公鑰就是可信的。

（2）公鑰加密計(jì)算量太大，如何減少耗用的時(shí)間？

解決方法：每一次對(duì)話(huà)（session），客戶(hù)端和服務(wù)器端都生成一個(gè)"對(duì)話(huà)密鑰"（session key），用它來(lái)加密信息。由于"對(duì)話(huà)密鑰"是對(duì)稱(chēng)加密，所以運(yùn)算速度非?？?，而服務(wù)器公鑰只用于加密"對(duì)話(huà)密鑰"本身，這樣就減少了加密運(yùn)算的消耗時(shí)間。

因此，SSL/TLS協(xié)議的基本過(guò)程是這樣的：

（1） 客戶(hù)端向服務(wù)器端索要并驗(yàn)證公鑰。

（2） 雙方協(xié)商生成"對(duì)話(huà)密鑰"。

（3） 雙方采用"對(duì)話(huà)密鑰"進(jìn)行加密通信。

上面過(guò)程的前兩步，又稱(chēng)為"握手階段"（handshake）。

四、握手階段的詳細(xì)過(guò)程

"握手階段"涉及四次通信，我們一個(gè)個(gè)來(lái)看。需要注意的是，"握手階段"的所有通信都是明文的。

4.1 客戶(hù)端發(fā)出請(qǐng)求（ClientHello）

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

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

（1） 支持的協(xié)議版本，比如TLS 1.0版。

（2） 一個(gè)客戶(hù)端生成的隨機(jī)數(shù)，稍后用于生成"對(duì)話(huà)密鑰"。

（3） 支持的加密方法，比如RSA公鑰加密。

（4） 支持的壓縮方法。

這里需要注意的是，客戶(hù)端發(fā)送的信息之中不包括服務(wù)器的域名。也就是說(shuō)，理論上服務(wù)器只能包含一個(gè)網(wǎng)站，否則會(huì)分不清應(yīng)該向客戶(hù)端提供哪一個(gè)網(wǎng)站的數(shù)字證書(shū)。這就是為什么通常一臺(tái)服務(wù)器只能有一張數(shù)字證書(shū)的原因。

對(duì)于虛擬主機(jī)的用戶(hù)來(lái)說(shuō)，這當(dāng)然很不方便。2006年，TLS協(xié)議加入了一個(gè)Server Name Indication擴(kuò)展，允許客戶(hù)端向服務(wù)器提供它所請(qǐng)求的域名。

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

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

（1） 確認(rèn)使用的加密通信協(xié)議版本，比如TLS 1.0版本。如果瀏覽器與服務(wù)器支持的版本不一致，服務(wù)器關(guān)閉加密通信。

（2） 一個(gè)服務(wù)器生成的隨機(jī)數(shù)，稍后用于生成"對(duì)話(huà)密鑰"。

（3） 確認(rèn)使用的加密方法，比如RSA公鑰加密。

（4） 服務(wù)器證書(shū)。

除了上面這些信息，如果服務(wù)器需要確認(rèn)客戶(hù)端的身份，就會(huì)再包含一項(xiàng)請(qǐng)求，要求客戶(hù)端提供"客戶(hù)端證書(shū)"。比如，金融機(jī)構(gòu)往往只允許認(rèn)證客戶(hù)連入自己的網(wǎng)絡(luò)，就會(huì)向正式客戶(hù)提供USB密鑰，里面就包含了一張客戶(hù)端證書(shū)。

4.3 客戶(hù)端回應(yīng)

客戶(hù)端收到服務(wù)器回應(yīng)以后，首先驗(yàn)證服務(wù)器證書(shū)。如果證書(shū)不是可信機(jī)構(gòu)頒布、或者證書(shū)中的域名與實(shí)際域名不一致、或者證書(shū)已經(jīng)過(guò)期，就會(huì)向訪(fǎng)問(wèn)者顯示一個(gè)警告，由其選擇是否還要繼續(xù)通信。

如果證書(shū)沒(méi)有問(wèn)題，客戶(hù)端就會(huì)從證書(shū)中取出服務(wù)器的公鑰。然后，向服務(wù)器發(fā)送下面三項(xiàng)信息。

（1） 一個(gè)隨機(jī)數(shù)。該隨機(jī)數(shù)用服務(wù)器公鑰加密，防止被竊聽(tīng)。

（2） 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。

（3） 客戶(hù)端握手結(jié)束通知，表示客戶(hù)端的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值，用來(lái)供服務(wù)器校驗(yàn)。

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

至于為什么一定要用三個(gè)隨機(jī)數(shù)，來(lái)生成"會(huì)話(huà)密鑰"，dog250解釋得很好：

"不管是客戶(hù)端還是服務(wù)器，都需要隨機(jī)數(shù)，這樣生成的密鑰才不會(huì)每次都一樣。由于SSL協(xié)議中證書(shū)是靜態(tài)的，因此十分有必要引入一種隨機(jī)因素來(lái)保證協(xié)商出來(lái)的密鑰的隨機(jī)性。

對(duì)于RSA密鑰交換算法來(lái)說(shuō)，pre-master-key本身就是一個(gè)隨機(jī)數(shù)，再加上hello消息中的隨機(jī)，三個(gè)隨機(jī)數(shù)通過(guò)一個(gè)密鑰導(dǎo)出器最終導(dǎo)出一個(gè)對(duì)稱(chēng)密鑰。

pre master的存在在于SSL協(xié)議不信任每個(gè)主機(jī)都能產(chǎn)生完全隨機(jī)的隨機(jī)數(shù)，如果隨機(jī)數(shù)不隨機(jī)，那么pre master secret就有可能被猜出來(lái)，那么僅適用pre master secret作為密鑰就不合適了，因此必須引入新的隨機(jī)因素，那么客戶(hù)端和服務(wù)器加上pre master secret三個(gè)隨機(jī)數(shù)一同生成的密鑰就不容易被猜出了，一個(gè)偽隨機(jī)可能完全不隨機(jī)，可是是三個(gè)偽隨機(jī)就十分接近隨機(jī)了，每增加一個(gè)自由度，隨機(jī)性增加的可不是一。"

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

4.4 服務(wù)器的最后回應(yīng)

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

（1）編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。

（2）服務(wù)器握手結(jié)束通知，表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值，用來(lái)供客戶(hù)端校驗(yàn)。

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

五、參考鏈接

• 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?

（完）