多年以前，我還在上大學(xué)的時候，曾經(jīng)聽學(xué)長說起他打過的一份工，每個月可以賺不少零花錢。這份工作非常簡單，就是去互聯(lián)網(wǎng)上流行的各種網(wǎng)站、手機上流行的各大 APP 以及各個網(wǎng)站的手機瀏覽器版本（WAP、H5 之類的）執(zhí)行一些基本的操作，包括注冊、登錄、操作具體業(yè)務(wù)等，比如航空類的網(wǎng)站就嘗試查詢航班、購買機票，團(tuán)購類的網(wǎng)站就嘗試搜索美食、發(fā)布評價……

在操作的同時，通過 Wireshark 這樣的抓包軟件把所有的通信包全部記錄下來并分析其中的 HTTP 數(shù)據(jù)，你會發(fā)現(xiàn)賬號、業(yè)務(wù)內(nèi)容等信息絕大部分都以明文形式在互聯(lián)網(wǎng)上流動，即使少部分看起來是亂碼，經(jīng)過簡單的解碼、解密，也可以快速獲取原文。

學(xué)長告訴我這樣的世界太不安全了：想要通過互聯(lián)網(wǎng)完成任何一件事情，你都需要從電腦或手機發(fā)起一系列 HTTP 請求，這些請求通過一層層的路由，最終送到千里之外的某臺服務(wù)器。

在這個過程中，你同宿舍的室友可能在偷看你的聊天，你的學(xué)校也可能以安全為由監(jiān)控著你的行蹤，還有一些不法分子在暗中記錄你的賬號和密碼；在這個過程中，許許多多的釣魚網(wǎng)站通過攔截你的網(wǎng)絡(luò)，假冒銀行、政府，獲取你的信任，套取你的信息；在這個過程中，運營商可能為了利益，在你正常瀏覽的網(wǎng)頁中嵌入了生硬的廣告，篡改了原始的頁面內(nèi)容……

直到我們有了 HTTPS —— 它簡直就是這一切的「救世主」。

HTTP 帶來的風(fēng)險

HTTPS，中文名是「超文本傳輸安全協(xié)議」（HyperText Transfer Protocol Secure），它以 HTTP 為基礎(chǔ)，為 HTTP 提供額外的加密和認(rèn)證。這也正是其名字的由來：HTTP + Secure。

如果我們用日常生活中的交流來模擬 HTTP，那么?明文的聊天?可能是這樣的：

致少數(shù)派：我叫李明，我的密碼是 123456；我最近收到了什么新的私信？

答復(fù)：李明你好，已確認(rèn)你的身份。昨天張三給你發(fā)了一條私信，內(nèi)容是「天氣真好」。

問題在于你和少數(shù)派并不是面對面交流的。事實上你跟少數(shù)派說的每一句話，都像一張明信片一樣，郵局拿到你的明信片，中間經(jīng)過一層層的郵政網(wǎng)點轉(zhuǎn)發(fā)，最終才派送到少數(shù)派那兒。少數(shù)派給你的答復(fù)也是如此。

這樣至少就帶來以下風(fēng)險：

1. 明信片嘛，所有郵遞員都可以看到。大家不但知道了你的私信內(nèi)容，大家甚至知道了你的姓名和密碼
2. 你雖然收到了一個答復(fù)，但是你無法確定到底是不是少數(shù)派給出的。萬一哪個郵遞員懶得（或者故意不去）送你的明信片，而自己隨便寫了一條私信回給你呢？
3. 內(nèi)容可能被篡改。郵遞員完成了派送，也成功取回了少數(shù)派給你的答復(fù)。但是少數(shù)派回復(fù)的私信內(nèi)容明明是「天氣真好」，有個搗蛋的郵遞員把它改成了「天氣真不好」

HTTPS 的互相問候

引入 HTTPS 之后情況就完全不一樣了，雖然仍然使用明信片進(jìn)行交流，但是這次你和少數(shù)派之間首先有個見面的問候：

致少數(shù)派：

我需要訪問私信；

我懂得使用 TLS_RSA_WITH_AES_256_GCM_SHA384 算法、 TLS_RSA_WITH_AES_128_GCM_SHA256 算法，你選一個；

我生成了一個隨機數(shù)，11872

當(dāng)然，實際使用時的信息會再多一些，這里只選取了其中最重要的幾個。它們分別是：

