一、SSL/TLS簡介

SSL（Secure Socket Layer）最初是由Netscape公司開發的一個協議，其目的在於為網際網路提供一個安全的通訊機制。Netscape最早對外公佈的版本是SSL2.0，但是由於SSL2.0有一些安全方面的缺陷，所以後來又重新設計了SSL3.0。SSL後來被IETF（Ineternet Engineering Task Force）所採納並重新命名為TLS（Transport Layer Security），也就是說，TLS其實是SSL的後續版本。TLS1.0是SSL3.0的一個升級版本，後續的小版本還有TLS1.1和TLS1.2。現在普遍使用的是SSL3.0或者TLS1.0。

SSL/TLS協議是位於應用層和傳輸層（如TCP）之間的，它和具體的應用層協議無關，也就是說，任何應用層協議都可以使用SSL/TLS來獲得安全通訊的能力，如HTTP/FTP/SMTP等。

二、SSL/TLS基本原理

我們知道，網際網路本身是一個公共的、不安全的網路。資料在網際網路上傳輸時，無法避免會被惡意的第三方監視、偷聽、截獲甚至篡改，更有甚者，正在和我們通訊的對方有可能根本就是假冒的，比如釣魚網站等。既然SSL/TLS要為網際網路提供一個安全通訊的機制，那麼它必須解決這裡所有提到的安全問題，具體說，SSL/TLS通過下面三個方面來為網際網路通訊提供安全保證。

1. 機密性保證

SSL/TLS對要傳輸的資料進行加密，這樣在網際網路的傳輸資料就是加密後的密文，即使被惡意的第三方監視和偷聽，由於沒有解密祕鑰，所以無法理解密文的意思。這也稱為SSL/TSL的防偷聽機制。

加密分為對稱加密和非對稱加密。對稱加密（AES/RC4/3DES）的優點是效率高，然而對稱加密使用的加密解密祕鑰是一樣的，這意味著加密方（即傳送方）必須把祕鑰傳送給接收方，顯然，在傳輸祕鑰的過程中，如果不加以保護，祕鑰就會被洩露。非對稱加密（RSA/ECC）則克服了對稱加密需要傳輸祕鑰的弱點，但是非對稱加密的效率很低，如果傳輸的資料量很大，那麼使用非對稱加密將是十分耗時的。也就是說，無論是對稱加密還是非對稱加密，都不能很好地滿足資料加密傳輸的要求，為此，SSL/TLS對這兩種方法取長補短，綜合應用。SSL/TLS利用非對稱加密來交換祕鑰資訊（祕鑰資訊並不是祕鑰，而是生成祕鑰時所需要用到的資訊），由於祕鑰資訊的資料量很少，使用非對稱加密還是可以接受的。而對於要傳輸的資料，SSL/TLS則使用對稱加密

2. 訊息完整性保證

由於惡意的第三方能夠截獲傳輸中的資料並把資料篡改後再發給接收方，所以SSL/TLS還必須提供一種方法來檢測資料是否被篡改過。這也稱為SSL/TLS的防篡改機制。具體地說，SSL/TLS使用MAC（訊息驗證碼）來實現防篡改，即在傳送訊息之前，把該訊息和一個通訊雙方共享的祕鑰作為一個hash演算法（MD5/SHA1）的輸入，再把由此求得的摘要值聯通訊息一起傳送給對方。

3. 身份真實性保證

SSL/TLS通過驗證身份來確保不會和假冒的對方通訊。這也稱為SSL/TLS的防假冒機制。SSL/TLS使用由私鑰簽名的數字證書來實現防假冒。一般來說，伺服器需要把它的數字證書傳給客戶端來驗證，而客戶端不一定需要提供證書。

三、SSL/TLS的握手過程

在開始傳輸應用程式資料之前，通訊的雙方必須先進行SSL/TLS握手。在握手的過程，雙方交換並協商重要的資訊，包括將要使用的SSL/TLS協議版本、加密演算法、MAC演算法、驗證演算法，以及用於各種演算法的祕鑰等。當然，任一方都可以在握手的過程中來驗證對方的真偽，一旦驗證失敗，握手過程將被終止，同時這個SSL/TLS連線也會被終止。具體說，SSL/TLS的握手過程可以分為三個階段：引數協商、身份驗證，以及祕鑰交換。

1. 引數協商

