[[355627]]

前言

近年來各大公司對(duì)信息安全傳輸越來越重視，也逐步把網(wǎng)站升級(jí)到 HTTPS 了，那么大家知道 HTTPS 的原理是怎樣的嗎，到底是它是如何確保信息安全傳輸?shù)?網(wǎng)上挺多介紹 HTTPS，但我發(fā)現(xiàn)總是或多或少有些點(diǎn)有些遺漏，沒有講全，今天試圖由淺入深地把 HTTPS 講明白，相信大家看完一定能掌握 HTTPS 的原理，本文大綱如下：

1.HTTP 為什么不安全

2.安全通信的四大原則

3.HTTPS 通信原理簡述

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

4.其它 HTTPS 相關(guān)問題

HTTP 為什么不安全

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

1、 竊聽風(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è)釣魚網(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 通信原理簡述

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

既然 HTTP 是明文傳輸?shù)?，那我們給報(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，簡稱 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)瘟耍瑢W(xué)歷編號(hào)其實(shí)就是我們常說的數(shù)字簽名，可以防止證書造假。

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

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

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

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

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

2、客戶端拿到證書后也用同樣的摘要算法對(duì)證書明文計(jì)算摘要，兩者一筆對(duì)就可以發(fā)現(xiàn)報(bào)文是否被篡改了，那為啥要用第三方權(quán)威機(jī)構(gòu)(Certificate Authority，簡稱 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 這些工具卻能抓包出明文來。

巨人的肩膀

https://juejin.cn/post/6844903958863937550

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

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

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

本文轉(zhuǎn)載自微信公眾號(hào)「碼?！梗梢酝ㄟ^以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系碼海公眾號(hào)。