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

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

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

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

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

HTTP 帶來的風險

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

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

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

答復：李明你好，已確認你的身份。昨天張三給你發了一條私信，內容是「天氣真好」。

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

這樣至少就帶來以下風險：

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

HTTPS 的互相問候

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

致少數派：

我需要訪問私信；

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

我生成了一個隨機數，11872

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

1. 所需訪問的網站
2. 我所支持的算法
3. 我生成的隨機數

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

答復：

我們就用 TLS_RSA_WITH_AES_256_GCM_SHA384 算法吧；

我也生成了一個隨機數，785391；

給你私信網站的證書（一個文件袋）

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

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

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

證書，一個文件袋

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

例如使用 Google Chrome 打開少數派網站，地址欄的左側會出現一把小鎖。點擊之后，可以查看證書的詳細情況：

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

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

接下來，你會一一對這些信息進行處理。

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

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

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

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

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

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

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

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

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

HTTPS 的初次加密嘗試

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

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

【這是只有你和少數派才可以看到的內容】

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

整理一下。結合前面的「問候」過程，現在你和少數派雙方手上擁有：

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

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

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

愉快的秘密通信

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

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

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

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

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

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

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

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

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

HTTPS 已隨處可見

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

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

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

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

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

還有幾個問題值得討論

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

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

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

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

為什么有些軟件還是可以讀取 HTTPS 內容？

我所知的幾種方法。

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

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

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

1. 你跟郵差之間通信，使用郵差的證書
2. 郵差收到你的內容，轉發給少數派，使用少數派的證書
3. 郵差收到少數派的內容，用少數派的密碼解密
4. 郵差把少數派的答復轉發給你，用與你之間的密碼加密

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

自簽名證書安全嗎？

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

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

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

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

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

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

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路徑和參數、返回的頭部和消息體，這些都是加密的。而信件的地址，也就是 IP 地址，必然是會被郵差知道，否則郵差不知道把信送到哪兒去。

唯一的漏網之魚來自于 SNI（Server Name Indication，服務器名稱指示）?？蛻舳讼蚍斩税l起請求的時候，會表明自己想要訪問的網站。例如，前面的例子中，你向少數派問候時：

我需要訪問私信

而少數派則回復：

給你私信網站的證書（一個文件袋）

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

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

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

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

你可以做些什么

基于前面的討論，我們可以思考如何更安全地在互聯網上瀏覽。

從一開始就使用 HTTPS

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

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

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

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

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

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

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

這些行為包括：

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

為自己的網站加上 HTTPS

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

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

本文章來源：少數派