如何理解HTTPS？可以收藏這一篇，足以應付面試！

摘自接水怪 ，作者怪怪

整個 HTTPS 的演變跟流程細思極恐，有很多思想可以借鑑學習。我以後要離搞安全的朋友遠一點。

這篇將帶你深入 HTTPS 加解密原理，希望看完能夠有這些收穫：

· 明白 HTTPS 到底解決了什麼問題

· 理解對稱加密與非對稱加密的原理和使用場景

· 明白 CA 機構和根證書到底起了什麼作用

Why HTTPS

近幾年來，各大公司都在大力推進 HTTPS 的建設：

· Google Chrome 將非 HTTPS 的網站標註為不安全。

· 蘋果要求 APP 中需要使用 HTTPS 進行通信。

· 微信小程序也要求使用 HTTPS 協議。

那麼，我們為什麼非要做這麼一件事呢？我們先來看看 HTTP。

HTTP（Hypertext Transfer Protocol）超文本傳輸協議，是一種用於分佈式、協作式和超媒體信息系統的應用層協議，可以說 HTTP 是當代互聯網通信的基礎。

但是，HTTP 有著一個致命的缺陷，那就是內容是明文傳輸的，沒有經過任何加密。

而這些明文數據會經過 WiFi、路由器、運營商、機房等多個物理設備節點，如果在這中間任意一個節點被監聽，傳輸的內容就會完全暴露。

這一攻擊手法叫做 MITM（Man In The Middle）中間人攻擊。

舉個例子，稍微有點長，但這個例子透露出了怪怪我對安全如此痴迷的原因。

可以拿小時候上課傳紙條來類比，你坐在教室靠牆的一邊，想要傳一句「晚上放學操場我等你」給坐在窗邊的小紅，中間要經過六七個人的傳遞。

雖然你把紙條對摺了一下，但是防君子不防小人，中間的所有人都可以很輕易地打開紙條看到你想要說什麼。

只是看還好，如果有小剛也喜歡小紅，看到你倆馬上就要甜甜蜜蜜地回家了，心有不甘，換了一張紙條，改成了「晚上放學你自己回家吧，我要去網吧玩遊戲」。

小紅看到你要拋棄她自己去玩遊戲，非常傷心，開始在紙條上質問「說好的一起回家呢，為什麼要去打遊戲，哼」。

在小紅的紙條傳回來的路上，小剛又改了紙條「你玩你的遊戲去吧，我要和小剛回家」。

於是，你和小紅都倍感傷心，小剛橫刀奪愛，而你一頭霧水。

回憶一下幾年前遍地都是的運營商劫持，當你訪問一個本來很正常的網頁，但頁面上卻莫名其妙出現了一些廣告標籤、跳轉腳本、欺騙性的紅包按鈕。

甚至有時候本來要下載一個文件，最後下下來卻變成了另外一個完全不同的東西，這些都是被運營商劫持了 HTTP 明文數據的現象。

運營商劫持

還有各大公司的員工安全培訓裡都有一條「不要連陌生的 WiFi」，也是類似的原因，惡意 WiFi 的控制者可以看到和篡改 HTTP 明文傳輸的信息。

為了解決 HTTP 明文傳輸數據可能導致的安全問題，1994 年網景公司提出了 HTTPS（HyperText Transfer Protocol Secure）超文本傳輸安全協議，數據通信仍然是 HTTP，但利用 SSL/TLS 加密數據包。

HTTPS 實現原理

前面說到，HTTPS 其實就是將 HTTP 的數據包再通過 SSL/TLS 加密後傳輸，那麼 SSL/TLS 又是什麼呢？

SSL（Secure Sockets Layer）安全套接層和 TLS（Transport Layer Security）傳輸層安全協議其實是一套東西。

網景公司在 1994 年提出 HTTPS 協議時，使用的是 SSL 進行加密。

後來 IETF（Internet Engineering Task Force）互聯網工程任務組將 SSL 進一步標準化，於 1999 年公佈第一版 TLS 協議文件 TLS 1.0。目前最新版的 TLS 協議是 TLS 1.3，於 2018 年公佈。

工作流程

我們先來看看 HTTPS 的加解密流程，如下圖：

HTTPS 加解密流程如下：

· 用戶在瀏覽器發起 HTTPS 請求（如 https://www.mogu.com/），默認使用服務端的 443 端口進行連接。

· HTTPS 需要使用一套 CA 數字證書，證書內會附帶一個公鑰 Pub，而與之對應的私鑰 Private 保留在服務端不公開。

· 服務端收到請求，返回配置好的包含公鑰 Pub 的證書給客戶端。

