整個 HTTPS 的演變跟流程細思極恐，有很多思想可以借鑒學習。我以后要離搞安全的朋友遠一點。
這篇將帶你深入 HTTPS 加解密原理，希望看完能夠有這些收獲：
· 明白 HTTPS 到底解決了什么問題
· 理解對稱加密與非對稱加密的原理和使用場景
· 明白 CA 機構和根證書到底起了什么作用
Why HTTPS
近幾年來，各大公司都在大力推進 HTTPS 的建設：
· google Chrome 將非 HTTPS 的網(wǎng)站標注為不安全。
· 蘋果要求 App 中需要使用 HTTPS 進行通信。
· 微信小程序也要求使用 HTTPS 協(xié)議。
那么，我們?yōu)槭裁捶且鲞@么一件事呢？我們先來看看 HTTP。
HTTP（Hypertext Transfer Protocol）超文本傳輸協(xié)議，是一種用于分布式、協(xié)作式和超媒體信息系統(tǒng)的應用層協(xié)議，可以說 HTTP 是當代互聯(lián)網(wǎng)通信的基礎。
但是，HTTP 有著一個致命的缺陷，那就是內容是明文傳輸?shù)模瑳]有經過任何加密。
而這些明文數(shù)據(jù)會經過 WiFi、路由器、運營商、機房等多個物理設備節(jié)點，如果在這中間任意一個節(jié)點被監(jiān)聽，傳輸?shù)膬热菥蜁耆┞丁?/p>
這一攻擊手法叫做 MITM（Man In The Middle）中間人攻擊。
舉個例子，稍微有點長，但這個例子透露出了怪怪我對安全如此癡迷的原因。
可以拿小時候上課傳紙條來類比，你坐在教室靠墻的一邊，想要傳一句「晚上放學操場我等你」給坐在窗邊的小紅，中間要經過六七個人的傳遞。
雖然你把紙條對折了一下，但是防君子不防小人，中間的所有人都可以很輕易地打開紙條看到你想要說什么。
只是看還好，如果有小剛也喜歡小紅，看到你倆馬上就要甜甜蜜蜜地回家了，心有不甘，換了一張紙條，改成了「晚上放學你自己回家吧，我要去網(wǎng)吧玩游戲」。
小紅看到你要拋棄她自己去玩游戲，非常傷心，開始在紙條上質問「說好的一起回家呢，為什么要去打游戲，哼」。
在小紅的紙條傳回來的路上，小剛又改了紙條「你玩你的游戲去吧，我要和小剛回家」。
于是，你和小紅都倍感傷心，小剛橫刀奪愛，而你一頭霧水。
回憶一下幾年前遍地都是的運營商劫持，當你訪問一個本來很正常的網(wǎng)頁，但頁面上卻莫名其妙出現(xiàn)了一些廣告標簽、跳轉腳本、欺騙性的紅包按鈕。
甚至有時候本來要下載一個文件，最后下下來卻變成了另外一個完全不同的東西，這些都是被運營商劫持了 HTTP 明文數(shù)據(jù)的現(xiàn)象。
運營商劫持
還有各大公司的員工安全培訓里都有一條「不要連陌生的 WiFi」，也是類似的原因，惡意 WiFi 的控制者可以看到和篡改 HTTP 明文傳輸?shù)男畔ⅰ?/p>
為了解決 HTTP 明文傳輸數(shù)據(jù)可能導致的安全問題，1994 年網(wǎng)景公司提出了 HTTPS（HyperText Transfer Protocol Secure）超文本傳輸安全協(xié)議，數(shù)據(jù)通信仍然是 HTTP，但利用 SSL/TLS 加密數(shù)據(jù)包。
HTTPS 實現(xiàn)原理
前面說到，HTTPS 其實就是將 HTTP 的數(shù)據(jù)包再通過 SSL/TLS 加密后傳輸，那么 SSL/TLS 又是什么呢？
SSL（Secure Sockets Layer）安全套接層和 TLS（Transport Layer Security）傳輸層安全協(xié)議其實是一套東西。
網(wǎng)景公司在 1994 年提出 HTTPS 協(xié)議時，使用的是 SSL 進行加密。
后來 IETF（Internet Engineering Task Force）互聯(lián)網(wǎng)工程任務組將 SSL 進一步標準化，于 1999 年公布第一版 TLS 協(xié)議文件 TLS 1.0。目前最新版的 TLS 協(xié)議是 TLS 1.3，于 2018 年公布。
工作流程
我們先來看看 HTTPS 的加解密流程，如下圖：
HTTPS 加解密流程如下：
· 用戶在瀏覽器發(fā)起 HTTPS 請求（如 https://www.mogu.com/），默認使用服務端的 443 端口進行連接。
· HTTPS 需要使用一套 CA 數(shù)字證書，證書內會附帶一個公鑰 Pub，而與之對應的私鑰 Private 保留在服務端不公開。
· 服務端收到請求，返回配置好的包含公鑰 Pub 的證書給客戶端。
· 客戶端收到證書，校驗合法性，主要包括是否在有效期內、證書的域名與請求的域名是否匹配，上一級證書是否有效（遞歸判斷，直到判斷到系統(tǒng)內置或瀏覽器配置好的根證書），如果不通過，則顯示 HTTPS 警告信息，如果通過則繼續(xù)。
· 客戶端生成一個用于對稱加密的隨機 Key，并用證書內的公鑰 Pub 進行加密，發(fā)送給服務端。
· 服務端收到隨機 Key 的密文，使用與公鑰 Pub 配對的私鑰 Private 進行解密，得到客戶端真正想發(fā)送的隨機 Key。
· 服務端使用客戶端發(fā)送過來的隨機 Key 對要傳輸?shù)?HTTP 數(shù)據(jù)進行對稱加密，將密文返回客戶端。
· 客戶端使用隨機 Key 對稱解密密文，得到 HTTP 數(shù)據(jù)明文。
· 后續(xù) HTTPS 請求使用之前交換好的隨機 Key 進行對稱加解密。
對稱加密與非對稱加密
又是對稱加密又是非對稱加密，一會公鑰一會私鑰一會隨機 Key，為什么要這么復雜呢，一套搞到底不好么？
對稱加密是指有一個密鑰，用它可以對一段明文加密，加密之后也只能用這個密鑰來解密得到明文。
如果通信雙方都持有密鑰，且天知地知你知我知，絕對不會有別的人知道，那么通信安全自然是可以得到保證的（在密鑰足夠強的情況下）。
然而，在 HTTPS 的傳輸場景下，服務端事先并不知道客戶端是誰，你也不可能在事先不通過互聯(lián)網(wǎng)和每一個網(wǎng)站的管理員都悄悄商量好一個通信密鑰出來。
那么必然存在一個密鑰在互聯(lián)網(wǎng)上傳輸?shù)倪^程，如果在傳輸過程中被別人監(jiān)聽到了，那么后續(xù)的所有加密都是無用功。
這時，我們就需要另一種神奇的加密類型，非對稱加密。
非對稱加密有兩個密鑰，一個是公鑰，另一個是私鑰。一般來說，公鑰用來加密，這時密文只能用私鑰才能解開。
那么，當客戶端發(fā)起連接請求，服務端將公鑰傳輸過去，客戶端利用公鑰加密好信息，再將密文發(fā)送給服務端，服務端里有私鑰可以解密。
但是，當服務端要返回數(shù)據(jù)，如果用公鑰加密，那么客戶端并沒有私鑰用來解密，而如果用私鑰加密，客戶端雖然有公鑰可以解密。但這個公鑰之前就在互聯(lián)網(wǎng)上傳輸過，很有可能已經有人拿到，并不安全，所以這一過程只用非對稱加密是不能滿足的。注意，嚴格來講，私鑰并不能用來加密，只能用作簽名使用，這是由于密碼學中生成公鑰私鑰時對不同變量的數(shù)學要求是不同的。
因此公鑰私鑰抵抗攻擊的能力也不同，在實際使用中不可互換。簽名的功能在 HTTPS 里也有用到，下文中會說明。
只有一組公鑰私鑰只能保證單程的加解密，那么如果我們準備兩組公鑰私鑰呢，是不是可以解決這個問題？
來看下面這個過程：
· 服務端有非對稱加密的公鑰 A1，私鑰 A2。
· 客戶端有非對稱加密的公鑰 B1，私鑰 B2。
· 客戶端向服務端發(fā)起請求，服務端將公鑰 A1 返回給客戶端。
· 瀏覽器收到公鑰 A1，將自己保存的公鑰 B1 發(fā)送給服務端。
· 之后瀏覽器所有向客戶端發(fā)送的數(shù)據(jù)，使用公鑰 B1 加密，客戶端可以使用私鑰 B2 解密。
· 客戶端所有向服務端發(fā)送的數(shù)據(jù)，使用公鑰 A1 加密，服務端可以使用私鑰 A2 解密。
此時，兩條傳輸方向的數(shù)據(jù)都經過非對稱加密，都能保證安全性，那么為什么不采用這種方案呢？
最主要的原因是非對稱加解密耗時要遠大于對稱加解密，對性能有很大損耗，大家的使用體驗很差。
所以，我們才最終選用了上文介紹到非對稱加密+對稱加密的方案，再復習一下：
· 服務端有非對稱加密的公鑰 A1，私鑰 A2。
· 客戶端發(fā)起請求，服務端將公鑰 A1 返回給客戶端。
· 客戶端隨機生成一個對稱加密的密鑰 K，用公鑰 A1 加密后發(fā)送給服務端。
· 服務端收到密文后用自己的私鑰 A2 解密，得到對稱密鑰 K，此時完成了安全的對稱密鑰交換，解決了對稱加密時密鑰傳輸被人竊取的問題。
· 之后雙方通信都使用密鑰 K 進行對稱加解密。
看起來是一個非常完美的方案，兼顧了安全性和性能，但是，真的就安全了么？
CA 頒發(fā)機構
依然考慮中間人攻擊的情況，非對稱加密的算法都是公開的，所有人都可以自己生成一對公鑰私鑰。
當服務端向客戶端返回公鑰 A1 的時候，中間人將其替換成自己的公鑰 B1 傳送給瀏覽器。
而瀏覽器此時一無所知，傻乎乎地使用公鑰 B1 加密了密鑰 K 發(fā)送出去，又被中間人截獲。
中間人利用自己的私鑰 B2 解密，得到密鑰 K，再使用服務端的公鑰 A1 加密傳送給服務端，完成了通信鏈路，而服務端和客戶端毫無感知。
HTTPS 中間人
出現(xiàn)這一問題的核心原因是客戶端無法確認收到的公鑰是不是真的是服務端發(fā)來的。為了解決這個問題，互聯(lián)網(wǎng)引入了一個公信機構，這就是 CA。
服務端在使用 HTTPS 前，去經過認證的 CA 機構申請頒發(fā)一份數(shù)字證書，數(shù)字證書里包含有證書持有者、證書有效期、公鑰等信息。
服務端將證書發(fā)送給客戶端，客戶端校驗證書身份和要訪問的網(wǎng)站身份確實一致后再進行后續(xù)的加密操作。
但是，如果中間人也聰明一點，只改動了證書中的公鑰部分，客戶端依然不能確認證書是否被篡改，這時我們就需要一些防偽技術了。
前面說過，非對稱加密中一般公鑰用來加密，私鑰用來解密，雖然私鑰加密理論上可行，但由于數(shù)學上的設計這么做并不適合，那么私鑰就只有解密這個功能了么？
私鑰除了解密外的真正用途其實還有一個，就是數(shù)字簽名，其實就是一種防偽技術，只要有人篡改了證書，那么數(shù)字簽名必然校驗失敗。
具體過程如下：
· CA 機構擁有自己的一對公鑰和私鑰。
· CA 機構在頒發(fā)證書時對證書明文信息進行哈希。
· 將哈希值用私鑰進行加簽，得到數(shù)字簽名。
明文數(shù)據(jù)和數(shù)字簽名組成證書，傳遞給客戶端：
· 客戶端得到證書，分解成明文部分 Text 和數(shù)字簽名 Sig1。
· 用 CA 機構的公鑰進行解簽，得到 Sig2（由于 CA 機構是一種公信身份，因此在系統(tǒng)或瀏覽器中會內置 CA 機構的證書和公鑰信息）。
· 用證書里聲明的哈希算法對明文 Text 部分進行哈希得到 H。
· 當自己計算得到的哈希值 T 與解簽后的 Sig2 相等，表示證書可信，沒有被篡改。
這時，簽名是由 CA 機構的私鑰生成的，中間人篡改信息后無法拿到 CA 機構的私鑰，保證了證書可信。
注意，這里有一個比較難以理解的地方，非對稱加密的簽名過程是，私鑰將一段消息進行加簽，然后將簽名部分和消息本身一起發(fā)送給對方。
收到消息后對簽名部分利用公鑰驗簽，如果驗簽出來的內容和消息本身一致，表明消息沒有被篡改。
在這個過程中，系統(tǒng)或瀏覽器中內置的 CA 機構的證書和公鑰成為了至關重要的環(huán)節(jié)，這也是 CA 機構公信身份的證明，如果系統(tǒng)或瀏覽器中沒有這個 CA 機構，那么客戶端可以不接受服務端傳回的證書，顯示 HTTPS 警告。
實際上 CA 機構的證書是一條信任鏈，A 信任 B，B 信任 C，以掘金的證書為例，掘金向 RapidSSL 申請一張證書，而 RapidSSL 的 CA 身份是由 DigiCert Global 根 CA 認證的，構成了一條信任鏈。
各級 CA 機構的私鑰是絕對的私密信息，一旦 CA 機構的私鑰泄露，其公信力就會一敗涂地。
之前就有過幾次 CA 機構私鑰泄露，引發(fā)信任危機，各大系統(tǒng)和瀏覽器只能紛紛吊銷內置的對應 CA 的根證書。
有些老舊的網(wǎng)站會要求使用前下載安裝他自己的根證書，這就是這個網(wǎng)站使用的證書并不能在系統(tǒng)內置的 CA 機構和根證書之間形成一條信任鏈，需要自己安裝根證書來構成信任鏈，這里的風險就要使用者自己承擔了。
證書明細
總結
HTTPS 的出發(fā)點是解決 HTTP 明文傳輸時信息被篡改和監(jiān)聽的問題：
· 為了兼顧性能和安全性，使用了非對稱加密+對稱加密的方案。
· 為了保證公鑰傳輸中不被篡改，又使用了非對稱加密的數(shù)字簽名功能，借助 CA 機構和系統(tǒng)根證書的機制保證了 HTTPS 證書的公信力。
