[[357317]]

圖片來自 Pexels

網(wǎng)上挺多介紹 HTTPS，但我發(fā)現(xiàn)總是或多或少有些點(diǎn)有些遺漏，沒有講全。

今天試圖由淺入深地把 HTTPS 講明白，相信大家看完一定能掌握 HTTPS 的原理。

本文大綱如下：

• HTTP 為什么不安全
• 安全通信的四大原則
• HTTPS 通信原理簡(jiǎn)述
• 其他 HTTPS 相關(guān)問題

HTTP 為什么不安全

HTTP 由于是明文傳輸，主要存在三大風(fēng)險(xiǎn)。

①竊聽風(fēng)險(xiǎn)

中間人可以獲取到通信內(nèi)容，由于內(nèi)容是明文，所以獲取明文后有安全風(fēng)險(xiǎn)。

②篡改風(fēng)險(xiǎn)

中間人可以篡改報(bào)文內(nèi)容后再發(fā)送給對(duì)方，風(fēng)險(xiǎn)極大。

③冒充風(fēng)險(xiǎn)

比如你以為是在和某寶通信，但實(shí)際上是在和一個(gè)釣魚網(wǎng)站通信。

HTTPS 顯然是為了解決這三大風(fēng)險(xiǎn)而存在的，接下來我們看看 HTTPS 到底解決了什么問題。

安全通信的四大原則

看了上一節(jié)，不難猜到 HTTPS 就是為了解決上述三個(gè)風(fēng)險(xiǎn)而生的，一般我們認(rèn)為安全的通信需要包括以下四個(gè)原則: 機(jī)密性、完整性，身份認(rèn)證和不可否認(rèn)。

如下：

• 機(jī)密性：即對(duì)數(shù)據(jù)加密，解決了竊聽風(fēng)險(xiǎn)，因?yàn)榧词贡恢虚g人竊聽，由于數(shù)據(jù)是加密的，他也拿不到明文。
• 完整性：指數(shù)據(jù)在傳輸過程中沒有被篡改，不多不少，保持原樣，中途如果哪怕改了一個(gè)標(biāo)點(diǎn)符號(hào)，接收方也能識(shí)別出來，從來判定接收?qǐng)?bào)文不合法。
• 身份認(rèn)證：確認(rèn)對(duì)方的真實(shí)身份，即證明「你媽是你媽」的問題，這樣就解決了冒充風(fēng)險(xiǎn)，用戶不用擔(dān)心訪問的是某寶結(jié)果卻在和釣魚網(wǎng)站通信的問題。
• 不可否認(rèn): 即不可否認(rèn)已發(fā)生的行為，比如小明向小紅借了 1000 元，但沒打借條，或者打了借條但沒有簽名，就會(huì)造成小紅的資金損失。

接下來我們一步步來看看 HTTPS 是如何實(shí)現(xiàn)以滿足以上四大安全通信原則的。

HTTPS 通信原理簡(jiǎn)述

對(duì)稱加密：HTTPS 的最終加密形式

既然 HTTP 是明文傳輸?shù)模俏覀兘o報(bào)文加密不就行了，既然要加密，我們肯定需要通信雙方協(xié)商好密鑰吧，一種是通信雙方使用同一把密鑰，即對(duì)稱加密的方式來給報(bào)文進(jìn)行加解密。

如圖示：使用對(duì)稱加密的通信雙方使用同一把密鑰進(jìn)行加解密。

對(duì)稱加密具有加解密速度快，性能高的特點(diǎn)，也是 HTTPS 最終采用的加密形式，但是這里有一個(gè)關(guān)鍵問題，對(duì)稱加密的通信雙方要使用同一把密鑰，這個(gè)密鑰是如何協(xié)商出來的?

如果通過報(bào)文的方式直接傳輸密鑰，之后的通信其實(shí)還是在裸奔，因?yàn)檫@個(gè)密鑰會(huì)被中間人截獲甚至替換掉，這樣中間人就可以用截獲的密鑰解密報(bào)文，甚至替換掉密鑰以達(dá)到篡改報(bào)文的目的。

有人說對(duì)這個(gè)密鑰加密不就完了，但對(duì)方如果要解密這個(gè)密鑰還是要傳加密密鑰給對(duì)方，依然還是會(huì)被中間人截獲的，這么看來直接傳輸密鑰無論怎樣都無法擺脫俄羅斯套娃的難題，是不可行的。

