Coding 應(yīng)當(dāng)是一生的事業(yè)，而不僅僅是 30 歲的青春。網(wǎng)上很多文章對(duì) HTTPS 的講解云里霧里，看完這篇，如果還不理解，罵我渣男好了!

[[322356]]

圖片來自 Pexels

整個(gè) HTTPS 的演變跟流程細(xì)思極恐，有很多思想可以借鑒學(xué)習(xí)。我以后要離搞安全的朋友遠(yuǎn)一點(diǎn)。

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

• 明白 HTTPS 到底解決了什么問題
• 理解對(duì)稱加密與非對(duì)稱加密的原理和使用場(chǎng)景
• 明白 CA 機(jī)構(gòu)和根證書到底起了什么作用

Why HTTPS

近幾年來，各大公司都在大力推進(jìn) HTTPS 的建設(shè)：

• Google Chrome 將非 HTTPS 的網(wǎng)站標(biāo)注為不安全。
• 蘋果要求 APP 中需要使用 HTTPS 進(jìn)行通信。
• 微信小程序也要求使用 HTTPS 協(xié)議。

那么，我們?yōu)槭裁捶且鲞@么一件事呢?我們先來看看 HTTP。

HTTP(Hypertext Transfer Protocol)超文本傳輸協(xié)議，是一種用于分布式、協(xié)作式和超媒體信息系統(tǒng)的應(yīng)用層協(xié)議，可以說 HTTP 是當(dāng)代互聯(lián)網(wǎng)通信的基礎(chǔ)。

但是，HTTP 有著一個(gè)致命的缺陷，那就是內(nèi)容是明文傳輸?shù)?，沒有經(jīng)過任何加密。

而這些明文數(shù)據(jù)會(huì)經(jīng)過 WiFi、路由器、運(yùn)營商、機(jī)房等多個(gè)物理設(shè)備節(jié)點(diǎn)，如果在這中間任意一個(gè)節(jié)點(diǎn)被監(jiān)聽，傳輸?shù)膬?nèi)容就會(huì)完全暴露。

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

[[322357]]

舉個(gè)例子，稍微有點(diǎn)長，但這個(gè)例子透露出了怪怪我對(duì)安全如此癡迷的原因。

可以拿小時(shí)候上課傳紙條來類比，你坐在教室靠墻的一邊，想要傳一句「晚上放學(xué)操場(chǎng)我等你」給坐在窗邊的小紅，中間要經(jīng)過六七個(gè)人的傳遞。

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

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

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

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

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

回憶一下幾年前遍地都是的運(yùn)營商劫持，當(dāng)你訪問一個(gè)本來很正常的網(wǎng)頁，但頁面上卻莫名其妙出現(xiàn)了一些廣告標(biāo)簽、跳轉(zhuǎn)腳本、欺騙性的紅包按鈕。

甚至有時(shí)候本來要下載一個(gè)文件，最后下下來卻變成了另外一個(gè)完全不同的東西，這些都是被運(yùn)營商劫持了 HTTP 明文數(shù)據(jù)的現(xiàn)象。

運(yùn)營商劫持

還有各大公司的員工安全培訓(xùn)里都有一條「不要連陌生的 WiFi」，也是類似的原因，惡意 WiFi 的控制者可以看到和篡改 HTTP 明文傳輸?shù)男畔ⅰ?/p>

為了解決 HTTP 明文傳輸數(shù)據(jù)可能導(dǎo)致的安全問題，1994 年網(wǎng)景公司提出了 HTTPS(HyperText Transfer Protocol Secure)超文本傳輸安全協(xié)議，數(shù)據(jù)通信仍然是 HTTP，但利用 SSL/TLS 加密數(shù)據(jù)包。

HTTPS 實(shí)現(xiàn)原理

前面說到，HTTPS 其實(shí)就是將 HTTP 的數(shù)據(jù)包再通過 SSL/TLS 加密后傳輸，那么 SSL/TLS 又是什么呢?

SSL(Secure Sockets Layer)安全套接層和 TLS(Transport Layer Security)傳輸層安全協(xié)議其實(shí)是一套東西。

網(wǎng)景公司在 1994 年提出 HTTPS 協(xié)議時(shí)，使用的是 SSL 進(jìn)行加密。

