咱們通常所說的 HTTPS 協議，就是指安全套接字層超文字傳輸協議HTTPS。就是“HTTP 協議”和“SSL/TLS 協議”的組合，你可以把 HTTPS 大致理解為——“HTTP over SSL”或“HTTP over TLS”。HTTP協議以明文方式傳送內容，不提供任何方式的資料加密，HTTPS在HTTP的基礎上加入了SSL協議，SSL依靠證書來驗證伺服器的身份，併為瀏覽器和伺服器之間的通訊加密。

加密分為“對稱加密”和“非對稱加密”兩種：

對稱加密：所謂的“對稱加密”，意思就是說：“加密”和“解密”使用相同的金鑰。

非對稱加密：：所謂的“非對稱加密”，意思就是說：“加密”和“解密”使用不同的金鑰。

單純用“對稱加密演算法”：

如果用對稱加密，瀏覽器和伺服器之間勢必先要交換“對稱加密的金鑰”，如果這個金鑰直接用明文傳輸，很容易就會被第三方（有可能是“攻擊者”）偷窺到；如果這個金鑰用密文傳輸，那就再次引入了“如何交換加密金鑰”的問題，這就造成了無限迴圈，所以，單純用對稱加密，是沒有作用的。

單純用“非對稱加密演算法”：

上面已經說了“非對稱加密”的特點——“加密和解密採用不同的金鑰”。基於這個特點，可以避開前面提到的“迴圈邏輯”的困境。大致的步驟如下：

第1步 
網站伺服器先基於“非對稱加密演算法”，隨機生成一個“金鑰對”（為敘述方便，稱之為“k1 和 k2”）。因為是隨機生成的，目前為止，只有網站伺服器才知道 k1 和 k2。

第2步 
網站把 k1 保留在自己手中，把 k2 用【明文】的方式傳送給訪問者的瀏覽器。 
因為 k2 是明文傳送的，自然有可能被偷窺。不過不要緊。即使偷窺者拿到 k2，也【很難】根據 k2 推算出 k1 
（這一點是由“非對稱加密演算法”從數學上保證的）。

第3步 
瀏覽器拿到 k2 之後，先【隨機生成】第三個對稱加密的金鑰（簡稱 k）。 
然後用 k2 加密 k，得到 k’（k’ 是 k 的加密結果） 
瀏覽器把 k’ 傳送給網站伺服器。

由於 k1 和 k2 是成對的，所以只有 k1 才能解密 k2 的加密結果。 
因此這個過程中，即使被第三方偷窺，第三方也【無法】從 k’ 解密得到 k

第4步 
網站伺服器拿到 k’ 之後，用 k1 進行解密，得到 k 
至此，瀏覽器和網站伺服器就完成了金鑰交換，雙方都知道 k，而且【貌似】第三方無法拿到 k 
然後，雙方就可以用 k 來進行資料雙向傳輸的加密。

然後上面的方案依然是不安全的——雖然可以在一定程度上防止網路資料的【偷窺/嗅探】，但是無法防範網路資料的【篡改】。

假設有一個攻擊者處於“瀏覽器”和“網站伺服器”的通訊線路之間，並且這個攻擊者具備“篡改雙方傳輸資料”的能力。那麼，這個攻擊者就可以攻破上述方案，具體的攻擊過程如下：

第1步 
這一步跟原先一樣——伺服器先隨機生成一個“非對稱的金鑰對”k1 和 k2（此時只有網站知道 k1 和 k2）

第2步 
當網站傳送 k2 給瀏覽器的時候，攻擊者截獲 k2，保留在自己手上。 
然後攻擊者自己生成一個【偽造的】金鑰對（以下稱為 pk1 和 pk2）。 
攻擊者把 pk2 傳送給瀏覽器。

第3步 
瀏覽器收到 pk2，以為 pk2 就是網站傳送的。 
瀏覽器不知情，依舊隨機生成一個對稱加密的金鑰 k，然後用 pk2 加密 k，得到密文的 k’ 
瀏覽器把 k’ 傳送給網站。 
（以下是關鍵） 
傳送的過程中，再次被攻擊者截獲。 
因為 pk1 pk2 都是攻擊者自己生成的，所以攻擊者自然就可以用 pk1 來解密 k’ 得到 k 
然後，攻擊者拿到 k 之後，用之前截獲的 k2 重新加密，得到 k”，並把 k” 傳送給網站。

第4步 
網站伺服器收到了 k” 之後，用自己儲存的 k1 可以正常解密，所以網站方面不會起疑心。 
至此，攻擊者完成了一次漂亮的偷樑換柱，而且讓雙方都沒有起疑心。

上述過程，也就是傳說中大名鼎鼎的“中間人攻擊”。洋文叫做“Man-In-The-Middle attack”。縮寫是 MITM。

因為“缺乏身份認證機制”，所以當攻擊者一開始截獲 k2 並把自己偽造的 pk2 傳送給瀏覽器時，瀏覽器無法鑑別：自己收到的金鑰是不是真的來自於網站伺服器，假如具備某種【可靠的】身份認證機制，即使攻擊者能夠篡改資料，但是篡改之後的資料很容易被識破。那篡改也就失去了意義。

基於CA證書的祕鑰交換

第1步（這是“一次性”的準備工作） 
網站方面首先要花一筆銀子，在某個 CA 那裡購買一個數字證書。 
該證書通常會對應幾個檔案：其中一個檔案包含公鑰，還有一個檔案包含私鑰。 
此處的“私鑰”，相當於“方案2”裡面的 k1；而“公鑰”類似於“方案2”裡面的 k2。 
網站方面必須在 Web 伺服器上部署這兩個檔案。

所謂的“公鑰”，顧名思義就是可以公開的 key；而所謂的“私鑰”就是私密的 key。 
其實前面已經說過了，這裡再嘮叨一下：

“非對稱加密演算法”從數學上確保了——即使你知道某個公鑰，也很難（不是不可能，是很難）根據此公鑰推匯出對應的私鑰。

第2步 
當瀏覽器訪問該網站，Web 伺服器首先把包含公鑰的證書傳送給瀏覽器。

第3步 
瀏覽器驗證網站發過來的證書。如果發現其中有詐，瀏覽器會提示“CA 證書安全警告”。 
由於有了這一步，就大大降低了（注意：是“大大降低”，而不是“徹底消除”）前面提到的“中間人攻擊”的風險。

為啥瀏覽器能發現 CA 證書是否有詐？ 
因為正經的 CA 證書，都是來自某個權威的 CA。如果某個 CA 足夠權威，那麼主流的作業系統（或瀏覽器）會內建該 CA 的“根證書”。（比如 Windows 中就內建了幾十個權威 CA 的根證書） 
因此，瀏覽器就可以利用系統內建的根證書，來判斷網站發過來的 CA 證書是不是某個 CA 頒發的。 

第4步 
如果網站發過來的 CA 證書沒有問題，那麼瀏覽器就從該 CA 證書中提取出“公鑰”。 
然後瀏覽器隨機生成一個“對稱加密的金鑰”（以下稱為 k）。用 CA 證書的公鑰加密 k，得到密文 k’ 
瀏覽器把 k’ 傳送給網站。

第5步 
網站收到瀏覽器發過來的 k’，用伺服器上的私鑰進行解密，得到 k。 
至此，瀏覽器和網站都擁有 k，“金鑰交換”大功告成啦。

這種方案從理論上講沒有明顯的漏洞，目前的 SSL/TLS 大致採用的就是這個方案。