?相信你看過 HTTPS 協(xié)議的定義，知道它是一個安全的通訊協(xié)議，可以防止中間人竊聽，但是你也知道很多代理都可以對 HTTPS 協(xié)議抓包，那 HTTPS 協(xié)議是如何防中間人竊聽的呢？還有，HTTPS 也可以雙向驗證，也就是服務(wù)器端可以驗證客戶端證書，這一點和防止中間人竊聽有沒有關(guān)系呢？本文就來回答這個問題，如果有不同意見，可以直接發(fā)消息與我交流。

HTTPS 協(xié)議的基本概念：HTTPS 協(xié)議是在 HTTP 協(xié)議的基礎(chǔ)上，通過添加 SSL/TLS 加密協(xié)議而成的。SSL/TLS 協(xié)議是一種用于網(wǎng)絡(luò)通信安全的加密協(xié)議，可以將數(shù)據(jù)在傳輸過程中進(jìn)行加密，保證數(shù)據(jù)的機(jī)密性和完整性。

如何防止中間人竊聽

要回答這個問題，我們先看看 HTTPS 協(xié)議雙方，也就是客戶端和服務(wù)器的通信過程。

1. 客戶端發(fā)送請求

當(dāng)用戶在瀏覽器中輸入一個 HTTPS 網(wǎng)址時，瀏覽器會向服務(wù)器發(fā)送一個請求，請求建立一個HTTPS 連接。請求中包含有客戶端支持的加密算法列表，當(dāng)然也包括客戶端自己的公鑰。

2. 服務(wù)器回應(yīng)

服務(wù)器會回應(yīng)客戶端的請求，并從中選擇一種加密算法。服務(wù)器會使用該算法生成一組密鑰，并將該密鑰用客戶端的公鑰加密，并將加密后的密鑰及數(shù)字證書發(fā)送給客戶端。

3. 客戶端驗證證書

客戶端收到服務(wù)器的回應(yīng)后，會驗證服務(wù)器的數(shù)字證書是否合法。數(shù)字證書是由數(shù)字證書認(rèn)證機(jī)構(gòu)（CA）頒發(fā)的，用于證明服務(wù)器的身份?？蛻舳藭鶕?jù)自己的信任列表，驗證數(shù)字證書的合法性。

驗證數(shù)字證書的過程如下：

• 客戶端（瀏覽器或 APP）讀取證書中的證書對應(yīng)的域名、所有者、有效期等信息進(jìn)行一一校驗；
• 客戶端開始查找操作系統(tǒng)中已內(nèi)置的受信任的證書發(fā)布機(jī)構(gòu) CA，與服務(wù)器發(fā)來的證書中的頒發(fā)者 CA 比對，用于校驗證書是否為合法機(jī)構(gòu)頒發(fā)；
• 如果找不到，客戶端就會報錯，說明服務(wù)器發(fā)來的證書是不可信任的；
• 如果找到，那么客戶端就會從操作系統(tǒng)中取出 頒發(fā)者 CA 的公鑰，然后對服務(wù)器發(fā)來的證書里面的簽名進(jìn)行解密；
• 客戶端使用相同的 hash 算法計算出服務(wù)器發(fā)來的證書的 hash 值，將這個計算的 hash 值與證書中簽名做對比；
• 對比結(jié)果一致，則證明服務(wù)器發(fā)來的證書合法，沒有被冒充；
• 此時客戶端就可以讀取證書中的公鑰，用于后續(xù)加密了；

4. 客戶端生成密鑰

如果數(shù)字證書驗證通過，客戶端會使用自己的私鑰解密服務(wù)器發(fā)送過來的密鑰。然后客戶端會使用該密鑰生成一對對稱密鑰，一份用于加密，一份用于解密。

5. 客戶端發(fā)送密鑰

客戶端使用服務(wù)器的公鑰加密剛剛生成的對稱密鑰，并將加密后的密鑰發(fā)送給服務(wù)器。