后來 IETF(Internet Engineering Task Force)互聯(lián)網(wǎng)工程任務(wù)組將 SSL 進(jìn)一步標(biāo)準(zhǔn)化，于 1999 年公布第一版 TLS 協(xié)議文件 TLS 1.0。目前最新版的 TLS 協(xié)議是 TLS 1.3，于 2018 年公布。

工作流程

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

HTTPS 加解密流程如下：

• 用戶在瀏覽器發(fā)起 HTTPS 請(qǐng)求(如 https://www.mogu.com/)，默認(rèn)使用服務(wù)端的 443 端口進(jìn)行連接。
• HTTPS 需要使用一套 CA 數(shù)字證書，證書內(nèi)會(huì)附帶一個(gè)公鑰 Pub，而與之對(duì)應(yīng)的私鑰 Private 保留在服務(wù)端不公開。
• 服務(wù)端收到請(qǐng)求，返回配置好的包含公鑰 Pub 的證書給客戶端。
• 客戶端收到證書，校驗(yàn)合法性，主要包括是否在有效期內(nèi)、證書的域名與請(qǐng)求的域名是否匹配，上一級(jí)證書是否有效(遞歸判斷，直到判斷到系統(tǒng)內(nèi)置或?yàn)g覽器配置好的根證書)，如果不通過，則顯示 HTTPS 警告信息，如果通過則繼續(xù)。
• 客戶端生成一個(gè)用于對(duì)稱加密的隨機(jī) Key，并用證書內(nèi)的公鑰 Pub 進(jìn)行加密，發(fā)送給服務(wù)端。
• 服務(wù)端收到隨機(jī) Key 的密文，使用與公鑰 Pub 配對(duì)的私鑰 Private 進(jìn)行解密，得到客戶端真正想發(fā)送的隨機(jī) Key。
• 服務(wù)端使用客戶端發(fā)送過來的隨機(jī) Key 對(duì)要傳輸?shù)?HTTP 數(shù)據(jù)進(jìn)行對(duì)稱加密，將密文返回客戶端。
• 客戶端使用隨機(jī) Key 對(duì)稱解密密文，得到 HTTP 數(shù)據(jù)明文。
• 后續(xù) HTTPS 請(qǐng)求使用之前交換好的隨機(jī) Key 進(jìn)行對(duì)稱加解密。

[[322358]]

對(duì)稱加密與非對(duì)稱加密

又是對(duì)稱加密又是非對(duì)稱加密，一會(huì)公鑰一會(huì)私鑰一會(huì)隨機(jī) Key，為什么要這么復(fù)雜呢，一套搞到底不好么?

對(duì)稱加密是指有一個(gè)密鑰，用它可以對(duì)一段明文加密，加密之后也只能用這個(gè)密鑰來解密得到明文。

如果通信雙方都持有密鑰，且天知地知你知我知，絕對(duì)不會(huì)有別的人知道，那么通信安全自然是可以得到保證的(在密鑰足夠強(qiáng)的情況下)。

然而，在 HTTPS 的傳輸場(chǎng)景下，服務(wù)端事先并不知道客戶端是誰，你也不可能在事先不通過互聯(lián)網(wǎng)和每一個(gè)網(wǎng)站的管理員都悄悄商量好一個(gè)通信密鑰出來。

那么必然存在一個(gè)密鑰在互聯(lián)網(wǎng)上傳輸?shù)倪^程，如果在傳輸過程中被別人監(jiān)聽到了，那么后續(xù)的所有加密都是無用功。

這時(shí)，我們就需要另一種神奇的加密類型，非對(duì)稱加密。

非對(duì)稱加密有兩個(gè)密鑰，一個(gè)是公鑰，另一個(gè)是私鑰。一般來說，公鑰用來加密，這時(shí)密文只能用私鑰才能解開。

那么，當(dāng)客戶端發(fā)起連接請(qǐng)求，服務(wù)端將公鑰傳輸過去，客戶端利用公鑰加密好信息，再將密文發(fā)送給服務(wù)端，服務(wù)端里有私鑰可以解密。

但是，當(dāng)服務(wù)端要返回?cái)?shù)據(jù)，如果用公鑰加密，那么客戶端并沒有私鑰用來解密，而如果用私鑰加密，客戶端雖然有公鑰可以解密。

