漫畫：什麼是 HTTPS 協議？

什麼是 HTTP 協議？

HTTP 協議全稱 Hyper Text Transfer Protocol，翻譯過來就是超文本傳輸協議，位於 TCP/IP 四層模型當中的應用層。

HTTP 協議通過請求 / 響應的方式，在客戶端和服務端之間進行通信。

這一切看起來很美好，但是 HTTP 協議有一個致命的缺點：不夠安全。

HTTP 協議的信息傳輸完全以明文方式，不做任何加密，相當於是在網絡上 “裸奔”。這樣會導致什麼問題呢？讓我們打一個比方：

小灰是客戶端，小灰的同事小紅是服務端，有一天小灰試圖給小紅髮送請求。

但是，由於傳輸信息是明文，這個信息有可能被某個中間人惡意截獲甚至篡改。這種行爲叫做中間人攻擊。

如何進行加密呢？

小灰和小紅可以事先約定一種對稱加密方式，並且約定一個隨機生成的密鑰。後續的通信中，信息發送方都使用密鑰對信息加密，而信息接收方通過同樣的密鑰對信息解密。

這樣做是不是就絕對安全了呢？並不是。

雖然我們在後續的通信中對明文進行了加密，但是第一次約定加密方式和密鑰的通信仍然是明文，如果第一次通信就已經被攔截了，那麼密鑰就會泄露給中間人，中間人仍然可以解密後續所有的通信內容。

這可怎麼辦呢？別擔心，我們可以使用非對稱加密，爲密鑰的傳輸做一層額外的保護。

非對稱加密的一組祕鑰對中，包含一個公鑰和一個私鑰。明文既可以用公鑰加密，用私鑰解密；也可以用私鑰加密，用公鑰解密。

在小灰和小紅建立通信的時候，小紅首先把自己的公鑰 Key1 發給小灰：

收到小紅的公鑰以後，小灰自己生成一個用於對稱加密的密鑰 Key2，並且用剛纔接收的公鑰 Key1 對 Key2 進行加密（這裏有點繞），發送給小紅：

小紅利用自己非對稱加密的私鑰，解開了公鑰 Key1 的加密，獲得了 Key2 的內容。從此以後，兩人就可以利用 Key2 進行對稱加密的通信了。

在通信過程中，即使中間人在一開始就截獲了公鑰 Key1，由於不知道私鑰是什麼，也無從解密。

是什麼壞主意呢？中間人雖然不知道小紅的私鑰是什麼，但是在截獲了小紅的公鑰 Key1 之後，卻可以偷天換日，自己另外生成一對公鑰私鑰，把自己的公鑰 Key3 發送給小灰。

小灰不知道公鑰被偷偷換過，以爲 Key3 就是小紅的公鑰。於是按照先前的流程，用 Key3 加密了自己生成的對稱加密密鑰 Key2，發送給小紅。

這一次通信再次被中間人截獲，中間人先用自己的私鑰解開了 Key3 的加密，獲得 Key2，然後再用當初小紅髮來的 Key1 重新加密，再發給小紅。

這樣一來，兩個人後續的通信儘管用 Key2 做了對稱加密，但是中間人已經掌握了 Key2，所以可以輕鬆進行解密。

是什麼解決方案呢？難道再把公鑰進行一次加密嗎？這樣只會陷入雞生蛋蛋生雞，永無止境的困局。

這時候，我們有必要引入第三方，一個權威的證書頒發機構（CA）來解決。

到底什麼是證書呢？證書包含如下信息：

爲了便於說明，我們這裏做了簡化，只列出了一些關鍵信息。至於這些證書信息的用處，我們看看具體的通信流程就能夠弄明白了。

流程如下：

證書頒發機構自己也有一對公鑰私鑰。機構利用自己的私鑰來加密 Key1，並且通過服務端網址等信息生成一個證書籤名，證書籤名同樣經過機構的私鑰加密。證書製作完成後，機構把證書發送給了服務端小紅。

小灰收到證書以後，要做的第一件事情是驗證證書的真僞。需要說明的是，各大瀏覽器和操作系統已經維護了所有權威證書機構的名稱和公鑰。所以小灰只需要知道是哪個機構頒佈的證書，就可以從本地找到對應的機構公鑰，解密出證書籤名。

接下來，小灰按照同樣的簽名規則，自己也生成一個證書籤名，如果兩個簽名一致，說明證書是有效的。

驗證成功後，小灰就可以放心地再次利用機構公鑰，解密出服務端小紅的公鑰 Key1。

在這樣的流程下，我們不妨想一想，中間人是否還具有使壞的空間呢？

注：最新推出的 TLS 協議，是 SSL 3.0 協議的升級版，和 SSL 協議的大體原理是相同的。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/O0MAe2jWhT8oWWYHKTM4lg