圖文講解 HTTPS 的原理

轉(zhuǎn)自 |?碼海

1. HTTP 為什么不安全
2. 安全通信的四大原則
3. HTTPS 通信原理簡(jiǎn)述

• 對(duì)稱(chēng)加密
• 數(shù)字證書(shū)
• 非對(duì)稱(chēng)加密
• 數(shù)字簽名

HTTP 為什么不安全

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

1、 竊聽(tīng)風(fēng)險(xiǎn)

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

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

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

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

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

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

安全通信的四大原則

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

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

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

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

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

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

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

對(duì)稱(chēng)加密具有加解密速度快，性能高的特點(diǎn)，也是 HTTPS 最終采用的加密形式，但是這里有一個(gè)關(guān)鍵問(wèn)題，對(duì)稱(chēng)加密的通信雙方要使用同一把密鑰，這個(gè)密鑰是如何協(xié)商出來(lái)的？如果通過(guò)報(bào)文的方式直接傳輸密鑰，之后的通信其實(shí)還是在裸奔，因?yàn)檫@個(gè)密鑰會(huì)被中間人截獲甚至替換掉，這樣中間人就可以用截獲的密鑰解密報(bào)文，甚至替換掉密鑰以達(dá)到篡改報(bào)文的目的。

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

非對(duì)稱(chēng)加密：解決單向?qū)ΨQ(chēng)密鑰的傳輸問(wèn)題

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

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

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

這樣的話(huà)對(duì)于 server 來(lái)說(shuō)，保管好私鑰，發(fā)布公鑰給其他 client, 其他 client 只要把對(duì)稱(chēng)加密的密鑰加密傳給 server 即可，如此一來(lái)由于公鑰加密只有私鑰能解密，而私鑰只有 server 有，所以能保證 client 向 server 傳輸是安全的，server 解密后即可拿到對(duì)稱(chēng)加密密鑰，這樣交換了密鑰之后就可以用對(duì)稱(chēng)加密密鑰通信了。

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

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

如何解決公鑰傳輸問(wèn)題呢，從現(xiàn)實(shí)生活中的場(chǎng)景找答案，員工入職時(shí)，企業(yè)一般會(huì)要求提供學(xué)歷證明，顯然不是什么阿貓阿狗的本本都可稱(chēng)為學(xué)歷，這個(gè)學(xué)歷必須由第三方權(quán)威機(jī)構(gòu)（Certificate Authority，簡(jiǎn)稱(chēng) CA）即教育部頒發(fā)，同理，server 也可以向 CA 申請(qǐng)證書(shū)，在證書(shū)中附上公鑰，然后將證書(shū)傳給 client，證書(shū)由站點(diǎn)管理者向 CA 申請(qǐng)，申請(qǐng)的時(shí)候會(huì)提交 DNS 主機(jī)名等信息，CA 會(huì)根據(jù)這些信息生成證書(shū)

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

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

想象一下上文中我們提到的學(xué)歷，企業(yè)如何認(rèn)定你提供的學(xué)歷證書(shū)是真是假呢，答案是用學(xué)歷編號(hào)，企業(yè)拿到證書(shū)后用學(xué)歷編號(hào)在學(xué)信網(wǎng)上一查就知道證書(shū)真?zhèn)瘟耍瑢W(xué)歷編號(hào)其實(shí)就是我們常說(shuō)的數(shù)字簽名，可以防止證書(shū)造假。

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

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

消息摘要是把任意長(zhǎng)度的輸入揉和而產(chǎn)生長(zhǎng)度固定的偽隨機(jī)輸入的算法，無(wú)論輸入的消息有多長(zhǎng)，計(jì)算出來(lái)的消息摘要的長(zhǎng)度總是固定的，一般來(lái)說(shuō)，只要內(nèi)容不同，產(chǎn)生的摘要必然不同（相同的概率可以認(rèn)為接近于 0），所以可以驗(yàn)證內(nèi)容是否被篡改了。

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

