作用

不使用 SSL/TLS 的 HTTP 通信，就是不加密的通信。所有信息明文傳播，帶來了三大風險。

• 竊聽風險（eavesdropping）：第三方可以獲知通信內容。
• 篡改風險（tampering）：第三方可以修改通信內容。
• 冒充風險（pretending）：第三方可以冒充他人身份參與通信。

SSL/TLS 協議是為了解決這三大風險而設計的，希望達到：

• 所有信息都是加密傳播，第三方無法竊聽。
• 具有校驗機制，一旦被篡改，通信雙方會立刻發現。
• 配備身份證書，防止身份被冒充。

基本的運行過程

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

但是，這里有兩個問題。

• 如何保證公鑰不被篡改
  解決方法：將公鑰放在數字證書中。只要證書是可信的，公鑰就是可信的。

• 公鑰加密計算量太大，如何減少耗用的時間
  解決方法：每一次對話（session），客戶端和服務器端都生成一個對話密鑰（session key），用它來加密信息。由于對話密鑰是對稱加密，所以運算速度非常快，而服務器公鑰只用于加密對話密鑰本身，這樣就減少了加密運算的消耗時間。

因此，SSL/TLS 協議的基本過程是這樣的：

• 客戶端向服務器端索要并驗證公鑰。
• 雙方協商生成"對話密鑰"。
• 雙方采用"對話密鑰"進行加密通信。

上面過程的前兩步，又稱為握手階段（handshake）。

握手階段的詳細過程

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

客戶端發出請求（ClientHello）

首先，客戶端（通常是瀏覽器）先向服務器發出加密通信的請求，這被叫做 ClientHello 請求。

在這一步，客戶端主要向服務器提供以下信息：

• 支持的協議版本，比如 TLS 1.0 版。
• 一個客戶端生成的隨機數，稍后用于生成"對話密鑰"。
• 支持的加密方法，比如 RSA 公鑰加密。
• 支持的壓縮方法。

這里需要注意的是，客戶端發送的信息之中不包括服務器的域名。也就是說，理論上服務器只能包含一個網站，否則會分不清應該向客戶端提供哪一個網站的數字證書。這就是為什么通常一臺服務器只能有一張數字證書的原因。

對于虛擬主機的用戶來說，這當然很不方便。2006年，TLS 協議加入了一個 Server Name Indication 擴展，允許客戶端向服務器提供它所請求的域名。

服務器回應（SeverHello）

服務器收到客戶端請求后，向客戶端發出回應，這叫做 SeverHello。服務器的回應包含以下內容。

• 確認使用的加密通信協議版本，比如 TLS 1.0 版本。如果瀏覽器與服務器支持的版本不一致，服務器關閉加密通信。
• 一個服務器生成的隨機數，稍后用于生成"對話密鑰"。
• 確認使用的加密方法，比如 RSA 公鑰加密。
• 服務器證書。

除了上面這些信息，如果服務器需要確認客戶端的身份，就會再包含一項請求，要求客戶端提供"客戶端證書"。比如，金融機構往往只允許認證客戶連入自己的網絡，就會向正式客戶提供 USB 密鑰，里面就包含了一張客戶端證書。

客戶端回應

客戶端收到服務器回應以后，首先驗證服務器證書。如果證書不是可信機構頒布、或者證書中的域名與實際域名不一致、或者證書已經過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通信。

如果證書沒有問題，客戶端就會從證書中取出服務器的公鑰。然后，向服務器發送下面三項信息。

• 一個隨機數。該隨機數用服務器公鑰加密，防止被竊聽。
• 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發送。
• 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供服務器校驗。

上面第一項的隨機數，是整個握手階段出現的第三個隨機數，又稱"pre-master key"。有了它以后，客戶端和服務器就同時有了三個隨機數，接著雙方就用事先商定的加密方法，各自生成本次會話所用的同一把"會話密鑰"。

為什么一定要用三個隨機數，來生成"會話密鑰"：

不管是客戶端還是服務器，都需要隨機數，這樣生成的密鑰才不會每次都一樣。由于 SSL 協議中證書是靜態的，因此十分有必要引入一種隨機因素來保證協商出來的密鑰的隨機性。

對于 RSA 密鑰交換算法來說，pre-master-key 本身就是一個隨機數，再加上 hello 消息中的隨機，三個隨機數通過一個密鑰導出器最終導出一個對稱密鑰。

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

