大家好，我是小林。

上周有位讀者在面字節(jié)時(shí)被問(wèn)道這么一個(gè)問(wèn)題：HTTPS 一定安全可靠嗎？

這個(gè)問(wèn)題的場(chǎng)景是這樣的：客戶端通過(guò)瀏覽器向服務(wù)端發(fā)起 HTTPS 請(qǐng)求時(shí)，被「假基站」轉(zhuǎn)發(fā)到了一個(gè)「中間人服務(wù)器」，于是客戶端是和「中間人服務(wù)器」完成了 TLS 握手，然后這個(gè)「中間人服務(wù)器」再與真正的服務(wù)端完成 TLS 握手。

具體過(guò)程如下：

• 客戶端向服務(wù)端發(fā)起 HTTPS 建立連接請(qǐng)求時(shí)，然后被「假基站」轉(zhuǎn)發(fā)到了一個(gè)「中間人服務(wù)器」，接著中間人向服務(wù)端發(fā)起 HTTPS 建立連接請(qǐng)求，此時(shí)客戶端與中間人進(jìn)行 TLS 握手，中間人與服務(wù)端進(jìn)行 TLS 握手；
• 在客戶端與中間人進(jìn)行 TLS 握手過(guò)程中，中間人會(huì)發(fā)送自己的公鑰證書給客戶端，客戶端驗(yàn)證證書的真?zhèn)危缓髲淖C書拿到公鑰，并生成一個(gè)隨機(jī)數(shù)，用公鑰加密隨機(jī)數(shù)發(fā)送給中間人，中間人使用私鑰解密，得到隨機(jī)數(shù)，此時(shí)雙方都有隨機(jī)數(shù)，然后通過(guò)算法生成對(duì)稱加密密鑰（A），后續(xù)客戶端與中間人通信就用這個(gè)對(duì)稱加密密鑰來(lái)加密數(shù)據(jù)了。
• 在中間人與服務(wù)端進(jìn)行 TLS 握手過(guò)程中，服務(wù)端會(huì)發(fā)送從 CA 機(jī)構(gòu)簽發(fā)的公鑰證書給中間人，從證書拿到公鑰，并生成一個(gè)隨機(jī)數(shù)，用公鑰加密隨機(jī)數(shù)發(fā)送給服務(wù)端，服務(wù)端使用私鑰解密，得到隨機(jī)數(shù)，此時(shí)雙方都有隨機(jī)數(shù)，然后通過(guò)算法生成對(duì)稱加密密鑰（B），后續(xù)中間人與服務(wù)端通信就用這個(gè)對(duì)稱加密密鑰來(lái)加密數(shù)據(jù)了。
• 后續(xù)的通信過(guò)程中，中間人用對(duì)稱加密密鑰（A）解密客戶端的 HTTPS 請(qǐng)求的數(shù)據(jù)，然后用對(duì)稱加密密鑰（B）加密 HTTPS 請(qǐng)求后，轉(zhuǎn)發(fā)給服務(wù)端，接著服務(wù)端發(fā)送 HTTPS 響應(yīng)數(shù)據(jù)給中間人，中間人用對(duì)稱加密密鑰（B）解密 HTTPS 響應(yīng)數(shù)據(jù)，然后再用對(duì)稱加密密鑰（A）加密后，轉(zhuǎn)發(fā)給客戶端。

從客戶端的角度看，其實(shí)并不知道網(wǎng)絡(luò)中存在中間人服務(wù)器這個(gè)角色。

那么中間人就可以解開瀏覽器發(fā)起的 HTTPS 請(qǐng)求里的數(shù)據(jù)，也可以解開服務(wù)端響應(yīng)給瀏覽器的 HTTPS 響應(yīng)數(shù)據(jù)。相當(dāng)于，中間人能夠 “偷看” 瀏覽器與服務(wù)端之間的 HTTPS 請(qǐng)求和響應(yīng)的數(shù)據(jù)。

但是要發(fā)生這種場(chǎng)景是有前提的，前提是用戶點(diǎn)擊接受了中間人服務(wù)器的證書。

中間人服務(wù)器與客戶端在 TLS 握手過(guò)程中，實(shí)際上發(fā)送了自己偽造的證書給瀏覽器，而這個(gè)偽造的證書是能被瀏覽器（客戶端）識(shí)別出是非法的，于是就會(huì)提醒用戶該證書存在問(wèn)題。

