HTTPS(SSL/TLS) 原理之深刻淺出

注：本文參考自網絡上的多篇HTTPS相關文章，本人根據本身的理解，進行一些修改，綜合。

1. 必要的加密解密基礎知識

1）對稱加密算法：就是加密和解密使用同一個密鑰的加密算法。由於加密方和解密方使用的密鑰相同，因此稱爲稱爲對稱加密，也稱爲單鑰加密方法。

    優勢是：加密和解密運算速度快，因此對稱加密算法一般在消息發送方須要加密大量數據時使用；

    缺點是：安全性差，若是一方的密鑰遭泄露，那麼整個通訊就會被破解。另外加密以前雙方須要同步密鑰;

    經常使用對稱加密算法有：DES、3DES、TDEA、Blowfish、RC二、RC四、RC五、IDEA、SKIPJACK、AES等;

2）非對稱加密算法：而非對稱加密算法須要兩個密鑰來進行加密和解密，這兩個祕鑰是公開密鑰(public key，簡稱公鑰)和私有密鑰(private key，簡稱私鑰)。

    公鑰和私鑰是一對：公鑰用來加密，私鑰解密，並且公鑰是公開的，私鑰是本身保存的，不須要像對稱加密那樣在通訊以前要先同步祕鑰。

    有點是：安全性更好，私鑰是本身保存的，不須要像對稱加密那樣在通訊以前要先同步祕鑰。

    缺點是：加密和解密花費時間長、速度慢，只適合對少許數據進行加密。

    經常使用的非對稱加密算法有：RSA、Elgamal、Rabin、D-H、ECC等；

3）HASH算法：也稱爲消息摘要算法。將任意長度的二進制值映射爲較短的固定長度的二進制值，該二進制值稱爲哈希值。

    經常使用於檢驗數據的完整性，檢驗數據沒有被篡改過。常見的又 MD5(MD系列)，SHA-1(SHA系列)

HTTPS 使用到了上面所有三種加密算法。

2. HTTPS 的做用

HTTPS簡單而言，即便創建在SSL/TLS協議之上的HTTP。不使用SSL/TLS的HTTP通訊，就是不加密的通訊。全部信息明文傳播，帶來了三大風險。

（1） 竊聽風險（eavesdropping）：第三方能夠獲知通訊內容。

（2） 篡改風險（tampering）：第三方能夠修改通訊內容。

（3） 冒充風險（pretending）：第三方能夠冒充他人身份參與通訊。

SSL/TLS協議是爲了解決這三大風險而設計的，但願達到：

（1） 全部信息都是加密傳播，第三方沒法竊聽。

（2） 具備校驗機制，一旦被篡改，通訊雙方會馬上發現。

（3） 配備身份證書，防止身份被冒充。

互聯網是開放環境，通訊雙方都是未知身份，這爲協議的設計帶來了很大的難度。並且，協議還必須可以經受全部匪夷所思的攻擊，這使得SSL/TLS協議變得異常複雜。

3. HTTPS 的歷史

互聯網加密通訊協議的歷史，幾乎與互聯網同樣長。

1994年，NetScape公司設計了SSL協議（Secure Sockets Layer）的1.0版，可是未發佈。

1995年，NetScape公司發佈SSL 2.0版，很快發現有嚴重漏洞。

1996年，SSL 3.0版問世，獲得大規模應用。

1999年，互聯網標準化組織ISOC接替NetScape公司，發佈了SSL的升級版TLS 1.0版。

2006年和2008年，TLS進行了兩次升級，分別爲TLS 1.1版和TLS 1.2版。最新的變更是2011年TLS 1.2的修訂版。

目前，應用最普遍的是TLS 1.0，接下來是SSL 3.0。可是，主流瀏覽器都已經實現了TLS 1.2的支持。

TLS 1.0一般被標示爲SSL 3.1，TLS 1.1爲SSL 3.2，TLS 1.2爲SSL 3.3。

4. 基本的運行過程

HTTPS 的基本運行過程：

1）利用對稱加密算法來加密網頁內容，那麼如何保證對稱加密算法的祕鑰的安全呢？

2）使用非對稱加密算法來得到對稱加密算法的祕鑰，從而保證了對稱加密算法的祕鑰的安全，也就保證了對稱加密算法的安全。

