多年以前，我還在上大學(xué)的時候，曾經(jīng)聽學(xué)長說起他打過的一份工，每個月可以賺不少零花錢。這份工作非常簡單，就是去互聯(lián)網(wǎng)上流行的各種網(wǎng)站、手機(jī)上流行的各大 APP 以及各個網(wǎng)站的手機(jī)瀏覽器版本（WAP、H5 之類的）執(zhí)行一些基本的操作，包括注冊、登錄、操作具體業(yè)務(wù)等，比如航空類的網(wǎng)站就嘗試查詢航班、購買機(jī)票，團(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)完成任何一件事情，你都需要從電腦或手機(jī)發(fā)起一系列 HTTP 請求，這些請求通過一層層的路由，最終送到千里之外的某臺服務(wù)器。
在這個過程中，你同宿舍的室友可能在偷看你的聊天，你的學(xué)校也可能以安全為由監(jiān)控著你的行蹤，還有一些不法分子在暗中記錄你的賬號和密碼；在這個過程中，許許多多的釣魚網(wǎng)站通過攔截你的網(wǎng)絡(luò)，假冒銀行、政府，獲取你的信任，套取你的信息；在這個過程中，運(yùn)營商可能為了利益，在你正常瀏覽的網(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)險：
- 明信片嘛，所有郵遞員都可以看到。大家不但知道了你的私信內(nèi)容，大家甚至知道了你的姓名和密碼
- 你雖然收到了一個答復(fù)，但是你無法確定到底是不是少數(shù)派給出的。萬一哪個郵遞員懶得（或者故意不去）送你的明信片，而自己隨便寫了一條私信回給你呢？
- 內(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 算法，你選一個；
我生成了一個隨機(jī)數(shù)，11872
當(dāng)然，實際使用時的信息會再多一些，這里只選取了其中最重要的幾個。它們分別是：
- 所需訪問的網(wǎng)站
- 我所支持的算法
- 我生成的隨機(jī)數(shù)
少數(shù)派拿到你的信息之后，會根據(jù)自身情況做出答復(fù)：
答復(fù)：
我們就用 TLS_RSA_WITH_AES_256_GCM_SHA384 算法吧；
我也生成了一個隨機(jī)數(shù)，785391；
給你私信網(wǎng)站的證書（一個文件袋）
少數(shù)派給的答復(fù)也比我所舉的例子復(fù)雜得多，這里選取的幾項分別是：
- 從你所給的幾種算法中挑了一種，雙方都合適的
- 也生成了一個隨機(jī)數(shù)
- 給了你所需網(wǎng)站的證書
HTTPS 的安全通道尚未建立，但是我們有必要先來看一下這張證書。
證書，一個文件袋
經(jīng)過和少數(shù)派的第一次通信，你擁有了一張證書；或者說是一個文件袋，里面裝滿了各種文件，可供查驗和使用。你可以在任何瀏覽器中看到這張證書。
例如使用 Google Chrome 打開少數(shù)派網(wǎng)站，地址欄的左側(cè)會出現(xiàn)一把小鎖。點擊之后，可以查看證書的詳細(xì)情況：
這張證書主要包含以下信息：
- 證書頒給了哪個或哪些網(wǎng)站（使用者）
- 證書的有效期的起止時間（有效期）
- 一個公鑰
- 證書是由誰頒發(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é)原理保證的）。
你可以放心地使用從證書中找到的這枚公鑰。如果你決定試一下，便可以生成一個隨機(jī)數(shù) 36721，寫在明信片上，然后興致勃勃地把明信片裝進(jìn)信封，仔細(xì)地封好口子。
【這是只有你和少數(shù)派才可以看到的內(nèi)容】
現(xiàn)在，你交給郵局的不再是體無遮攔的明信片，而是一個信封。郵差看不到信件的內(nèi)容，他只知道這封信送往何處；少數(shù)派成功收到了這封信，并使用少數(shù)派的私鑰拆開了信封。最后一個隨機(jī)數(shù)成功送達(dá)。
整理一下。結(jié)合前面的「問候」過程，現(xiàn)在你和少數(shù)派雙方手上擁有：
- 一個雙方都認(rèn)可的加密算法 TLS_RSA_WITH_AES_256_GCM_SHA384，郵差可以偷看
- 一個少數(shù)派生成的隨機(jī)數(shù) 785391，郵差可以偷看
- 一個你生成的隨機(jī)數(shù) 11872，郵差可以偷看
- 另一個你生成的隨機(jī)數(shù) 36721，只有你和少數(shù)派知道
通過這些信息，你和少數(shù)派會各自使用三個隨機(jī)數(shù)和算法，計算出一個稱為「會話密鑰」的密碼。由于隨機(jī)數(shù)和算法都已經(jīng)確定，因此你和少數(shù)派計算出的「會話密鑰」必然是一致的；假設(shè)這個計算出來的密碼是 1627638。
你們事實上完成了一件很有意思的事情：在所有聊天內(nèi)容都會被人偷看的情況下，你們成功交換了密碼。這使得后續(xù)的秘密聊天成為可能。交換密鑰的方法也還有很多，這里僅僅展示了其中的一種。
愉快的秘密通信
好了，最后，你們可以使用前面制作的 1627638 這個密碼來進(jìn)行后面的聊天。
這個密碼用起來就方便多了，只要雙方通過?一個帶密碼鎖的小盒子?來互相通信，那路上的郵差就肯定打不開。
暴力解鎖？密碼復(fù)雜度保證了即使用人類最頂級的計算機(jī)，也無法在有生之年把密碼猜出來。（1627638 這只是個例子，實際使用當(dāng)然不可能這么短?。?/p>
你把想問的問題（我的私信？）塞進(jìn)了密碼鎖，并把密碼鎖的密碼設(shè)為 1627638，鎖上之后打亂密碼鎖。
少數(shù)派拿到了這個密碼鎖，通過 1627638 解開密碼鎖。同樣的，少數(shù)派會把你的私信內(nèi)容也用 1627638 鎖上，寄回給你。
最后，你還是用 1627638 解鎖私信內(nèi)容，秘密通信順利完成。
再來回頭看看最開始 HTTP 遇到幾個風(fēng)險，在 HTTPS 中是如何解決的：
- 郵差知道了你的私信內(nèi)容、姓名和密碼：在 HTTPS 中，由于通信使用 1627638 這個密碼鎖來加密，所以路上的郵差不可能知道信件的內(nèi)容
- 無法確定到底是不是少數(shù)派給出的答復(fù)：在 HTTPS 中，證書的信任鏈保證了「公鑰」的可信度，而公鑰和私鑰的匹配認(rèn)證了少數(shù)派的身份
- 搗蛋的郵遞員修改了信件內(nèi)容：在 HTTPS 中，由于使用了密碼鎖，郵差讀不了郵件，也無法寫入信件
所以通過這稍顯復(fù)雜的 HTTPS 通道，我們最終解決了 HTTP 的一些風(fēng)險。
HTTPS 已隨處可見
現(xiàn)在幾乎所有主流的瀏覽器都已經(jīng)用比較強(qiá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)飽受爭議，但是瀏覽器這樣的強(qiá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)的「受信任列表」；于是：
- 你跟郵差之間通信，使用郵差的證書
- 郵差收到你的內(nèi)容，轉(zhuǎn)發(fā)給少數(shù)派，使用少數(shù)派的證書
- 郵差收到少數(shù)派的內(nèi)容，用少數(shù)派的密碼解密
- 郵差把少數(shù)派的答復(fù)轉(zhuǎn)發(fā)給你，用與你之間的密碼加密
所以，只要你保護(hù)好自己的「受信任列表」，就不用擔(dān)心 HTTPS 通信被他人偷看，換句話說，如果有網(wǎng)站讓你「添加證書到系統(tǒng)」，為了安全請一定要慎重。
自簽名證書安全嗎？
不安全，自簽名證書屬于自欺欺人、掩耳盜鈴、欲蓋彌彰。
有些網(wǎng)站會自己簽發(fā)證書。由于缺少了可靠的證書信任鏈，客戶端無法驗證服務(wù)端的真實身份，因此信件很容易被路上的郵差調(diào)包；如果郵差從最開始的「問候」階段就開始動壞心思，那么整個通信都可以被郵差控制。
當(dāng)使用自簽名證書時，幾乎所有瀏覽器都會給出證書出錯的提示，需要用戶手動確認(rèn)才可以繼續(xù)訪問。
中間人還可以竊聽到什么信息？
路由器和運(yùn)營商提供的訪問統(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>
...
也就是說，包括主機(jī)名、請求體、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?提供的免費(fèi)證書，借助?Certbot?這個一鍵配置工具，簡單幾行命令就可以一勞永逸地配置完成。
Let's Encrypt 的證書有效期只有三個月，但是 Certbot 提供了自動續(xù)期的功能，有效期將近時會自動更新服務(wù)器上所有托管的證書。
本文章來源：少數(shù)派