因?yàn)槭褂梅菍?duì)稱(chēng)加密是非常耗時(shí)的，如果把整個(gè)證書(shū)內(nèi)容都加密生成簽名的話(huà)，客戶(hù)端驗(yàn)驗(yàn)簽也需要把簽名解密，證書(shū)明文較長(zhǎng)，客戶(hù)端驗(yàn)簽就需要很長(zhǎng)的時(shí)間，而用摘要的話(huà)，會(huì)把內(nèi)容很長(zhǎng)的明文壓縮成小得多的定長(zhǎng)字符串，客戶(hù)端驗(yàn)簽的話(huà)就會(huì)快得多。

2、客戶(hù)端拿到證書(shū)后也用同樣的摘要算法對(duì)證書(shū)明文計(jì)算摘要，兩者一筆對(duì)就可以發(fā)現(xiàn)報(bào)文是否被篡改了，那為啥要用第三方權(quán)威機(jī)構(gòu)（Certificate Authority，簡(jiǎn)稱(chēng) CA）私鑰對(duì)摘要加密呢，因?yàn)檎惴ㄊ枪_(kāi)的，中間人可以替換掉證書(shū)明文，再根據(jù)證書(shū)上的摘要算法計(jì)算出摘要后把證書(shū)上的摘要也給替換掉！這樣 client 拿到證書(shū)后計(jì)算摘要發(fā)現(xiàn)一樣，誤以為此證書(shū)是合法就中招了。所以必須要用 CA 的私鑰給摘要進(jìn)行加密生成簽名，這樣的話(huà) client 得用 CA 的公鑰來(lái)給簽名解密，拿到的才是未經(jīng)篡改合法的摘要（私鑰簽名，公鑰才能解密）

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

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

細(xì)心的你一定發(fā)現(xiàn)了問(wèn)題，CA 公鑰如何安全地傳輸?shù)?client ？如果還是從 server 傳輸?shù)?client，依然無(wú)法解決公鑰被調(diào)包的風(fēng)險(xiǎn)，實(shí)際上此公鑰是存在于 CA 證書(shū)上，而此證書(shū)（也稱(chēng) Root CA 證書(shū)）被操作系統(tǒng)信任，內(nèi)置在操作系統(tǒng)上的，無(wú)需傳輸，如果用的是 ?Mac 的同學(xué)，可以打開(kāi) keychain 查看一下，可以看到很多內(nèi)置的被信任的證書(shū)。

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

問(wèn)題二、 如何防止證書(shū)被調(diào)包

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

正常站點(diǎn)和中間人都可以向 CA 申請(qǐng)證書(shū)，獲得認(rèn)證的證書(shū)由于都是 CA 頒發(fā)的，所以都是合法的，那么此時(shí)中間人是否可以在傳輸過(guò)程中將正常站點(diǎn)發(fā)給 client 的證書(shū)替換成自己的證書(shū)呢，如下所示

答案是不行，因?yàn)榭蛻?hù)端除了通過(guò)驗(yàn)簽的方式驗(yàn)證證書(shū)是否合法之外，還需要驗(yàn)證證書(shū)上的域名與自己的請(qǐng)求域名是否一致，中間人中途雖然可以替換自己向 CA 申請(qǐng)的合法證書(shū)，但此證書(shū)中的域名與 client 請(qǐng)求的域名不一致，client 會(huì)認(rèn)定為不通過(guò)！

但是上面的證書(shū)調(diào)包給了我們一種思路，什么思路？大家想想， ?HTTPS 既然是加密的， charles 這些「中間人」為啥能抓到明文的包呢，其實(shí)就是用了證書(shū)調(diào)包這一手法，想想看，在用 charles 抓 HTTPS 的包之前我們先要做什么，當(dāng)然是安裝 charles 的證書(shū)

這個(gè)證書(shū)里有 charles 的公鑰，這樣的話(huà) charles 就可以將 server 傳給 client 的證書(shū)調(diào)包成自己的證書(shū)，client 拿到后就可以用你安裝的 charles ?證書(shū)來(lái)驗(yàn)簽等，驗(yàn)證通過(guò)之后就會(huì)用 charles 證書(shū)中的公鑰來(lái)加密對(duì)稱(chēng)密鑰了，整個(gè)流程如下

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