1. 所需訪問的網(wǎng)站
2. 我所支持的算法
3. 我生成的隨機數(shù)

少數(shù)派拿到你的信息之后，會根據(jù)自身情況做出答復(fù)：

答復(fù)：

我們就用 TLS_RSA_WITH_AES_256_GCM_SHA384 算法吧；

我也生成了一個隨機數(shù)，785391；

給你私信網(wǎng)站的證書（一個文件袋）

少數(shù)派給的答復(fù)也比我所舉的例子復(fù)雜得多，這里選取的幾項分別是：

1. 從你所給的幾種算法中挑了一種，雙方都合適的
2. 也生成了一個隨機數(shù)
3. 給了你所需網(wǎng)站的證書

HTTPS 的安全通道尚未建立，但是我們有必要先來看一下這張證書。

證書，一個文件袋

經(jīng)過和少數(shù)派的第一次通信，你擁有了一張證書；或者說是一個文件袋，里面裝滿了各種文件，可供查驗和使用。你可以在任何瀏覽器中看到這張證書。

例如使用 Google Chrome 打開少數(shù)派網(wǎng)站，地址欄的左側(cè)會出現(xiàn)一把小鎖。點擊之后，可以查看證書的詳細(xì)情況：

這張證書主要包含以下信息：

1. 證書頒給了哪個或哪些網(wǎng)站（使用者）
2. 證書的有效期的起止時間（有效期）
3. 一個公鑰
4. 證書是由誰頒發(fā)的（頒發(fā)者）

接下來，你會一一對這些信息進(jìn)行處理。

第一項很好理解，使用者，就是這張證書對誰有效。你看了一眼，嗯，*.sspai.com，這是一個通配符域名，意思就是對所有?sspai.com?的域名都有效。好的，它確實符合少數(shù)派網(wǎng)站的網(wǎng)址，驗證通過。

第二項，有效期，也很容易。你在自己的電腦上查了一下時間，2021 年 8 月，確實是在有效期區(qū)間內(nèi)，好的，驗證通過。

第三項是一個?公鑰，先存下來后面用。

第四項，頒發(fā)者，雖然你知道了這張證書是由一個叫做 RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1 的人頒發(fā)的。但這個人又是誰，他值得信任嗎？

這就要看證書中的最后一項內(nèi)容，證書路徑。在這里，我們可以通過一個樹形圖，清晰地看到我們當(dāng)前這個證書的信任鏈。對于列表中的每一項，都可以通過右下方「查看證書」按鈕，讀取到這一項的證書信息。

也就是說，列表中的每一項其實都是一張完整的證書。在這個例子中：

• RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1 保證了?*.sspai.com?的證書是可信任的
• DigiCert 保證了 RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1 的證書是可信任的
• 瀏覽器，或者操作系統(tǒng)，充分信任 DigiCert（瀏覽器或操作系統(tǒng)會維護(hù)一個受信任的列表）

因此，隨著一層層的信任關(guān)系你也就信任了?*.sspai.com?這張證書；這種信任帶來的最重要的意義在于——你相信，證書中包含的那個「公鑰」確實是屬于少數(shù)派的，而不是其中任何一個郵差偽造的。

所以，證書帶來的結(jié)果就是：你擁有了一個確信是少數(shù)派的公鑰。

HTTPS 的初次加密嘗試

公鑰就像是從證書這個文件袋中捎過來的一個信封，一旦封口，就只有證書擁有者使用私鑰才可以打開；換言之，你只要用這個信封寄送，那么就只有少數(shù)派可以讀到（啊，用于封口的是?一種神奇的膠水，這是由數(shù)學(xué)原理保證的）。

你可以放心地使用從證書中找到的這枚公鑰。如果你決定試一下，便可以生成一個隨機數(shù) 36721，寫在明信片上，然后興致勃勃地把明信片裝進(jìn)信封，仔細(xì)地封好口子。

【這是只有你和少數(shù)派才可以看到的內(nèi)容】

現(xiàn)在，你交給郵局的不再是體無遮攔的明信片，而是一個信封。郵差看不到信件的內(nèi)容，他只知道這封信送往何處；少數(shù)派成功收到了這封信，并使用少數(shù)派的私鑰拆開了信封。最后一個隨機數(shù)成功送達(dá)。