非對(duì)稱加密：解決單向?qū)ΨQ密鑰傳輸問題

直接傳輸密鑰無論從哪一端傳從上節(jié)分析來看是不行了，這里我們?cè)倏戳硪环N加密方式：非對(duì)稱加密。

非對(duì)稱加密即加解密雙方使用不同的密鑰，一把作為公鑰，可以公開的，一把作為私鑰，不能公開，公鑰加密的密文只有私鑰可以解密，私鑰加密的內(nèi)容，也只有公鑰可以解密。

注：私鑰加密其實(shí)這個(gè)說法其實(shí)并不嚴(yán)謹(jǐn)，準(zhǔn)確的說私鑰加密應(yīng)該叫私鑰簽名，因?yàn)樗矫芗用艿男畔⒐€是可以解密的，而公鑰是公開的，任何人都可以拿到，用公鑰解密叫做驗(yàn)簽。

這樣的話對(duì)于 server 來說，保管好私鑰，發(fā)布公鑰給其他 client，其他 client 只要把對(duì)稱加密的密鑰加密傳給 server 即可。

如此一來由于公鑰加密只有私鑰能解密，而私鑰只有 server 有，所以能保證 client 向 server 傳輸是安全的，server 解密后即可拿到對(duì)稱加密密鑰，這樣交換了密鑰之后就可以用對(duì)稱加密密鑰通信了。

但是問題又來了， server 怎么把公鑰安全地傳輸給 client 呢。如果直接傳公鑰，也會(huì)存在被中間人調(diào)包的風(fēng)險(xiǎn)。

數(shù)字證書，解決公鑰傳輸信任問題

如何解決公鑰傳輸問題呢，從現(xiàn)實(shí)生活中的場(chǎng)景找答案，員工入職時(shí)，企業(yè)一般會(huì)要求提供學(xué)歷證明。

顯然不是什么阿貓阿狗的本本都可稱為學(xué)歷，這個(gè)學(xué)歷必須由第三方權(quán)威機(jī)構(gòu)(Certificate Authority，簡(jiǎn)稱 CA)即教育部頒發(fā)。

同理，server 也可以向 CA 申請(qǐng)證書，在證書中附上公鑰，然后將證書傳給 client，證書由站點(diǎn)管理者向 CA 申請(qǐng)，申請(qǐng)的時(shí)候會(huì)提交 DNS 主機(jī)名等信息，CA 會(huì)根據(jù)這些信息生成證書。

這樣當(dāng) client 拿到證書后，就可以獲得證書上的公鑰，再用此公鑰加密對(duì)稱加密密鑰傳給 server 即可，看起來確實(shí)很完美，不過在這里大家要考慮兩個(gè)問題。

問題一：如何驗(yàn)證證書的真實(shí)性，如何防止證書被篡改

想象一下上文中我們提到的學(xué)歷，企業(yè)如何認(rèn)定你提供的學(xué)歷證書是真是假呢?

答案是用學(xué)歷編號(hào)，企業(yè)拿到證書后用學(xué)歷編號(hào)在學(xué)信網(wǎng)上一查就知道證書真?zhèn)瘟?，學(xué)歷編號(hào)其實(shí)就是我們常說的數(shù)字簽名，可以防止證書造假。

回到 HTTPS 上，證書的數(shù)字簽名該如何產(chǎn)生的呢，一圖勝千言：

步驟如下：

①首先使用一些摘要算法(如 MD5)將證書明文(如證書序列號(hào)，DNS主機(jī)名等)生成摘要，然后再用第三方權(quán)威機(jī)構(gòu)的私鑰對(duì)生成的摘要進(jìn)行加密(簽名)。

消息摘要是把任意長(zhǎng)度的輸入揉和而產(chǎn)生長(zhǎng)度固定的偽隨機(jī)輸入的算法，無論輸入的消息有多長(zhǎng)，計(jì)算出來的消息摘要的長(zhǎng)度總是固定的。

一般來說，只要內(nèi)容不同，產(chǎn)生的摘要必然不同(相同的概率可以認(rèn)為接近于 0)，所以可以驗(yàn)證內(nèi)容是否被篡改了。

為啥要先生成摘要再加密呢，不能直接加密?

因?yàn)槭褂梅菍?duì)稱加密是非常耗時(shí)的，如果把整個(gè)證書內(nèi)容都加密生成簽名的話，客戶端驗(yàn)驗(yàn)簽也需要把簽名解密，證書明文較長(zhǎng)，客戶端驗(yàn)簽就需要很長(zhǎng)的時(shí)間。