· 客戶端收到證書，校驗合法性，主要包括是否在有效期內、證書的域名與請求的域名是否匹配，上一級證書是否有效（遞歸判斷，直到判斷到系統內置或瀏覽器配置好的根證書），如果不通過，則顯示 HTTPS 警告信息，如果通過則繼續。

· 客戶端生成一個用於對稱加密的隨機 Key，並用證書內的公鑰 Pub 進行加密，發送給服務端。

· 服務端收到隨機 Key 的密文，使用與公鑰 Pub 配對的私鑰 Private 進行解密，得到客戶端真正想發送的隨機 Key。

· 服務端使用客戶端發送過來的隨機 Key 對要傳輸的 HTTP 數據進行對稱加密，將密文返回客戶端。

· 客戶端使用隨機 Key 對稱解密密文，得到 HTTP 數據明文。

· 後續 HTTPS 請求使用之前交換好的隨機 Key 進行對稱加解密。

對稱加密與非對稱加密

又是對稱加密又是非對稱加密，一會公鑰一會私鑰一會隨機 Key，為什麼要這麼複雜呢，一套搞到底不好麼？

對稱加密是指有一個密鑰，用它可以對一段明文加密，加密之後也只能用這個密鑰來解密得到明文。

如果通信雙方都持有密鑰，且天知地知你知我知，絕對不會有別的人知道，那麼通信安全自然是可以得到保證的（在密鑰足夠強的情況下）。

然而，在 HTTPS 的傳輸場景下，服務端事先並不知道客戶端是誰，你也不可能在事先不通過互聯網和每一個網站的管理員都悄悄商量好一個通信密鑰出來。

那麼必然存在一個密鑰在互聯網上傳輸的過程，如果在傳輸過程中被別人監聽到了，那麼後續的所有加密都是無用功。

這時，我們就需要另一種神奇的加密類型，非對稱加密。

非對稱加密有兩個密鑰，一個是公鑰，另一個是私鑰。一般來說，公鑰用來加密，這時密文只能用私鑰才能解開。

那麼，當客戶端發起連接請求，服務端將公鑰傳輸過去，客戶端利用公鑰加密好信息，再將密文發送給服務端，服務端裡有私鑰可以解密。

但是，當服務端要返回數據，如果用公鑰加密，那麼客戶端並沒有私鑰用來解密，而如果用私鑰加密，客戶端雖然有公鑰可以解密。但這個公鑰之前就在互聯網上傳輸過，很有可能已經有人拿到，並不安全，所以這一過程只用非對稱加密是不能滿足的。注意，嚴格來講，私鑰並不能用來加密，只能用作簽名使用，這是由於密碼學中生成公鑰私鑰時對不同變量的數學要求是不同的。

因此公鑰私鑰抵抗攻擊的能力也不同，在實際使用中不可互換。簽名的功能在 HTTPS 裡也有用到，下文中會說明。

只有一組公鑰私鑰只能保證單程的加解密，那麼如果我們準備兩組公鑰私鑰呢，是不是可以解決這個問題？

來看下面這個過程：

· 服務端有非對稱加密的公鑰 A1，私鑰 A2。

· 客戶端有非對稱加密的公鑰 B1，私鑰 B2。

· 客戶端向服務端發起請求，服務端將公鑰 A1 返回給客戶端。

· 瀏覽器收到公鑰 A1，將自己保存的公鑰 B1 發送給服務端。

· 之後瀏覽器所有向客戶端發送的數據，使用公鑰 B1 加密，客戶端可以使用私鑰 B2 解密。

· 客戶端所有向服務端發送的數據，使用公鑰 A1 加密，服務端可以使用私鑰 A2 解密。

此時，兩條傳輸方向的數據都經過非對稱加密，都能保證安全性，那麼為什麼不採用這種方案呢？

最主要的原因是非對稱加解密耗時要遠大於對稱加解密，對性能有很大損耗，大家的使用體驗很差。

所以，我們才最終選用了上文介紹到非對稱加密+對稱加密的方案，再複習一下：

· 服務端有非對稱加密的公鑰 A1，私鑰 A2。

· 客戶端發起請求，服務端將公鑰 A1 返回給客戶端。

· 客戶端隨機生成一個對稱加密的密鑰 K，用公鑰 A1 加密後發送給服務端。

· 服務端收到密文後用自己的私鑰 A2 解密，得到對稱密鑰 K，此時完成了安全的對稱密鑰交換，解決了對稱加密時密鑰傳輸被人竊取的問題。

· 之後雙方通信都使用密鑰 K 進行對稱加解密。