但這個(gè)公鑰之前就在互聯(lián)網(wǎng)上傳輸過，很有可能已經(jīng)有人拿到，并不安全，所以這一過程只用非對(duì)稱加密是不能滿足的。

注意，嚴(yán)格來講，私鑰并不能用來加密，只能用作簽名使用，這是由于密碼學(xué)中生成公鑰私鑰時(shí)對(duì)不同變量的數(shù)學(xué)要求是不同的。

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

只有一組公鑰私鑰只能保證單程的加解密，那么如果我們準(zhǔn)備兩組公鑰私鑰呢，是不是可以解決這個(gè)問題?

來看下面這個(gè)過程：

• 服務(wù)端有非對(duì)稱加密的公鑰 A1，私鑰 A2。
• 客戶端有非對(duì)稱加密的公鑰 B1，私鑰 B2。
• 客戶端向服務(wù)端發(fā)起請(qǐng)求，服務(wù)端將公鑰 A1 返回給客戶端。
• 瀏覽器收到公鑰 A1，將自己保存的公鑰 B1 發(fā)送給服務(wù)端。
• 之后瀏覽器所有向客戶端發(fā)送的數(shù)據(jù)，使用公鑰 B1 加密，客戶端可以使用私鑰 B2 解密。
• 客戶端所有向服務(wù)端發(fā)送的數(shù)據(jù)，使用公鑰 A1 加密，服務(wù)端可以使用私鑰 A2 解密。

此時(shí)，兩條傳輸方向的數(shù)據(jù)都經(jīng)過非對(duì)稱加密，都能保證安全性，那么為什么不采用這種方案呢?

[[322359]]

最主要的原因是非對(duì)稱加解密耗時(shí)要遠(yuǎn)大于對(duì)稱加解密，對(duì)性能有很大損耗，大家的使用體驗(yàn)很差。

所以，我們才最終選用了上文介紹到非對(duì)稱加密+對(duì)稱加密的方案，再復(fù)習(xí)一下：

• 服務(wù)端有非對(duì)稱加密的公鑰 A1，私鑰 A2。
• 客戶端發(fā)起請(qǐng)求，服務(wù)端將公鑰 A1 返回給客戶端。
• 客戶端隨機(jī)生成一個(gè)對(duì)稱加密的密鑰 K，用公鑰 A1 加密后發(fā)送給服務(wù)端。
• 服務(wù)端收到密文后用自己的私鑰 A2 解密，得到對(duì)稱密鑰 K，此時(shí)完成了安全的對(duì)稱密鑰交換，解決了對(duì)稱加密時(shí)密鑰傳輸被人竊取的問題。
• 之后雙方通信都使用密鑰 K 進(jìn)行對(duì)稱加解密。

看起來是一個(gè)非常完美的方案，兼顧了安全性和性能，但是，真的就安全了么?

CA 頒發(fā)機(jī)構(gòu)

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

當(dāng)服務(wù)端向客戶端返回公鑰 A1 的時(shí)候，中間人將其替換成自己的公鑰 B1 傳送給瀏覽器。

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

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

HTTPS 中間人

出現(xiàn)這一問題的核心原因是客戶端無法確認(rèn)收到的公鑰是不是真的是服務(wù)端發(fā)來的。為了解決這個(gè)問題，互聯(lián)網(wǎng)引入了一個(gè)公信機(jī)構(gòu)，這就是 CA。

服務(wù)端在使用 HTTPS 前，去經(jīng)過認(rèn)證的 CA 機(jī)構(gòu)申請(qǐng)頒發(fā)一份數(shù)字證書，數(shù)字證書里包含有證書持有者、證書有效期、公鑰等信息。

服務(wù)端將證書發(fā)送給客戶端，客戶端校驗(yàn)證書身份和要訪問的網(wǎng)站身份確實(shí)一致后再進(jìn)行后續(xù)的加密操作。

但是，如果中間人也聰明一點(diǎn)，只改動(dòng)了證書中的公鑰部分，客戶端依然不能確認(rèn)證書是否被篡改，這時(shí)我們就需要一些防偽技術(shù)了。

前面說過，非對(duì)稱加密中一般公鑰用來加密，私鑰用來解密，雖然私鑰加密理論上可行，但由于數(shù)學(xué)上的設(shè)計(jì)這么做并不適合，那么私鑰就只有解密這個(gè)功能了么?