而用摘要的話，會(huì)把內(nèi)容很長(zhǎng)的明文壓縮成小得多的定長(zhǎng)字符串，客戶端驗(yàn)簽的話就會(huì)快得多。

②客戶端拿到證書后也用同樣的摘要算法對(duì)證書明文計(jì)算摘要，兩者一筆對(duì)就可以發(fā)現(xiàn)報(bào)文是否被篡改了，那為啥要用第三方權(quán)威機(jī)構(gòu)(Certificate Authority，簡(jiǎn)稱 CA)私鑰對(duì)摘要加密?

因?yàn)檎惴ㄊ枪_的，中間人可以替換掉證書明文，再根據(jù)證書上的摘要算法計(jì)算出摘要后把證書上的摘要也給替換掉!

這樣 client 拿到證書后計(jì)算摘要發(fā)現(xiàn)一樣，誤以為此證書是合法就中招了。

所以必須要用 CA 的私鑰給摘要進(jìn)行加密生成簽名，這樣的話 client 得用 CA 的公鑰來給簽名解密，拿到的才是未經(jīng)篡改合法的摘要(私鑰簽名，公鑰才能解密)。

server 將證書傳給 client 后，client 的驗(yàn)簽過程如下：

這樣的話，由于只有 CA 的公鑰才能解密簽名，如果客戶端收到一個(gè)假的證書，使用 CA 的公鑰是無法解密的，如果客戶端收到了真的證書，但證書上的內(nèi)容被篡改了，摘要比對(duì)不成功的話，客戶端也會(huì)認(rèn)定此證書非法。

細(xì)心的你一定發(fā)現(xiàn)了問題，CA 公鑰如何安全地傳輸?shù)?client?如果還是從 server 傳輸?shù)?client，依然無法解決公鑰被調(diào)包的風(fēng)險(xiǎn)。

實(shí)際上此公鑰是存在于 CA 證書上，而此證書(也稱 Root CA 證書)被操作系統(tǒng)信任，內(nèi)置在操作系統(tǒng)上的，無需傳輸。

如果用的是 Mac 的同學(xué)，可以打開 keychain 查看一下，可以看到很多內(nèi)置的被信任的證書。

server 傳輸 CA 頒發(fā)的證書，客戶中收到證書后使用內(nèi)置 CA 證書中的公鑰來解密簽名，驗(yàn)簽即可，這樣的話就解決了公鑰傳輸過程中被調(diào)包的風(fēng)險(xiǎn)。

問題二：如何防止證書被調(diào)包

實(shí)際上任何站點(diǎn)都可以向第三方權(quán)威機(jī)構(gòu)申請(qǐng)證書，中間人也不例外。

正常站點(diǎn)和中間人都可以向 CA 申請(qǐng)證書，獲得認(rèn)證的證書由于都是 CA 頒發(fā)的，所以都是合法的。

那么此時(shí)中間人是否可以在傳輸過程中將正常站點(diǎn)發(fā)給 client 的證書替換成自己的證書呢?

如下所示：

答案是不行，因?yàn)榭蛻舳顺送ㄟ^驗(yàn)簽的方式驗(yàn)證證書是否合法之外，還需要驗(yàn)證證書上的域名與自己的請(qǐng)求域名是否一致。

中間人中途雖然可以替換自己向 CA 申請(qǐng)的合法證書，但此證書中的域名與 client 請(qǐng)求的域名不一致，client 會(huì)認(rèn)定為不通過!

但是上面的證書調(diào)包給了我們一種思路，什么思路?大家想想，HTTPS 既然是加密的，charles 這些「中間人」為啥能抓到明文的包呢，其實(shí)就是用了證書調(diào)包這一手法。

想想看，在用 charles 抓 HTTPS 的包之前我們先要做什么，當(dāng)然是安裝 charles 的證書：

這個(gè)證書里有 charles 的公鑰，這樣的話 charles 就可以將 server 傳給 client 的證書調(diào)包成自己的證書。

client 拿到后就可以用你安裝的 charles 證書來驗(yàn)簽等，驗(yàn)證通過之后就會(huì)用 charles 證書中的公鑰來加密對(duì)稱密鑰了。

整個(gè)流程如下：