整理一下。結(jié)合前面的「問候」過程，現(xiàn)在你和少數(shù)派雙方手上擁有：

1. 一個雙方都認(rèn)可的加密算法 TLS_RSA_WITH_AES_256_GCM_SHA384，郵差可以偷看
2. 一個少數(shù)派生成的隨機數(shù) 785391，郵差可以偷看
3. 一個你生成的隨機數(shù) 11872，郵差可以偷看
4. 另一個你生成的隨機數(shù) 36721，只有你和少數(shù)派知道

通過這些信息，你和少數(shù)派會各自使用三個隨機數(shù)和算法，計算出一個稱為「會話密鑰」的密碼。由于隨機數(shù)和算法都已經(jīng)確定，因此你和少數(shù)派計算出的「會話密鑰」必然是一致的；假設(shè)這個計算出來的密碼是 1627638。

你們事實上完成了一件很有意思的事情：在所有聊天內(nèi)容都會被人偷看的情況下，你們成功交換了密碼。這使得后續(xù)的秘密聊天成為可能。交換密鑰的方法也還有很多，這里僅僅展示了其中的一種。

愉快的秘密通信

好了，最后，你們可以使用前面制作的 1627638 這個密碼來進(jìn)行后面的聊天。

這個密碼用起來就方便多了，只要雙方通過?一個帶密碼鎖的小盒子?來互相通信，那路上的郵差就肯定打不開。

暴力解鎖？密碼復(fù)雜度保證了即使用人類最頂級的計算機，也無法在有生之年把密碼猜出來。（1627638 這只是個例子，實際使用當(dāng)然不可能這么短?。?/p>

你把想問的問題（我的私信？）塞進(jìn)了密碼鎖，并把密碼鎖的密碼設(shè)為 1627638，鎖上之后打亂密碼鎖。

少數(shù)派拿到了這個密碼鎖，通過 1627638 解開密碼鎖。同樣的，少數(shù)派會把你的私信內(nèi)容也用 1627638 鎖上，寄回給你。

最后，你還是用 1627638 解鎖私信內(nèi)容，秘密通信順利完成。

再來回頭看看最開始 HTTP 遇到幾個風(fēng)險，在 HTTPS 中是如何解決的：

1. 郵差知道了你的私信內(nèi)容、姓名和密碼：在 HTTPS 中，由于通信使用 1627638 這個密碼鎖來加密，所以路上的郵差不可能知道信件的內(nèi)容
2. 無法確定到底是不是少數(shù)派給出的答復(fù)：在 HTTPS 中，證書的信任鏈保證了「公鑰」的可信度，而公鑰和私鑰的匹配認(rèn)證了少數(shù)派的身份
3. 搗蛋的郵遞員修改了信件內(nèi)容：在 HTTPS 中，由于使用了密碼鎖，郵差讀不了郵件，也無法寫入信件

所以通過這稍顯復(fù)雜的 HTTPS 通道，我們最終解決了 HTTP 的一些風(fēng)險。

HTTPS 已隨處可見

現(xiàn)在幾乎所有主流的瀏覽器都已經(jīng)用比較強烈的視覺效果區(qū)分了 HTTP 和 HTTPS 網(wǎng)站，例如 Google Chrome，訪問少數(shù)派網(wǎng)站時，地址欄前方的標(biāo)識是一把寓示著安全的小鎖，點開則提示「連接是安全的」：

而如果訪問一個使用 HTTP 的網(wǎng)站，則會直接顯示「不安全」：

當(dāng)訪問的網(wǎng)站，雖然正常完成了「問候」的過程，但是從服務(wù)器取到的證書存在或多或少的問題時，瀏覽器會阻斷你們之間的通信：

即使通過「高級」按鈕底下的選項堅持訪問，瀏覽器依然會時刻把「不安全」標(biāo)注為醒目的紅色：

這樣激進(jìn)的措施曾經(jīng)飽受爭議，但是瀏覽器這樣的強制性的行為卻帶來了非常好的結(jié)果。時至今天，我們已經(jīng)很少見到有哪個網(wǎng)站還只支持 HTTP 訪問，也很少見到證書錯誤的情況。以至于當(dāng)我們說起互聯(lián)網(wǎng)的時候，我們已經(jīng)很難想象，當(dāng)年那樣幾乎完全基于 HTTP 的通信是多么不可靠、不安全。