這裏這樣安排使用的原理是，利用了對稱加密算法和非對稱加密算法優勢，而避免了它們的缺點。利用了對稱加密算法速度快，而非對稱加密算法安全的優勢；同時巧妙的避免了對稱加密算法的不安全性，以及須要同步密鑰的缺點，也避免了非對稱加密算法的速度慢的缺點。實在是巧妙了。

這裏有兩個問題：

（1）如何保證非對稱加密算法公鑰不被篡改？

解決方法：將公鑰放在數字證書中。只要證書是可信的，公鑰就是可信的。

（2）公鑰加密計算量太大，如何減小耗用的時間？

解決方法：每一次對話（session），客戶端和服務器端都生成一個"對話密鑰"（session key），用它來加密信息。因爲"對話密鑰"是對稱加密算法，因此運算速度很是快，而服務器公鑰只用於加密"對話密鑰"自己，這樣就減小了加密運算的消耗時間。（也就是網頁內容的加密使用的是對稱加密算法）

所以，SSL/TLS協議的基本過程是這樣的：

（1） 客戶端向服務器端索要並驗證非對稱加密算法的公鑰。

（2） 雙方協商生成對稱加密算法的"對話密鑰"。

（3） 雙方採用對稱加密算法和它的"對話密鑰"進行加密通訊。

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

5. 握手階段的詳細過程

"握手階段"涉及四次通訊，咱們一個個來看。須要注意的是，"握手階段"的全部通訊都是明文的。

1) 客戶端發出請求（ClientHello）

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

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

（1） 瀏覽器支持的SSL/TLS協議版本，好比TLS 1.0版。

（2） 一個瀏覽器客戶端生成的隨機數，稍後用於生成對稱加密算法的"對話密鑰"。

（3） 瀏覽器支持的各類加密方法，對稱的，非對稱的，HASH算法。好比RSA非對稱加密算法，DES對稱加密算法，SHA-1 hash算法。

（4） 瀏覽器支持的壓縮方法。

這裏須要注意的是，客戶端發送的信息之中不包括服務器的域名。也就是說，理論上服務器只能包含一個網站，不然會分不清應該向客戶端提供哪個網站的數字證書。這就是爲何一般一臺服務器只能有一張數字證書的緣由。

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

2) 服務器迴應（SeverHello）

服務器收到客戶端請求後，向客戶端發出迴應，這叫作SeverHello。服務器的迴應包含如下內容。

（1） 確認使用的加密通訊協議版本，好比TLS 1.0版本。若是瀏覽器與服務器支持的版本不一致，服務器關閉加密通訊。

（2） 一個服務器生成的隨機數，稍後用於生成對稱加密算法的"對話密鑰"。

（3） 確認使用的各類加密方法，好比確認算法使用：RSA非對稱加密算法，DES對稱加密算法，SHA-1 hash算法

（4） 服務器證書。

除了上面這些信息，若是服務器須要確認客戶端的身份，就會再包含一項請求，要求客戶端提供"客戶端證書"。好比，金融機構每每只容許認證客戶連入本身的網絡，就會向正式客戶提供USB密鑰，裏面就包含了一張客戶端證書。

3） 客戶端迴應

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

若是證書沒有問題，客戶端就會從證書中取出服務器的非對稱加密算法的公鑰。而後，向服務器發送下面三項信息。

（1） 一個隨機數。該隨機數用服務器發來的公鑰進行的使用非對稱加密算法加密，防止被竊聽。

（2） 編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送(好比確認使用：RSA非對稱，DES對稱，SHA-1 hash算法)。

（3） 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面發送的全部內容的hash值，用來供服務器校驗。