6. 服務(wù)器解密密鑰

服務(wù)器收到客戶端發(fā)送的加密后的對稱密鑰后，會使用自己的私鑰解密該密鑰。

7. 開始數(shù)據(jù)傳輸

經(jīng)過以上的驗證和加密，HTTPS 通信就建立了起來。此時，客戶端和服務(wù)器之間的數(shù)據(jù)傳輸都是通過對稱密鑰進(jìn)行加密的。為什么用對稱密鑰？因為對稱加密的開銷小，且其密鑰采用非對稱加密算法傳輸，通信過程非常安全。

理解了以上過程，你就會明白，防止中間人最重要最重要的過程是驗證證書，只要證書是合法的，服務(wù)器就是合法的，不會是冒充的。證書是專業(yè)的機(jī)構(gòu) CA 頒發(fā)和管理，所以是可信的。

假如，客戶端和服務(wù)器直接有一個中間人，比如你用了代理，那么這個代理就是中間人。中間人要想監(jiān)聽客戶端和服務(wù)器，就需要獲取客戶端和服務(wù)器的通信用的密鑰。服務(wù)器的密鑰，中間人可以作為客戶端的身份進(jìn)行獲取，但是要想獲取客戶端的密鑰，中間人需要偽裝服務(wù)器的身份，從而發(fā)布自己的證書，中間人的證書可以是自簽名證書，也可以是向 CA 申請的證書，無論是哪個證書，對應(yīng)的域名一定 不是服務(wù)器的域名，這樣，客戶端在驗證證書時一定不會通過，我們就會收到瀏覽器的提醒：證書不被信任。

如果，客戶端（你）選擇信任并繼續(xù)，那么你的通信將毫無安全可言。除非，這個代理（中間人）是你自己部署的，基于測試或抓包分析等其他原因，你可以信任并繼續(xù)。

回想一下，很多代理之所以可以抓取 HTTPS 包，是因為我們提前導(dǎo)入并信任它們的 CA 證書，然后就可以通過替換證書的方式進(jìn)行密鑰交換，以 charles 為例，具體過程如下：

圖片來源：https://ost.51cto.com/posts/19810

因此，HTTPS 協(xié)議是借助于證書防中間人竊聽的，請注意，如果自己從沒有做過什么代理設(shè)置，不要相信任何不受信任的證書，推而廣之，IOS 不要相信任何描述文件，不要安裝不明來源的 APP，不要賦予任何 APP 不需要的權(quán)限，這是保障自己信息安全的根本。

HTTPS 的雙向驗證

HTTPS 也可以雙向驗證，也就是服務(wù)器端可以驗證客戶端證書，那么什么場景需要這樣？

之前的過程，只能說明服務(wù)器是合法的，如果服務(wù)器想讓客戶端也是合法的，那么就需要驗證客戶端的證書，因此，如果服務(wù)端需要限定的客戶端才能訪問服務(wù)，那么可以采取 HTTPS 的雙向驗證[1]。因此 即使 HTTPS 不開啟雙向驗證，也可以防止中間人攻擊。

HTTPS 的雙向驗證 nginx 的配置示范如下：

location / {
    # 開啟 HTTPS 協(xié)議
    listen 443 ssl;
    # 指定 SSL 證書文件和私鑰文件
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    # 開啟證書校驗
    ssl_verify_client on;
    # 指定 CA 證書文件
    ssl_client_certificate /path/to/ca.pem;
    # 指定校驗方式為深度校驗
    ssl_verify_depth 2;
}

最后的話

HTTPS 協(xié)議通過使用 SSL/TLS 加密技術(shù)，通過證書檢驗，可以有效防止中間人竊聽、篡改和偽造等安全問題。

最后，請注意，當(dāng)瀏覽器或手機(jī)出現(xiàn)安全提醒時，一定不要添加信任并繼續(xù)，因為，詐騙犯/黑客正在暗處等著你，除非你真的知道你在做什么。