由此可知，charles 這些中間人能抓取 HTTPS 包的前提是信任它們的 CA 證書，然后就可以通過替換證書的方式進(jìn)行瞞天過海，所以我們千萬不要隨便信任第三方的證書，避免安全風(fēng)險(xiǎn)。

其他 HTTPS 相關(guān)問題

什么是雙向認(rèn)證

以上的講述過程中，我們只是在 client 端驗(yàn)證了 server 傳輸證書的合法性，但 server 如何驗(yàn)證 client 的合法性，還是用證書，我們?cè)诰W(wǎng)上進(jìn)行轉(zhuǎn)賬等操作時(shí)，想想看是不是要先將銀行發(fā)給我們的 U 盾插到電腦上?

其實(shí)也是因?yàn)?U 盾內(nèi)置了證書，通信時(shí)將證書發(fā)給 server，server 驗(yàn)證通過之后即可開始通信。

畫外音：身份認(rèn)證只是 U 盾功能的一種，還有其他功能，比如加解密都是在 U 盾中執(zhí)行，保證了密鑰不會(huì)出現(xiàn)在內(nèi)存中

什么是證書信任鏈

前文說了，我們可以向 CA 申請(qǐng)證書，但全世界的頂級(jí) CA(Root CA) 就那么幾個(gè)，每天都有很多人要向它申請(qǐng)證書，它也忙不過來啊，怎么辦呢?

想想看在一個(gè)公司里如果大家都找 CEO 辦事，他是不是要瘋了，那他能怎么辦?

授權(quán)，他會(huì)把權(quán)力交給 CTO，CFO 等，這樣你們只要把 CTO 之類的就行了，CTO 如果也忙不過來呢，繼續(xù)往下授權(quán)啊。

同樣的，既然頂級(jí) CA 忙不過來，那它就向下一級(jí)，下下級(jí) CA 授權(quán)即可，這樣我們就只要找一級(jí)/二級(jí)/三級(jí) CA 申請(qǐng)證書即可。

怎么證明這些證書被 Root CA 授權(quán)過了呢，小一點(diǎn)的 CA 可以讓大一點(diǎn)的 CA 來簽名認(rèn)證。

比如一級(jí) CA 讓 Root CA 來簽名認(rèn)證，二級(jí) CA 讓一級(jí) CA 來簽名認(rèn)證，Root CA 沒有人給他簽名認(rèn)證，只能自己證明自己了。

這個(gè)證書就叫「自簽名證書」或者「根證書」，我們必須信任它，不然證書信任鏈?zhǔn)亲卟幌氯サ?這個(gè)根證書前文我們提過，其實(shí)是內(nèi)置在操作系統(tǒng)中的)。

證書信任鏈

現(xiàn)在我們看看如果站點(diǎn)申請(qǐng)的是二級(jí) CA 頒發(fā)的證書，client 收到之后會(huì)如何驗(yàn)證這個(gè)證書呢，實(shí)際上 service 傳了傳給二級(jí) CA 的證書外，還會(huì)把證書信任鏈也一起傳給客戶端。

這樣客戶端會(huì)按如下步驟進(jìn)行驗(yàn)證：

• 瀏覽器就使用信任的根證書(根公鑰)解析證書鏈的根證書得到一級(jí)證書的公鑰+摘要驗(yàn)簽。
• 拿一級(jí)證書的公鑰解密一級(jí)證書，拿到二級(jí)證書的公鑰和摘要驗(yàn)簽。
• 再然后拿二級(jí)證書的公鑰解密 server 傳過來的二級(jí)證書，得到服務(wù)器的公鑰和摘要驗(yàn)簽，驗(yàn)證過程就結(jié)束了。

總結(jié)

相信大家看完本文應(yīng)該對(duì) HTTPS 的原理有了很清楚的認(rèn)識(shí)了，HTTPS 無非就是 HTTP+SSL/TLS。

而 SSL/TLS 的功能其實(shí)本質(zhì)上是如何協(xié)商出安全的對(duì)稱加密密鑰以利用此密鑰進(jìn)行后續(xù)通訊的過程，帶著這個(gè)疑問相信你不難理解數(shù)字證書和數(shù)字簽名這兩個(gè)讓人費(fèi)解的含義。

搞懂了這些也就明白了為啥 HTTPS 是加密的，charles 這些工具卻能抓包出明文來。

作者：碼海

編輯：陶家龍

出處：轉(zhuǎn)載自公眾號(hào)碼海(ID：seaofcode)