在這個階段，客戶端和伺服器確定一個雙方都能支援的最高版本的SSL/TLS協議，同時確定它們所使用的演算法組合（Cipher Suite）。演算法組合是分別用於不同目的的三個演算法的組合，包含用於交換祕鑰（Key Exchange）和身份驗證的演算法，用於加密應用程式資料的對稱加密演算法，以及用於訊息驗證的MAC演算法。在SSL/TLS中，一個演算法組合可以用一個字串來表示，如“TLS_RSA_WHIT_RC4_128_MD5”，這個演算法組合表示使用RSA來交換祕鑰和驗證身份，使用RC4來加密應用程式資料，以及使用MD5來驗證訊息內容（即防篡改）。另外，在這個階段中，客戶端和伺服器會分別產生一個隨機數，然後把其傳給對方，它們將會在後面的祕鑰交換階段中用到。

2. 身份驗證

如果在引數協商階段時所確定的演算法組合要求進行身份驗證（如RSA），則伺服器需要提供資訊（伺服器證書）來讓客戶端對齊進行身份驗證。反過來，伺服器也可以要求客戶端提供證書，以便伺服器也能夠驗證客戶端的身份，不過這並不是必須的。是否需要驗證客戶端主要是根據應用程式的要求。

3. 金鑰交換

在身份驗證通過以後，就可以進入金鑰交換階段。注意，在這個階段，客戶端和伺服器並不是直接交換祕鑰，而是交換生成祕鑰所需要用的資訊，這個資訊被稱為Pre-Master Secret，其實就是一個有客戶端產生的隨機數。如果在引數協商階段時所確定的演算法組合指明使用RSA來交換祕鑰，那麼客戶端將使用伺服器的公鑰（包含在伺服器的數字證書中）來加密這個Pre-Master Secret，然後再傳給伺服器，由於只有伺服器才有私鑰來進行解密，所以Pre-Master Secret的傳輸是安全的。有了Pre-Master Secret之後，客戶端和伺服器還需要再計算一個Master Secret，這是因為最終的祕鑰都是基於Master Secret而生成的。Master Secret本身則是通過對三個隨機數進行計算而得到的，除了Pre-Master Secret之外，另外兩個隨機數則是在引數協商階段交換的客戶端隨機數和伺服器隨機數。

最終生成的祕鑰一共有4個，分別是：

• 客戶端MAC寫入祕鑰。客戶端使用這個祕鑰來計算將要傳送的訊息的摘要，伺服器使用該祕鑰來驗證客戶端發過了的訊息，也即實現防篡改。
• 伺服器MAC寫入祕鑰。伺服器使用這個祕鑰來計算將要傳送的訊息的摘要，客戶端使用該祕鑰來驗證伺服器發過來的訊息。
• 客戶端寫入祕鑰。客戶端使用這個祕鑰來加密將要傳送的應用程式資料，伺服器使用它來對收到的密文進行解密。
• 伺服器寫入祕鑰。伺服器使用這個祕鑰來加密將要傳送的應用程式資料，客戶端使用它來對收到的密文進行解密。

1. 客戶端傳送一個ClientHello訊息給伺服器，該訊息包含客戶端所能支援的SSL/TLS最高版本，以及一個支援的演算法組合列表，當然，還有客戶端生成的隨機數。
2. 伺服器給客戶端傳送一個ServerHello訊息，該訊息包含伺服器所選擇的SSL/TLS版本號以及演算法組合，同時還有伺服器產生的隨機數
3. 如果在步驟2中所選擇的演算法組合包含RSA，則伺服器向客戶端傳送它的數字證書，客戶端將會驗證伺服器的身份。
4. 伺服器向客戶端傳送ServerHelloDone訊息，表示伺服器完成協商階段的工作。
5. 客戶端產生一個隨機的Pre-Master Secret，然後想伺服器傳送一個ClientKeyExchange訊息，該訊息包含使用伺服器公鑰加密的Pre-Master Secret
6. 客戶端和伺服器各自使用Pre-Master Secret，步驟1中產生的客戶端隨機數，以及步驟2中產生的伺服器隨機數來計算一個Master Secret。有了Master Secret之後，客戶端和伺服器就可以使用Master Secret來計算後面所有需要用到的祕鑰。
7. 客戶端傳送一個ChangeCipherSpec通知給伺服器，表明客戶端將要開始使用剛才生成的祕鑰來加密和驗證資料。最後，客戶端傳送一個ClientFinish訊息。
8. 伺服器收到了客戶端的ChangeCipherSpec通知之後，也會對客戶端傳送ChangeCipherSpec通知，最後，伺服器傳送一個ClientFinish訊息。