還有幾個問題值得討論

為什么一定要有「會話密鑰」，直接使用公私鑰對來通信不好嗎？

確實，為了交換一個保險箱密碼我們多花了不少精力。而要取得少數(shù)派的神奇信封，似乎只要向少數(shù)派索取一個證書就可以了。

但這樣做原因很簡單：用保險箱上鎖，只要打亂密碼就可以了，成本低；而神奇信封和用于封口的神奇膠水太貴了。

術(shù)語來講，前者稱為對稱加密，后者稱為非對稱加密。對稱加密更加高效。

為什么有些軟件還是可以讀取 HTTPS 內(nèi)容？

我所知的幾種方法。

第一種，你可以直接通過瀏覽器 F12 的「網(wǎng)絡(luò)」標(biāo)簽頁來讀取 HTTPS 內(nèi)容。這里，瀏覽器就是通信雙方中的一方（也就是上文中的「你」），自然知道所有的加密要素，所以通過瀏覽器可以讀到明文的數(shù)據(jù)也就不足為奇了；就像你可以知道你發(fā)給少數(shù)派、少數(shù)派發(fā)給你的所有信息一樣自然。

第二種，你信任其中一個郵差，告訴了他密碼鎖的密碼；那郵差就可以讀信給你聽了。

還有一種，是通過安裝私有證書來實現(xiàn)。你信任一個郵差，所以你把郵差的證書加入了自己系統(tǒng)的「受信任列表」；于是：

1. 你跟郵差之間通信，使用郵差的證書
2. 郵差收到你的內(nèi)容，轉(zhuǎn)發(fā)給少數(shù)派，使用少數(shù)派的證書
3. 郵差收到少數(shù)派的內(nèi)容，用少數(shù)派的密碼解密
4. 郵差把少數(shù)派的答復(fù)轉(zhuǎn)發(fā)給你，用與你之間的密碼加密

所以，只要你保護(hù)好自己的「受信任列表」，就不用擔(dān)心 HTTPS 通信被他人偷看，換句話說，如果有網(wǎng)站讓你「添加證書到系統(tǒng)」，為了安全請一定要慎重。

自簽名證書安全嗎？

不安全，自簽名證書屬于自欺欺人、掩耳盜鈴、欲蓋彌彰。

有些網(wǎng)站會自己簽發(fā)證書。由于缺少了可靠的證書信任鏈，客戶端無法驗證服務(wù)端的真實身份，因此信件很容易被路上的郵差調(diào)包；如果郵差從最開始的「問候」階段就開始動壞心思，那么整個通信都可以被郵差控制。

當(dāng)使用自簽名證書時，幾乎所有瀏覽器都會給出證書出錯的提示，需要用戶手動確認(rèn)才可以繼續(xù)訪問。

中間人還可以竊聽到什么信息？

路由器和運營商提供的訪問統(tǒng)計、以安全之名實行的網(wǎng)站攔截，亦或是以大數(shù)據(jù)之名而進(jìn)行的隱私追蹤，這些在 HTTPS 中依然可以做到嗎？采取了 HTTPS 通信后，作為路上的郵差，還可以偷看到哪些信息呢？

自然，加密信件的全部內(nèi)容都無法獲取。這些內(nèi)容包括：

GET /message/2hzb91qd HTTP/1.1
Host: sspai.com
Connection: keep-alive
Cache-Control: max-age=0
sec-ch-ua: "Chromium";v="92", " Not A;Brand";v="99", "Microsoft Edge";v="92"
sec-ch-ua-mobile: ?0
DNT: 1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36 Edg/92.0.902.62
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6,zh-TW;q=0.5,ja;q=0.4,sl;q=0.3
If-Modified-Since: Wed, 04 Aug 2021 08:54:52 GMT

HTTP/1.1 200 OK
Server: nginx/1.10.3
Date: Wed, 04 Aug 2021 08:55:22 GMT
Last-Modified: Wed, 04 Aug 2021 08:54:52 GMT
Access-Control-Allow-Origin: *.sspai.com
Content-Type: text/html
Vary: Accept-Encoding
ETag: W/"610a55dc-1121"
Content-Encoding: gzip

<!DOCTYPE html><html lang=en id=html>
...

 

也就是說，包括主機名、請求體、URL路徑和參數(shù)、返回的頭部和消息體，這些都是加密的。而信件的地址，也就是 IP 地址，必然是會被郵差知道，否則郵差不知道把信送到哪兒去。