看起來是一個非常完美的方案，兼顧了安全性和性能，但是，真的就安全了麼？

CA 頒發機構

依然考慮中間人攻擊的情況，非對稱加密的算法都是公開的，所有人都可以自己生成一對公鑰私鑰。

當服務端向客戶端返回公鑰 A1 的時候，中間人將其替換成自己的公鑰 B1 傳送給瀏覽器。

而瀏覽器此時一無所知，傻乎乎地使用公鑰 B1 加密了密鑰 K 發送出去，又被中間人截獲。

中間人利用自己的私鑰 B2 解密，得到密鑰 K，再使用服務端的公鑰 A1 加密傳送給服務端，完成了通信鏈路，而服務端和客戶端毫無感知。

HTTPS 中間人

出現這一問題的核心原因是客戶端無法確認收到的公鑰是不是真的是服務端發來的。為了解決這個問題，互聯網引入了一個公信機構，這就是 CA。

服務端在使用 HTTPS 前，去經過認證的 CA 機構申請頒發一份數字證書，數字證書裡包含有證書持有者、證書有效期、公鑰等信息。

服務端將證書發送給客戶端，客戶端校驗證書身份和要訪問的網站身份確實一致後再進行後續的加密操作。

但是，如果中間人也聰明一點，只改動了證書中的公鑰部分，客戶端依然不能確認證書是否被篡改，這時我們就需要一些防偽技術了。

前面說過，非對稱加密中一般公鑰用來加密，私鑰用來解密，雖然私鑰加密理論上可行，但由於數學上的設計這麼做並不適合，那麼私鑰就只有解密這個功能了麼？

私鑰除了解密外的真正用途其實還有一個，就是數字簽名，其實就是一種防偽技術，只要有人篡改了證書，那麼數字簽名必然校驗失敗。

具體過程如下：

· CA 機構擁有自己的一對公鑰和私鑰。

· CA 機構在頒發證書時對證書明文信息進行哈希。

· 將哈希值用私鑰進行加簽，得到數字簽名。

明文數據和數字簽名組成證書，傳遞給客戶端：

· 客戶端得到證書，分解成明文部分 Text 和數字簽名 Sig1。

· 用 CA 機構的公鑰進行解籤，得到 Sig2（由於 CA 機構是一種公信身份，因此在系統或瀏覽器中會內置 CA 機構的證書和公鑰信息）。

· 用證書裡聲明的哈希算法對明文 Text 部分進行哈希得到 H。

· 當自己計算得到的哈希值 T 與解籤後的 Sig2 相等，表示證書可信，沒有被篡改。

這時，簽名是由 CA 機構的私鑰生成的，中間人篡改信息後無法拿到 CA 機構的私鑰，保證了證書可信。

注意，這裡有一個比較難以理解的地方，非對稱加密的簽名過程是，私鑰將一段消息進行加簽，然後將簽名部分和消息本身一起發送給對方。

收到消息後對簽名部分利用公鑰驗籤，如果驗簽出來的內容和消息本身一致，表明消息沒有被篡改。

在這個過程中，系統或瀏覽器中內置的 CA 機構的證書和公鑰成為了至關重要的環節，這也是 CA 機構公信身份的證明，如果系統或瀏覽器中沒有這個 CA 機構，那麼客戶端可以不接受服務端傳回的證書，顯示 HTTPS 警告。

實際上 CA 機構的證書是一條信任鏈，A 信任 B，B 信任 C，以掘金的證書為例，掘金向 RapidSSL 申請一張證書，而 RapidSSL 的 CA 身份是由 DigiCert Global 根 CA 認證的，構成了一條信任鏈。

各級 CA 機構的私鑰是絕對的私密信息，一旦 CA 機構的私鑰洩露，其公信力就會一敗塗地。

之前就有過幾次 CA 機構私鑰洩露，引發信任危機，各大系統和瀏覽器只能紛紛吊銷內置的對應 CA 的根證書。

有些老舊的網站會要求使用前下載安裝他自己的根證書，這就是這個網站使用的證書並不能在系統內置的 CA 機構和根證書之間形成一條信任鏈，需要自己安裝根證書來構成信任鏈，這裡的風險就要使用者自己承擔了。

證書明細

總結

HTTPS 的出發點是解決 HTTP 明文傳輸時信息被篡改和監聽的問題：

· 為了兼顧性能和安全性，使用了非對稱加密+對稱加密的方案。

· 為了保證公鑰傳輸中不被篡改，又使用了非對稱加密的數字簽名功能，藉助 CA 機構和系統根證書的機制保證了 HTTPS 證書的公信力。