如果用戶執(zhí)意點(diǎn)擊「繼續(xù)瀏覽此網(wǎng)站」，相當(dāng)于用戶接受了中間人偽造的證書，那么后續(xù)整個(gè) HTTPS 通信都能被中間人監(jiān)聽(tīng)了。

所以，這其實(shí)并不能說(shuō) HTTPS 不夠安全，畢竟瀏覽器都已經(jīng)提示證書有問(wèn)題了，如果用戶堅(jiān)決要訪問(wèn)，那不能怪 HTTPS ，得怪自己手賤。

客戶端是如何驗(yàn)證證書的？

接下來(lái)，詳細(xì)說(shuō)一下實(shí)際中數(shù)字證書簽發(fā)和驗(yàn)證流程。

如下圖圖所示，為數(shù)字證書簽發(fā)和驗(yàn)證流程：

當(dāng)服務(wù)端向 CA 機(jī)構(gòu)申請(qǐng)證書的時(shí)候，CA 簽發(fā)證書的過(guò)程，如上圖左邊部分：

• 首先 CA 會(huì)把持有者的公鑰、用途、頒發(fā)者、有效時(shí)間等信息打成一個(gè)包，然后對(duì)這些信息進(jìn)行 Hash 計(jì)算，得到一個(gè) Hash 值；
• 然后 CA 會(huì)使用自己的私鑰將該 Hash 值加密，生成 Certificate Signature，也就是 CA 對(duì)證書做了簽名；
• 最后將 Certificate Signature 添加在文件證書上，形成數(shù)字證書；

客戶端校驗(yàn)服務(wù)端的數(shù)字證書的過(guò)程，如上圖右邊部分：

• 首先客戶端會(huì)使用同樣的 Hash 算法獲取該證書的 Hash 值 H1；
• 通常瀏覽器和操作系統(tǒng)中集成了 CA 的公鑰信息，瀏覽器收到證書后可以使用 CA 的公鑰解密 Certificate Signature 內(nèi)容，得到一個(gè) Hash 值 H2 ；
• 最后比較 H1 和 H2，如果值相同，則為可信賴的證書，否則則認(rèn)為證書不可信。

但事實(shí)上，證書的驗(yàn)證過(guò)程中還存在一個(gè)證書信任鏈的問(wèn)題，因?yàn)槲覀兿?CA 申請(qǐng)的證書一般不是根證書簽發(fā)的，而是由中間證書簽發(fā)的，比如百度的證書，從下圖你可以看到，證書的層級(jí)有三級(jí)：

對(duì)于這種三級(jí)層級(jí)關(guān)系的證書的驗(yàn)證過(guò)程如下：

• 客戶端收到 baidu.com 的證書后，發(fā)現(xiàn)這個(gè)證書的簽發(fā)者不是根證書，就無(wú)法根據(jù)本地已有的根證書中的公鑰去驗(yàn)證 baidu.com 證書是否可信。于是，客戶端根據(jù) baidu.com 證書中的簽發(fā)者，找到該證書的頒發(fā)機(jī)構(gòu)是 “GlobalSign Organization Validation CA - SHA256 - G2”，然后向 CA 請(qǐng)求該中間證書。
• 請(qǐng)求到證書后發(fā)現(xiàn) “GlobalSign Organization Validation CA - SHA256 - G2” 證書是由 “GlobalSign Root CA” 簽發(fā)的，由于 “GlobalSign Root CA” 沒(méi)有再上級(jí)簽發(fā)機(jī)構(gòu)，說(shuō)明它是根證書，也就是自簽證書。應(yīng)用軟件會(huì)檢查此證書有否已預(yù)載于根證書清單上，如果有，則可以利用根證書中的公鑰去驗(yàn)證 “GlobalSign Organization Validation CA - SHA256 - G2” 證書，如果發(fā)現(xiàn)驗(yàn)證通過(guò)，就認(rèn)為該中間證書是可信的。
• “GlobalSign Organization Validation CA - SHA256 - G2” 證書被信任后，可以使用 “GlobalSign Organization Validation CA - SHA256 - G2” 證書中的公鑰去驗(yàn)證 baidu.com 證書的可信性，如果驗(yàn)證通過(guò)，就可以信任 baidu.com 證書。

在這四個(gè)步驟中，最開始客戶端只信任根證書 GlobalSign Root CA 證書的，然后 “GlobalSign Root CA” 證書信任 “GlobalSign Organization Validation CA - SHA256 - G2” 證書，而 “GlobalSign Organization Validation CA - SHA256 - G2” 證書又信任 baidu.com 證書，于是客戶端也信任 baidu.com 證書?？偫▉?lái)說(shuō)，由于用戶信任 GlobalSign，所以由 GlobalSign 所擔(dān)保的 baidu.com 可以被信任，另外由于用戶信任操作系統(tǒng)或?yàn)g覽器的軟件商，所以由軟件商預(yù)載了根證書的 GlobalSign 都可被信任。

