文章分享

本周，CloudFlare宣布，開(kāi)始提供Keyless服務(wù)，即你把網(wǎng)站放到它們的CDN上，不用提供自己的私鑰，也能使用SSL加密鏈接。

我看了CloudFlare的說(shuō)明（這里和這里），突然意識(shí)到這是絕好的例子，可以用來(lái)說(shuō)明SSL/TLS協(xié)議的運(yùn)行機(jī)制。它配有插圖，很容易看懂。

下面，我就用這些圖片作為例子，配合我半年前寫(xiě)的《SSL/TLS協(xié)議運(yùn)行機(jī)制的概述》，來(lái)解釋SSL協(xié)議。

一、SSL協(xié)議的握手過(guò)程

開(kāi)始加密通信之前，客戶端和服務(wù)器首先必須建立連接和交換參數(shù)，這個(gè)過(guò)程叫做握手（handshake）。

假定客戶端叫做愛(ài)麗絲，服務(wù)器叫做鮑勃，整個(gè)握手過(guò)程可以用下圖說(shuō)明（點(diǎn)擊看大圖）。

握手階段分成五步。

第一步，愛(ài)麗絲給出協(xié)議版本號(hào)、一個(gè)客戶端生成的隨機(jī)數(shù)（Client random），以及客戶端支持的加密方法。

第二步，鮑勃確認(rèn)雙方使用的加密方法，并給出數(shù)字證書(shū)、以及一個(gè)服務(wù)器生成的隨機(jī)數(shù)（Server random）。

第三步，愛(ài)麗絲確認(rèn)數(shù)字證書(shū)有效，然后生成一個(gè)新的隨機(jī)數(shù)（Premaster secret），并使用數(shù)字證書(shū)中的公鑰，加密這個(gè)隨機(jī)數(shù)，發(fā)給鮑勃。

第四步，鮑勃使用自己的私鑰，獲取愛(ài)麗絲發(fā)來(lái)的隨機(jī)數(shù)（即Premaster secret）。

第五步，愛(ài)麗絲和鮑勃根據(jù)約定的加密方法，使用前面的三個(gè)隨機(jī)數(shù)，生成"對(duì)話密鑰"（session key），用來(lái)加密接下來(lái)的整個(gè)對(duì)話過(guò)程。

上面的五步，畫(huà)成一張圖，就是下面這樣。

二、私鑰的作用

握手階段有三點(diǎn)需要注意。

（1）生成對(duì)話密鑰一共需要三個(gè)隨機(jī)數(shù)。

（2）握手之后的對(duì)話使用"對(duì)話密鑰"加密（對(duì)稱加密），服務(wù)器的公鑰和私鑰只用于加密和解密"對(duì)話密鑰"（非對(duì)稱加密），無(wú)其他作用。

（3）服務(wù)器公鑰放在服務(wù)器的數(shù)字證書(shū)之中。

從上面第二點(diǎn)可知，整個(gè)對(duì)話過(guò)程中（握手階段和其后的對(duì)話），服務(wù)器的公鑰和私鑰只需要用到一次。這就是CloudFlare能夠提供Keyless服務(wù)的根本原因。

某些客戶（比如銀行）想要使用外部CDN，加快自家網(wǎng)站的訪問(wèn)速度，但是出于安全考慮，不能把私鑰交給CDN服務(wù)商。這時(shí)，完全可以把私鑰留在自家服務(wù)器，只用來(lái)解密對(duì)話密鑰，其他步驟都讓CDN服務(wù)商去完成。

上圖中，銀行的服務(wù)器只參與第四步，后面的對(duì)話都不再會(huì)用到私鑰了。

三、DH算法的握手階段

整個(gè)握手階段都不加密（也沒(méi)法加密），都是明文的。因此，如果有人竊聽(tīng)通信，他可以知道雙方選擇的加密方法，以及三個(gè)隨機(jī)數(shù)中的兩個(gè)。整個(gè)通話的安全，只取決于第三個(gè)隨機(jī)數(shù)（Premaster secret）能不能被破解。

雖然理論上，只要服務(wù)器的公鑰足夠長(zhǎng)（比如2048位），那么Premaster secret可以保證不被破解。但是為了足夠安全，我們可以考慮把握手階段的算法從默認(rèn)的RSA算法，改為 Diffie-Hellman算法（簡(jiǎn)稱DH算法）。

采用DH算法后，Premaster secret不需要傳遞，雙方只要交換各自的參數(shù)，就可以算出這個(gè)隨機(jī)數(shù)。

上圖中，第三步和第四步由傳遞Premaster secret變成了傳遞DH算法所需的參數(shù)，然后雙方各自算出Premaster secret。這樣就提高了安全性。

四、session的恢復(fù)

握手階段用來(lái)建立SSL連接。如果出于某種原因，對(duì)話中斷，就需要重新握手。

這時(shí)有兩種方法可以恢復(fù)原來(lái)的session：一種叫做session ID，另一種叫做session ticket。

session ID的思想很簡(jiǎn)單，就是每一次對(duì)話都有一個(gè)編號(hào)（session ID）。如果對(duì)話中斷，下次重連的時(shí)候，只要客戶端給出這個(gè)編號(hào)，且服務(wù)器有這個(gè)編號(hào)的記錄，雙方就可以重新使用已有的"對(duì)話密鑰"，而不必重新生成一把。

上圖中，客戶端給出session ID，服務(wù)器確認(rèn)該編號(hào)存在，雙方就不再進(jìn)行握手階段剩余的步驟，而直接用已有的對(duì)話密鑰進(jìn)行加密通信。

session ID是目前所有瀏覽器都支持的方法，但是它的缺點(diǎn)在于session ID往往只保留在一臺(tái)服務(wù)器上。所以，如果客戶端的請(qǐng)求發(fā)到另一臺(tái)服務(wù)器，就無(wú)法恢復(fù)對(duì)話。session ticket就是為了解決這個(gè)問(wèn)題而誕生的，目前只有Firefox和Chrome瀏覽器支持。

上圖中，客戶端不再發(fā)送session ID，而是發(fā)送一個(gè)服務(wù)器在上一次對(duì)話中發(fā)送過(guò)來(lái)的session ticket。這個(gè)session ticket是加密的，只有服務(wù)器才能解密，其中包括本次對(duì)話的主要信息，比如對(duì)話密鑰和加密方法。當(dāng)服務(wù)器收到session ticket以后，解密后就不必重新生成對(duì)話密鑰了。

（完）