私鑰除了解密外的真正用途其實(shí)還有一個(gè)，就是數(shù)字簽名，其實(shí)就是一種防偽技術(shù)，只要有人篡改了證書，那么數(shù)字簽名必然校驗(yàn)失敗。

具體過程如下：

• CA 機(jī)構(gòu)擁有自己的一對(duì)公鑰和私鑰。
• CA 機(jī)構(gòu)在頒發(fā)證書時(shí)對(duì)證書明文信息進(jìn)行哈希。
• 將哈希值用私鑰進(jìn)行加簽，得到數(shù)字簽名。

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

• 客戶端得到證書，分解成明文部分 Text 和數(shù)字簽名 Sig1。
• 用 CA 機(jī)構(gòu)的公鑰進(jìn)行解簽，得到 Sig2(由于 CA 機(jī)構(gòu)是一種公信身份，因此在系統(tǒng)或?yàn)g覽器中會(huì)內(nèi)置 CA 機(jī)構(gòu)的證書和公鑰信息)。
• 用證書里聲明的哈希算法對(duì)明文 Text 部分進(jìn)行哈希得到 H。
• 當(dāng)自己計(jì)算得到的哈希值 T 與解簽后的 Sig2 相等，表示證書可信，沒有被篡改。

[[322360]]

這時(shí)，簽名是由 CA 機(jī)構(gòu)的私鑰生成的，中間人篡改信息后無法拿到 CA 機(jī)構(gòu)的私鑰，保證了證書可信。

注意，這里有一個(gè)比較難以理解的地方，非對(duì)稱加密的簽名過程是，私鑰將一段消息進(jìn)行加簽，然后將簽名部分和消息本身一起發(fā)送給對(duì)方。

收到消息后對(duì)簽名部分利用公鑰驗(yàn)簽，如果驗(yàn)簽出來的內(nèi)容和消息本身一致，表明消息沒有被篡改。

在這個(gè)過程中，系統(tǒng)或?yàn)g覽器中內(nèi)置的 CA 機(jī)構(gòu)的證書和公鑰成為了至關(guān)重要的環(huán)節(jié)，這也是 CA 機(jī)構(gòu)公信身份的證明，如果系統(tǒng)或?yàn)g覽器中沒有這個(gè) CA 機(jī)構(gòu)，那么客戶端可以不接受服務(wù)端傳回的證書，顯示 HTTPS 警告。

實(shí)際上 CA 機(jī)構(gòu)的證書是一條信任鏈，A 信任 B，B 信任 C，以掘金的證書為例，掘金向 RapidSSL 申請(qǐng)一張證書，而 RapidSSL 的 CA 身份是由 DigiCert Global 根 CA 認(rèn)證的，構(gòu)成了一條信任鏈。

各級(jí) CA 機(jī)構(gòu)的私鑰是絕對(duì)的私密信息，一旦 CA 機(jī)構(gòu)的私鑰泄露，其公信力就會(huì)一敗涂地。

之前就有過幾次 CA 機(jī)構(gòu)私鑰泄露，引發(fā)信任危機(jī)，各大系統(tǒng)和瀏覽器只能紛紛吊銷內(nèi)置的對(duì)應(yīng) CA 的根證書。

有些老舊的網(wǎng)站會(huì)要求使用前下載安裝他自己的根證書，這就是這個(gè)網(wǎng)站使用的證書并不能在系統(tǒng)內(nèi)置的 CA 機(jī)構(gòu)和根證書之間形成一條信任鏈，需要自己安裝根證書來構(gòu)成信任鏈，這里的風(fēng)險(xiǎn)就要使用者自己承擔(dān)了。

證書明細(xì)

總結(jié)

HTTPS 的出發(fā)點(diǎn)是解決 HTTP 明文傳輸時(shí)信息被篡改和監(jiān)聽的問題：

• 為了兼顧性能和安全性，使用了非對(duì)稱加密+對(duì)稱加密的方案。
• 為了保證公鑰傳輸中不被篡改，又使用了非對(duì)稱加密的數(shù)字簽名功能，借助 CA 機(jī)構(gòu)和系統(tǒng)根證書的機(jī)制保證了 HTTPS 證書的公信力。

作者：怪怪

編輯：陶家龍

出處：轉(zhuǎn)載自微信公眾號(hào)接水怪(ID：master0931)