上面第一項的隨機數，是整個握手階段出現的第三個隨機數，又稱"pre-master key"。有了它之後，客戶端和服務器就同時有了三個隨機數，接着雙方就用事先商定的對稱加密算法，各自生成本次會話所用的同一把"會話密鑰"。也就是說瀏覽器和服務器各自使用同一個對稱加密算法，對三個相同的隨機數進行加密，得到了，用來加密網頁內容的 對稱加密算法的祕鑰。(注意：這裏瀏覽器的三個隨機數都是明文的，可是服務端得到的"pre-master key"是密文的，因此服務器須要使用非對稱加密算法的私鑰，來先解密得到"pre-master key"的明文，在來生成對稱加密算法的祕鑰。這樣的目的是爲了防止："pre-master key"被竊聽，由於發送明文會被竊聽，可是發生的是非對稱加密算法的加密事後的密文，由於竊聽者不知道私鑰，因此即便竊聽了，也沒法解密出其對應的明文。從而保證了最後生成的：用於加密網頁內容的對稱加密算法的祕鑰的安全性！！！)

至於爲何必定要用三個隨機數，來生成"會話密鑰"，dog250解釋得很好：

"不論是客戶端仍是服務器，都須要隨機數，這樣生成的密鑰纔不會每次都同樣。因爲SSL協議中證書是靜態的，所以十分有必要引入一種隨機因素來保證協商出來的密鑰的隨機性。

對於RSA密鑰交換算法來講，pre-master-key自己就是一個隨機數，再加上hello消息中的隨機，三個隨機數經過一個密鑰導出器最終導出一個對稱密鑰。

pre master的存在在於SSL協議不信任每一個主機都能產生徹底隨機的隨機數，若是隨機數不隨機，那麼pre master secret就有可能被猜出來，那麼僅適用pre master secret做爲密鑰就不合適了，所以必須引入新的隨機因素，那麼客戶端和服務器加上pre master secret三個隨機數一同生成的密鑰就不容易被猜出了，一個僞隨機可能徹底不隨機，但是是三個僞隨機就十分接近隨機了，每增長一個自由度，隨機性增長的 可不是一。"

這裏：其實若是 pre-master-key 和 瀏覽器生成的隨機數均可能被猜出來，那麼最後生成的對稱加密算法的祕鑰就是不安全的。由於三個隨機數均可能被竊聽到了。

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

4) 服務器的最後迴應

服務器收到客戶端的第三個隨機數pre-master key以後，計算生成本次會話所用的對稱加密算法的"會話密鑰"。而後，向客戶端最後發送下面信息。

（1）編碼改變通知，表示隨後的信息都將用雙方商定的對稱加密算法和密鑰進行加密。

（2）服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時也是前面發送的全部內容的hash值，用來供客戶端校驗。

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

參考連接

• MicroSoft TechNet, SSL/TLS in Detail
• Jeff Moser, The First Few Milliseconds of an HTTPS Connection
• Wikipedia, Transport Layer Security
• StackExchange, How does SSL work?

（完）

=======================================

注：

本文主要修改自：SSL/TLS協議運行機制的概述

僅僅按照本身的理解，進行了一些修改，和補充，以利於本身理解。可能會存在本身理解上的錯誤。

另外參考了：HTTPS那些事（一）HTTPS原理

本文若是結合 HTTPS鏈接的前幾毫秒發生了什麼 一塊兒來理解HTTPS，將理解的更加深刻。

 

總結：

1）HTTPS 結合使用了 非對稱加密算法，對稱加密算法，hash算法，分別利用他們的優點，避免他們的缺點。利用非對稱加密算法得到對稱加密算法的祕鑰，保證他的安全性；而後實際的網頁內容的加密使用的是對稱加密算法，利用了對稱加密算法速度快的優點，hash算法主要是防止篡改的發生，是一種校驗機制，最後數字證書，保證了服務器在將非對稱加密算法的公鑰傳給瀏覽器時的安全性(不會被中間人篡改)，同時也標誌了服務器的身份。

2）HTTPS的四大金剛：

    非對稱加密算法(對稱加密算法的祕鑰) + 對稱加密算法(加密內容) + 數字證書(防止篡改非對稱加密算法的公鑰) + HASH算法(防止篡改消息)== HTTPS

3）HTTPS的本質是什麼？

     HTTPS的本質就是在HTTP鏈接發起以前，先使用SSL/TLS協議，協調客戶端和服務端，在兩端各自生產一個對稱加密算法的祕鑰，

     而後使用普通的HTTP協議傳輸 通過對稱加密算法加密的網頁內容。由於對稱加密算法的祕鑰是安全的，因此對稱加密算法加密的網頁內容也是安全的。