唯一的漏網(wǎng)之魚來自于 SNI（Server Name Indication，服務(wù)器名稱指示）。客戶端向服務(wù)端發(fā)起請求的時候，會表明自己想要訪問的網(wǎng)站。例如，前面的例子中，你向少數(shù)派問候時：

我需要訪問私信

而少數(shù)派則回復(fù)：

給你私信網(wǎng)站的證書（一個文件袋）

這是因為，同一臺服務(wù)器上，可能部署了多個子網(wǎng)站（例如可能私信、文章區(qū)分了不同的子域名，但是部署在同一個服務(wù)器上），那么就需要客戶端指明所需訪問的網(wǎng)站，服務(wù)器才可以給出合適的證書。

例如，sspai.com?或者?ditu.baidu.com?這樣的域名依然通過「明信片」的形式發(fā)送，郵差們可以隨意查看。但是，?/message/2hzb91qd?這樣表明「查看某條私信」的具體操作，則是安全的。

這也為基于 HTTPS 的網(wǎng)絡(luò)通信過濾提供了方便。前面所說的訪問統(tǒng)計、網(wǎng)站攔截、隱私追蹤，很大一部分都是靠的 SNI 這個參數(shù)。但是就像前述例子中所述，SNI 僅提供域名，而 URL 地址包含在加密的 HTTP 消息中，因此追蹤也相對有限。

事實上，現(xiàn)在也有技術(shù)來保護(hù) SNI 的安全，例如 ESNI 和后來演變成的 ECH 都是非常有效的嘗試。

你可以做些什么

基于前面的討論，我們可以思考如何更安全地在互聯(lián)網(wǎng)上瀏覽。

從一開始就使用 HTTPS

對于支持 HTTPS 的網(wǎng)站，大部分都對 HTTP 進(jìn)行了跳轉(zhuǎn)。舉例來說，當(dāng)你訪問少數(shù)派網(wǎng)站時，如果直接在瀏覽器中輸入?sspai.com?就敲下回車鍵，那么瀏覽器會自動跳轉(zhuǎn)到?http://sspai.com?而不是 HTTPS 站點。而少數(shù)派網(wǎng)站在收到 HTTP 請求后，會告訴你：我改地址了，請使用 HTTPS 訪問。

致少數(shù)派：我需要訪問首頁，這是我的個人信息

答復(fù)：我換地方了，請使用 https://sspai.com/ 重新訪問

于是，你重新發(fā)起了一次聊天，這次，你使用了 HTTPS。

這里有很明顯的問題，當(dāng)你使用 HTTP 訪問時，你已經(jīng)把你需要訪問的內(nèi)容（少數(shù)派首頁）、你的個人信息，都以「明信片」的形式交給了郵差。雖然少數(shù)派提醒了你需要更換地址并拒絕給予任何有實際意義的答復(fù)，但是這之前已經(jīng)稍許泄露了信息。

所以最好的做法是，當(dāng)你訪問網(wǎng)站時，直接輸入：?https://sspai.com?而不要偷懶讓瀏覽器自動去跳轉(zhuǎn)。

絕對不要信任不可靠的證書

這些行為包括：

• 有些銀行網(wǎng)站，會讓你提前安裝「網(wǎng)銀助手」，其中一步就是「把銀行自己的證書安裝到系統(tǒng)中」。這其實并不安全。不過現(xiàn)在這樣做的銀行已經(jīng)越來越少了。
• 遇到證書過期、域名不匹配、信任鏈存在瑕疵的證書時，瀏覽器會給予全屏提示。此時雖然有小字可以點擊「繼續(xù)訪問」，但是非常不推薦此時繼續(xù)輸入敏感信息。

為自己的網(wǎng)站加上 HTTPS

如果你擁有自己的個人網(wǎng)站或者博客，那么你一定要配置一下 HTTPS 證書。我經(jīng)常使用?Let's Encrypt?提供的免費證書，借助?Certbot?這個一鍵配置工具，簡單幾行命令就可以一勞永逸地配置完成。

Let's Encrypt 的證書有效期只有三個月，但是 Certbot 提供了自動續(xù)期的功能，有效期將近時會自動更新服務(wù)器上所有托管的證書。

本文章來源：少數(shù)派