同時需要注意前兩個隨機數都是明文傳輸的，竊聽者是可以輕易獲取到的，只有最后一個 pre master secret 是加密傳輸的，只有擁有服務器私鑰才能解密，一旦 pre master secret 泄露，那么本次通信就就完全可被破解了。

此外，如果前一步，服務器要求客戶端證書，客戶端會在這一步發送證書及相關信息。

服務器的最后回應

服務器收到客戶端的第三個隨機數 pre-master key 之后，計算生成本次會話所用的"會話密鑰"。然后，向客戶端最后發送下面信息：

• 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發送。
• 服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時也是前面發送的所有內容的 hash 值，用來供客戶端校驗。

至此，整個握手階段全部結束。接下來，客戶端與服務器進入加密通信，就完全是使用普通的 HTTP 協議，只不過用"會話密鑰"加密內容。

簡易過程

• 客戶端向服務端發送請求
• 服務端返回數字證書
• 客戶端用自己的CA（主流的CA機構證書一般都內置在各個主流瀏覽器中）公鑰去解密證書，如果證書有問題會提示風險
• 如果證書沒問題，客戶端會生成一個對稱加密的隨機秘鑰然后再和剛剛解密的服務器端的公鑰對數據進行加密，然后發送給服務器端
• 服務器端收到以后會用自己的私鑰對客戶端發來的對稱秘鑰進行解密

• 之后雙方就拿著這個對稱加密秘鑰來進行正常的通信

  
  

簽名

1. 對對稱加密的通俗理解：
   即通信的雙方都使用同一個秘鑰進行加解密

2. 對非對稱加密算法的通俗理解：

• 私鑰 + 公鑰 = 密鑰對
• 即用私鑰加密的數據，只有對應的公鑰才能解密，用公鑰加密的數據，只有對應的私鑰才能解密
• 其實這個很容易理解，因為通信雙方的手里都有一套自己的密鑰對，通信之前雙方會先把自己的公鑰都先發給對方。然后對方再拿著這個公鑰來加密數據響應給對方，等到到了對方那里，對方再用自己的私鑰進行解密，就這么簡單
• 公鑰和私鑰都可以進行加密和解密

3. 非對稱加密所造成的速度慢的問題解決辦法：

• 先生成一個對稱加密算法的密鑰，用 RSA 的方式先安全的發給對方
• 隨后就不再用 RSA 了，只用這個對稱加密的密鑰來互相通信

4. 不過，以上方式存在明顯的中間人問題：
   假設，此時在客戶端和服務器之間存在一個中間人，這個中間人只需要把原本雙方通信互發的公鑰，換成自己的公鑰,這樣中間人就可以輕松解密通信雙方所發送的所有數據

5. 為解決上述中間人問題,于是后來就出現了證書，簡單來講就是找了一個大家公認的中介，來證明我就是我，你就是你的問題，防止中間被篡改：
   證書中就包括個人的基本信息和最重要的公鑰

6. 乍一眼看去，上面的方案貌似還不錯，但證書在傳輸的過程中如果被篡改了呢，所以后來就又出現了數字簽名：

• 簡單來講，就是將公鑰和個人信息用一個 Hash 算法生成一個消息摘要
• 這個過程是不可逆的，也就是說無法通過 Hash 值得出原來的信息內容；并且只要輸入數據有一點點變化，那生成的消息摘要就會有巨變，能有效防止別人篡改數據
• 在把信息發送出去時，把這個 Hash 值（消息摘要）和信息一起發出去。 接收方在收到信息后，會重新計算信息的 Hash 值，并和信息所附帶的 Hash 值（解密后）進行對比，如果一致，就說明信息的內容沒有被修改過，因為這里 Hash 計算可以保證不同的內容一定會得到不同的 Hash 值，所以只要內容一被修改，根據信息內容計算的 Hash 值就會變化
• 但這還是有個問題，如果中間人修改信息內容的同時也修改 Hash 值（也就是消息摘要），從而讓它們可以相匹配？為了防止這種情況，Hash 值一般都會加密后（也就是簽名）再和信息一起發送，以保證這個 Hash 值不被修改。但是客戶端如何解密呢？這就涉及到數字證書了
• CA 用它的私鑰對消息摘要加密，形成簽名，并把原始信息和數據簽名進行合并，即所謂的數字證書
• 這樣，當別人把他的證書發過來的時候，我再用同樣的 Hash 算法，再次生成消息摘要
• 然后用 CA 的公鑰對數字簽名解密，得到 CA 創建的消息摘要，兩者一比，就知道中間有沒有被人篡改了