[[357317]]

圖片來自 Pexels

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

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

本文大綱如下：

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

HTTP 為什么不安全

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

①竊聽風(fēng)險

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

②篡改風(fēng)險

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

③冒充風(fēng)險

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

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

安全通信的四大原則

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

如下：

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

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

HTTPS 通信原理簡述

對稱加密：HTTPS 的最終加密形式

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

如圖示：使用對稱加密的通信雙方使用同一把密鑰進行加解密。

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

如果通過報文的方式直接傳輸密鑰，之后的通信其實還是在裸奔，因為這個密鑰會被中間人截獲甚至替換掉，這樣中間人就可以用截獲的密鑰解密報文，甚至替換掉密鑰以達到篡改報文的目的。

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

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

直接傳輸密鑰無論從哪一端傳從上節(jié)分析來看是不行了，這里我們再看另一種加密方式：非對稱加密。

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

注：私鑰加密其實這個說法其實并不嚴謹，準確的說私鑰加密應(yīng)該叫私鑰簽名，因為私密加密的信息公鑰是可以解密的，而公鑰是公開的，任何人都可以拿到，用公鑰解密叫做驗簽。

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

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

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

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

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

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

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

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

問題一：如何驗證證書的真實性，如何防止證書被篡改

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

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

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

步驟如下：

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

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

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

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

因為使用非對稱加密是非常耗時的，如果把整個證書內(nèi)容都加密生成簽名的話，客戶端驗驗簽也需要把簽名解密，證書明文較長，客戶端驗簽就需要很長的時間。

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

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

因為摘要算法是公開的，中間人可以替換掉證書明文，再根據(jù)證書上的摘要算法計算出摘要后把證書上的摘要也給替換掉!

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

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

server 將證書傳給 client 后，client 的驗簽過程如下：

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

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

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

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

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

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

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

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

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

如下所示：

答案是不行，因為客戶端除了通過驗簽的方式驗證證書是否合法之外，還需要驗證證書上的域名與自己的請求域名是否一致。

中間人中途雖然可以替換自己向 CA 申請的合法證書，但此證書中的域名與 client 請求的域名不一致，client 會認定為不通過!

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

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

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

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

整個流程如下：

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

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

什么是雙向認證

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

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

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

什么是證書信任鏈

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

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

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

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

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

比如一級 CA 讓 Root CA 來簽名認證，二級 CA 讓一級 CA 來簽名認證，Root CA 沒有人給他簽名認證，只能自己證明自己了。

這個證書就叫「自簽名證書」或者「根證書」，我們必須信任它，不然證書信任鏈是走不下去的(這個根證書前文我們提過，其實是內(nèi)置在操作系統(tǒng)中的)。

證書信任鏈

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

這樣客戶端會按如下步驟進行驗證：

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

總結(jié)

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

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

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

作者：碼海

編輯：陶家龍

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