其它 HTTPS 相關(guān)問(wèn)題

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

以上的講述過(guò)程中，我們只是在 client 端驗(yàn)證了 server 傳輸證書(shū)的合法性，但 server 如何驗(yàn)證 client 的合法性，還是用證書(shū)，我們?cè)诰W(wǎng)上進(jìn)行轉(zhuǎn)賬等操作時(shí)，想想看是不是要先將銀行發(fā)給我們的 U 盾插到電腦上？其實(shí)也是因?yàn)?U 盾內(nèi)置了證書(shū)，通信時(shí)將證書(shū)發(fā)給 server，server 驗(yàn)證通過(guò)之后即可開(kāi)始通信。

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

什么是證書(shū)信任鏈

前文說(shuō)了，我們可以向 CA 申請(qǐng)證書(shū)，但全世界的頂級(jí) CA（Root CA） 就那么幾個(gè)，每天都有很多人要向它申請(qǐng)證書(shū)，它也忙不過(guò)來(lái)啊，怎么辦呢，想想看在一個(gè)公司里如果大家都找 CEO 辦事，他是不是要瘋了，那他能怎么辦？授權(quán)，他會(huì)把權(quán)力交給 CTO，CFO 等，這樣你們只要找 CTO 之類(lèi)的就行了，CTO 如果也忙不過(guò)來(lái)呢，繼續(xù)往下授權(quán)啊。

同樣的，既然頂級(jí) CA 忙不過(guò)來(lái)，那它就向下一級(jí)，下下級(jí) CA 授權(quán)即可，這樣我們就只要找一級(jí)/二級(jí)/三級(jí) CA 申請(qǐng)證書(shū)即可。怎么證明這些證書(shū)被 Root CA 授權(quán)過(guò)了呢，小一點(diǎn)的 CA 可以讓大一點(diǎn)的 CA 來(lái)簽名認(rèn)證，比如一級(jí) CA 讓 Root CA 來(lái)簽名認(rèn)證，二級(jí) CA 讓一級(jí) CA 來(lái)簽名認(rèn)證,Root CA 沒(méi)有人給他簽名認(rèn)證，只能自己證明自己了，這個(gè)證書(shū)就叫「自簽名證書(shū)」或者「根證書(shū)」，我們必須信任它，不然證書(shū)信任鏈?zhǔn)亲卟幌氯サ模ㄟ@個(gè)根證書(shū)前文我們提過(guò)，其實(shí)是內(nèi)置在操作系統(tǒng)中的）

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

1. 瀏覽器就使用信任的根證書(shū)（根公鑰）解析證書(shū)鏈的根證書(shū)得到一級(jí)證書(shū)的公鑰+摘要驗(yàn)簽
2. 拿一級(jí)證書(shū)的公鑰解密一級(jí)證書(shū)，拿到二級(jí)證書(shū)的公鑰和摘要驗(yàn)簽
3. 再然后拿二級(jí)證書(shū)的公鑰解密 server 傳過(guò)來(lái)的二級(jí)證書(shū)，得到服務(wù)器的公鑰和摘要驗(yàn)簽，驗(yàn)證過(guò)程就結(jié)束了

總結(jié)

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

而 SSL/TLS 的功能其實(shí)本質(zhì)上是如何協(xié)商出安全的對(duì)稱(chēng)加密密鑰以利用此密鑰進(jìn)行后續(xù)通訊的過(guò)程，帶著這個(gè)疑問(wèn)相信你不難理解數(shù)字證書(shū)和數(shù)字簽名這兩個(gè)讓人費(fèi)解的含義，搞懂了這些也就明白了為啥 ?HTTPS 是加密的，charles 這些工具卻能抓包出明文來(lái)。

巨人的肩膀

• https://juejin.cn/post/6844903958863937550

• https://showme.codes/2017-02-20/understand-https/

• 極客時(shí)間，透視 HTTP 協(xié)議

• https://zhuanlan.zhihu.com/p/67199487