SSL (Secure Socket Layer)為Netscape所研發，用以保障在Internet上數據傳輸之安全，利用數據加密(Encryption)技術，可確保數據在網絡上之傳輸過程中不會被截取及竊聽。它已被廣泛地用於Web瀏覽器與服務器之間的身份認證和加密數據傳輸。安全傳輸層協議（TLS）用於在兩個通信應用程序之間提供保密性和數據完整性。該協議由兩層組成： TLS 記錄協議（TLS Record）和 TLS 握手協議（TLS Handshake）。
1、為什麼要使用協議
不使用SSL/TLS的HTTP通信，就是不加密的通信。會帶來以下風險。
竊聽風險（eavesdropping）：第三方可以獲知通信內容。
篡改風險（tampering）：第三方可以修改通信內容。
冒充風險（pretending）：第三方可以冒充他人身份參與通信。
SSL/TLS協議是為了解決這三大風險而設計的，能做到：
所有信息都是加密傳播，第三方無法竊聽。
具有校驗機制，一旦被篡改，通信雙方會立刻發現。
配備身份證書，防止身份被冒充。
互聯網是開放環境，通信雙方都是未知身份，這為協議的設計帶來了很大的難度。而且協議還必須能夠經受所有匪夷所思的攻擊，這使得SSL/TLS協議變得異常複雜。
2、協議的淵源
1999年，互聯網標準化組織ISOC接替NetScape公司，發佈了SSL的升級版TLS 1.0版。
2006年和2008年，TLS進行了兩次升級，分別為TLS 1.1版和TLS 1.2版。最新的變動是2011年TLS 1.2的修訂版。
3、協議是如何運行的
SSL/TLS協議的基本思路是採用公鑰加密法，也就是客戶端先向服務器端索要公鑰，然後用公鑰加密信息，服務器收到密文後，用自己的私鑰解密。在這過程中有兩個問題亟待解決。
a、如何保證公鑰不被篡改？
解決方法：將公鑰放在數字證書中。只要證書是可信的，公鑰就是可信的。
b、公鑰加密計算量太大，如何減少耗用的時間？
解決方法：每一次對話（session），客戶端和服務器端都生成一個”對話密鑰”（session key），用它來加密信息。由於”對話密鑰”是對稱加密，所以運算速度非常快，而服務器公鑰只用於加密”對話密鑰”本身，這樣就減少了加密運算的消耗時間。
總結一下SSL/TLS協議的基本過程是這樣的：
客戶端向服務器端索要並驗證公鑰。
雙方協商生成”對話密鑰”。
雙方採用”對話密鑰”進行加密通信。
過程的前兩步，又稱為”握手階段”（handshake）。
4、協議握手階段（handshake）的詳細過程
“握手階段”涉及四次通信。需要注意的是，”握手階段”的所有通信都是明文的。
4.1、客戶端發出請求（ClientHello）
客戶端（通常是瀏覽器）先向服務器發出加密通信的請求，這被叫做ClientHello請求。
客戶端主要向服務器提供以下信息。
a、支持的協議版本，比如TLS 1.0版。
b、一個客戶端生成的隨機數，稍後用於生成”對話密鑰”。
c、支持的加密方法，比如RSA公鑰加密。
d、支持的壓縮方法。
客戶端發送的信息之中不包括服務器的域名。也就是說，理論上服務器只能包含一個網站，否則會分不清應該向客戶端提供哪一個網站的數字證書。這就是為什麼通常一臺服務器只能有一張數字證書的原因。對於虛擬主機的用戶來說，這當然很不方便。2006年，TLS協議加入了一個Server Name Indication擴展，允許客戶端向服務器提供它所請求的域名。
4.2、服務器回應（SeverHello）
服務器收到客戶端請求後，向客戶端發出回應，這叫做SeverHello。服務器的回應包含以下內容。
a、確認使用的加密通信協議版本，比如TLS 1.0版本。如果瀏覽器與服務器支持的版本不一致，服務器關閉加密通信。
b、一個服務器生成的隨機數，稍後用於生成”對話密鑰”。
c、確認使用的加密方法，比如RSA公鑰加密。
d、服務器證書。
除了上面這些信息，如果服務器需要確認客戶端的身份，就會再包含一項請求，要求客戶端提供”客戶端證書”。如金融機構往往只允許認證客戶連入自己的網絡，會向客戶提供USB密鑰，裡面就包含了一張客戶端證書。
4.3、客戶端回應
客戶端收到服務器回應以後，首先驗證服務器證書。如果證書不是可信機構頒佈、或者證書中的域名與實際域名不一致、或者證書已經過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通信。如果證書沒有問題，客戶端就會從證書中取出服務器的公鑰。然後向服務器發送下面三項信息。
a、 一個隨機數。該隨機數用服務器公鑰加密，防止被竊聽。
b、編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送。
c、客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供服務器校驗。
上面第一項的隨機數，是整個握手階段出現的第三個隨機數，又稱”pre-master key”。有了它以後，客戶端和服務器就同時有了三個隨機數，接著雙方就用事先商定的加密方法，各自生成本次會話所用的同一把”會話密鑰”。
至於為什麼一定要用三個隨機數，來生成”會話密鑰”，解釋如下：
“不管是客戶端還是服務器，都需要隨機數，這樣生成的密鑰才不會每次都一樣。由於SSL協議中證書是靜態的，因此十分有必要引入一種隨機因素來保證協商出來的密鑰的隨機性。
對於RSA密鑰交換算法來說，pre-master-key本身就是一個隨機數，再加上hello消息中的隨機，三個隨機數通過一個密鑰導出器最終導出一個對稱密鑰。
pre master的存在在於SSL協議不信任每個主機都能產生完全隨機的隨機數，如果隨機數不隨機，那麼pre master secret就有可能被猜出來，那麼僅適用pre master secret作為密鑰就不合適了，因此必須引入新的隨機因素，那麼客戶端和服務器加上pre master secret三個隨機數一同生成的密鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的可不是一。”
4.4、服務器的最後回答
服務器收到客戶端的第三個隨機數pre-master key之後，計算生成本次會話所用的”會話密鑰”。然後向客戶端最後發送下面信息。
a、編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送。
b、服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供客戶端校驗。
到這為止，整個握手階段全部結束。然後客戶端與服務器使用普通的HTTP協議進行加密通信，只不過用”會話密鑰”加密內容。
閱讀更多 石頭大V 的文章
