圖解SSL/TLS協議（轉）

本週，CloudFlare宣佈，開始提供Keyless服務，即你把網站放到它們的CDN上，不用提供本身的私鑰，也能使用SSL加密連接。

我看了CloudFlare的說明（這裏和這裏），忽然意識到這是絕好的例子，能夠用來講明SSL/TLS協議的運行機制。它配有插圖，很容易看懂。

下面，我就用這些圖片做爲例子，配合我半年前寫的《SSL/TLS協議運行機制的概述》，來解釋SSL協議。

1、SSL協議的握手過程

開始加密通訊以前，客戶端和服務器首先必須創建鏈接和交換參數，這個過程叫作握手（handshake）。

假定客戶端叫作愛麗絲，服務器叫作鮑勃，整個握手過程能夠用下圖說明（點擊看大圖）。

握手階段分紅五步。

第一步，愛麗絲給出協議版本號、一個客戶端生成的隨機數（Client random），以及客戶端支持的加密方法。

第二步，鮑勃確認雙方使用的加密方法，並給出數字證書、以及一個服務器生成的隨機數（Server random）。

第三步，愛麗絲確認數字證書有效，而後生成一個新的隨機數（Premaster secret），並使用數字證書中的公鑰，加密這個隨機數，發給鮑勃。

第四步，鮑勃使用本身的私鑰，獲取愛麗絲髮來的隨機數（即Premaster secret）。

第五步，愛麗絲和鮑勃根據約定的加密方法，使用前面的三個隨機數，生成"對話密鑰"（session key），用來加密接下來的整個對話過程。

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

2、私鑰的做用

握手階段有三點須要注意。

（1）生成對話密鑰一共須要三個隨機數。

（2）握手以後的對話使用"對話密鑰"加密（對稱加密），服務器的公鑰和私鑰只用於加密和解密"對話密鑰"（非對稱加密），無其餘做用。

（3）服務器公鑰放在服務器的數字證書之中。

從上面第二點可知，整個對話過程當中（握手階段和其後的對話），服務器的公鑰和私鑰只須要用到一次。這就是CloudFlare可以提供Keyless服務的根本緣由。

某些客戶（好比銀行）想要使用外部CDN，加快自家網站的訪問速度，可是出於安全考慮，不能把私鑰交給CDN服務商。這時，徹底能夠把私鑰留在自家服務器，只用來解密對話密鑰，其餘步驟都讓CDN服務商去完成。

上圖中，銀行的服務器只參與第四步，後面的對話都再也不會用到私鑰了。

3、DH算法的握手階段

整個握手階段都不加密（也無法加密），都是明文的。所以，若是有人竊聽通訊，他能夠知道雙方選擇的加密方法，以及三個隨機數中的兩個。整個通話的安全，只取決於第三個隨機數（Premaster secret）能不能被破解。

雖然理論上，只要服務器的公鑰足夠長（好比2048位），那麼Premaster secret能夠保證不被破解。可是爲了足夠安全，咱們能夠考慮把握手階段的算法從默認的RSA算法，改成 Diffie-Hellman算法（簡稱DH算法）。

採用DH算法後，Premaster secret不須要傳遞，雙方只要交換各自的參數，就能夠算出這個隨機數。

上圖中，第三步和第四步由傳遞Premaster secret變成了傳遞DH算法所需的參數，而後雙方各自算出Premaster secret。這樣就提升了安全性。

4、session的恢復

握手階段用來創建SSL鏈接。若是出於某種緣由，對話中斷，就須要從新握手。

這時有兩種方法能夠恢復原來的session：一種叫作session ID，另外一種叫作session ticket。

session ID的思想很簡單，就是每一次對話都有一個編號（session ID）。若是對話中斷，下次重連的時候，只要客戶端給出這個編號，且服務器有這個編號的記錄，雙方就能夠從新使用已有的"對話密鑰"，而沒必要從新生成一把。

上圖中，客戶端給出session ID，服務器確認該編號存在，雙方就再也不進行握手階段剩餘的步驟，而直接用已有的對話密鑰進行加密通訊。

session ID是目前全部瀏覽器都支持的方法，可是它的缺點在於session ID每每只保留在一臺服務器上。因此，若是客戶端的請求發到另外一臺服務器，就沒法恢復對話。session ticket就是爲了解決這個問題而誕生的，目前只有Firefox和Chrome瀏覽器支持。

上圖中，客戶端再也不發送session ID，而是發送一個服務器在上一次對話中發送過來的session ticket。這個session ticket是加密的，只有服務器才能解密，其中包括本次對話的主要信息，好比對話密鑰和加密方法。當服務器收到session ticket之後，解密後就沒必要從新生成對話密鑰了。