操作系統(tǒng)里一般都會(huì)內(nèi)置一些根證書，比如我的 MAC 電腦里內(nèi)置的根證書有這么多：

這樣的一層層地驗(yàn)證就構(gòu)成了一條信任鏈路，整個(gè)證書信任鏈驗(yàn)證流程如下圖所示：

如果你的電腦中毒了，被惡意導(dǎo)入了中間人的根證書，那么在驗(yàn)證中間人的證書的時(shí)候，由于你操作系統(tǒng)信任了中間人的根證書，那么等同于中間人的證書是合法的。

這種情況下，瀏覽器是不會(huì)彈出證書存在問(wèn)題的風(fēng)險(xiǎn)提醒的。

這其實(shí)也不關(guān) HTTPS 的事情，是你電腦中毒了才導(dǎo)致 HTTPS 數(shù)據(jù)被中間人劫持的。

所以，HTTPS 協(xié)議本身到目前為止還是沒(méi)有任何漏洞的，即使你成功進(jìn)行中間人攻擊，本質(zhì)上是利用了客戶端的漏洞（用戶點(diǎn)擊繼續(xù)訪問(wèn)或者被惡意導(dǎo)入偽造的根證書），并不是 HTTPS 不夠安全。

為什么抓包工具能截取 HTTPS 數(shù)據(jù)？

抓包工具 Fiddler 之所以可以明文看到 HTTPS 數(shù)據(jù)，工作原理與中間人一致的。

對(duì)于 HTTPS 連接來(lái)說(shuō)，中間人要滿足以下兩點(diǎn)，才能實(shí)現(xiàn)真正的明文代理:

• 中間人，作為客戶端與真實(shí)服務(wù)端建立連接這一步不會(huì)有問(wèn)題，因?yàn)榉?wù)端不會(huì)校驗(yàn)客戶端的身份；
• 中間人，作為服務(wù)端與真實(shí)客戶端建立連接，這里會(huì)有客戶端信任服務(wù)端的問(wèn)題，也就是服務(wù)端必須有對(duì)應(yīng)域名的私鑰；

中間人要拿到私鑰只能通過(guò)如下方式：

• 去網(wǎng)站服務(wù)端拿到私鑰；
• 去CA處拿域名簽發(fā)私鑰；
• 自己簽發(fā)證書，切要被瀏覽器信任；

不用解釋，抓包工具只能使用第三種方式取得中間人的身份。

使用抓包工具進(jìn)行 HTTPS 抓包的時(shí)候，需要在客戶端安裝 Fiddler 的根證書，這里實(shí)際上起認(rèn)證中心（CA）的作用。

Fiddler 能夠抓包的關(guān)鍵是客戶端會(huì)往系統(tǒng)受信任的根證書列表中導(dǎo)入 Fiddler 生成的證書，而這個(gè)證書會(huì)被瀏覽器信任，也就是 Fiddler 給自己創(chuàng)建了一個(gè)認(rèn)證中心 CA。

客戶端拿著中間人簽發(fā)的證書去中間人自己的 CA 去認(rèn)證，當(dāng)然認(rèn)為這個(gè)證書是有效的。

如何避免被中間人抓取數(shù)據(jù)？

我們要保證自己電腦的安全，不要被病毒乘虛而入，而且也不要點(diǎn)擊任何證書非法的網(wǎng)站，這樣 HTTPS 數(shù)據(jù)就不會(huì)被中間人截取到了。

當(dāng)然，我們還可以通過(guò) HTTPS 雙向認(rèn)證來(lái)避免這種問(wèn)題。

一般我們的 HTTPS 是單向認(rèn)證，客戶端只會(huì)驗(yàn)證了服務(wù)端的身份，但是服務(wù)端并不會(huì)驗(yàn)證客戶端的身份。

如果用了雙向認(rèn)證方式，不僅客戶端會(huì)驗(yàn)證服務(wù)端的身份，而且服務(wù)端也會(huì)驗(yàn)證客戶端的身份。

服務(wù)端一旦驗(yàn)證到請(qǐng)求自己的客戶端為不可信任的，服務(wù)端就拒絕繼續(xù)通信，客戶端如果發(fā)現(xiàn)服務(wù)端為不可信任的，那么也中止通信。