[[413391]]

圖片來自包圖網(wǎng)

我讀了那份通報，我直接炸開了，沒想到這次的瓜里，還有第三個人，它就是中間人劉某，具體怎么詐騙的呢?

整個詐騙過程可以概括成如下圖，下圖中的 ID_A 表示都某竹的銀行卡，ID_E 表示中間人劉某的銀行卡。

這個詐騙案牛逼在于，中間人劉某有雙重身份，不僅冒充都某竹的身份來向吳某凢索取賠償，而且又冒充吳某凢的身份騙都某竹把退款的錢轉(zhuǎn)到中間人劉某的銀行卡，從而獲取利益。

這波操作說實話比電影還精彩，劉某把中間人的角色演技到了極致，它做到了三件事情：

• 冒充身份，不僅冒充了都某竹的身份，而且冒充了吳某凢的身份。
• 篡改信息，騙都某竹把退款的錢，退到中間人劉某的銀行卡。
• 竊聽信息，因為冒充了身份，所以都某竹和吳某凢雙方的信息，劉某都牢牢的掌握在手中。

不知道大家有沒有察覺中間人劉某做的這三件事情，正是 HTTP 協(xié)議的安全風險?

HTTP 協(xié)議不僅傳輸?shù)男畔⑹敲魑模覜]有身份認證，所以存在竊聽風險、篡改風險、冒充風險。

為了解決 HTTP 協(xié)議的安全性，后面就出現(xiàn)了 HTTPS 協(xié)議，在 HTTP 層與 TCP 層之間加入了 TLS 協(xié)議，來保證安全可靠的信息傳輸。

具體怎么做到安全可靠的信息傳輸，這就涉及到了數(shù)字簽名和數(shù)字證書。沒想到吧，畫風突轉(zhuǎn)的很快吧。沒錯，今天這不是吃瓜文，而是技術文。

如何保證消息不被篡改?

為了保證傳輸?shù)膬?nèi)容不被篡改，我們需要對內(nèi)容計算出一個「指紋」，然后同內(nèi)容一起傳輸給對方。

對方收到后，先是對內(nèi)容也計算出一個「指紋」，然后跟發(fā)送方發(fā)送的「指紋」做一個比較，如果「指紋」相同，說明內(nèi)容沒有被篡改，否則就可以判斷出內(nèi)容被篡改了。

那么，在計算機里會用哈希函數(shù)來計算出內(nèi)容的哈希值，也就是內(nèi)容的「指紋」，這個哈希值是唯一的，且無法通過哈希值推導出內(nèi)容。

如何保證消息的來源可靠?

通過哈希算法可以確保內(nèi)容不會被篡改，但是并不能保證「內(nèi)容 + 哈希值」不會被中間人替換，因為這里缺少對客戶端收到的消息是否來源于服務端的證明。

舉個例子，你想向老師請假，一般來說是要求由家長寫一份請假理由并簽名，老師才能允許你請假。

但是你有模仿你爸爸字跡的能力，你用你爸爸的字跡寫了一份請假理由然后簽上你爸爸的名字，老師一看到這個請假條，查看字跡和簽名，就誤以為是你爸爸寫的，就會允許你請假。

那作為老師，要如何避免這種情況發(fā)生呢?現(xiàn)實生活中的，可以通過電話或視頻來確認是否是由父母發(fā)出的請假，但是計算機里可沒有這種操作。

那為了避免這種情況，計算機里會用非對稱加密算法來解決，共有兩個密鑰：

• 一個是公鑰，這個是可以公開給所有人的。
• 一個是私鑰，這個必須由本人管理，不可泄露。

這兩個密鑰可以雙向加解密的，比如可以用公鑰加密內(nèi)容，然后用私鑰解密，也可以用私鑰加密內(nèi)容，公鑰解密內(nèi)容。

流程的不同，意味著目的也不相同：

• 公鑰加密，私鑰解密。這個目的是為了保證內(nèi)容傳輸?shù)陌踩?，因為被公鑰加密的內(nèi)容，其他人是無法解密的，只有持有私鑰的人，才能解密出實際的內(nèi)容。
• 私鑰加密，公鑰解密。這個目的是為了保證消息不會被冒充，因為私鑰是不可泄露的，如果公鑰能正常解密出私鑰加密的內(nèi)容，就能證明這個消息是來源于持有私鑰身份的人發(fā)送的。

一般我們不會用非對稱加密來加密實際的傳輸內(nèi)容，因為非對稱加密的計算比較耗費性能的。

所以非對稱加密的用途主要在于通過「私鑰加密，公鑰解密」的方式，來確認消息的身份，我們常說的數(shù)字簽名算法，就是用的是這種方式，不過私鑰加密內(nèi)容不是內(nèi)容本身，而是對內(nèi)容的哈希值加密。

私鑰是由服務端保管，然后服務端會向客戶端頒發(fā)對應的公鑰。如果客戶端收到的信息，能被公鑰解密，就說明該消息是由服務器發(fā)送的。

引入了數(shù)字簽名算法后，你就無法模仿你爸爸的字跡來請假了，你爸爸手上持有著私鑰，你老師持有著公鑰。

這樣只有用你爸爸手上的私鑰才對請假條進行「簽名」，老師通過公鑰看能不能解出這個「簽名」，如果能解出并且確認內(nèi)容的完整性，就能證明是由你爸爸發(fā)起的請假條，這樣老師才允許你請假，否則老師就不認。

如果保證對方的身份?

前面我們知道：

• 可以通過哈希算法來保證消息的完整性。
• 可以通過數(shù)字簽名來保證消息的來源可靠性(能確認消息是由持有私鑰的一方發(fā)送的)。

但是這還遠遠不夠，還缺少身份驗證的環(huán)節(jié)，萬一公鑰是被偽造的呢?

還是拿請假的例子，雖然你爸爸持有私鑰，老師通過是否能用公鑰解密來確認這個請假條是不是來源你父親的。

但是我們還可以自己偽造出一對公私鑰啊!你找了個夜晚，偷偷把老師桌面上和你爸爸配對的公鑰，換成了你的公鑰，那么下次你在請假的時候，你繼續(xù)模仿你爸爸的字跡寫了個請假條，然后用你的私鑰做個了「數(shù)字簽名」。

但是老師并不知道自己的公鑰被你替換過了，所以他還是按照往常一樣用公鑰解密。

由于這個公鑰和你的私鑰是配對的，老師當然能用這個被替換的公鑰解密出來，并且確認了內(nèi)容的完整性，于是老師就會以為是你父親寫的請假條，又允許你請假了。

好家伙，為了一個請假，真的是斗智斗勇。后面你的老師和父親發(fā)現(xiàn)了你偽造公私鑰的事情后，決定重新商量一個對策來應對你這個臭家伙。

正所謂魔高一丈，道高一尺。既然偽造公私鑰那么隨意，所以你爸把他的公鑰注冊到警察局。

警察局用他們自己的私鑰對你父親的公鑰做了個數(shù)字簽名，然后把你爸爸的「個人信息 + 公鑰 + 數(shù)字簽名」打包成一個數(shù)字證書，也就是說這個數(shù)字證書包含你爸爸的公鑰。

這樣，你爸爸如果因為家里確實有事要向老師幫你請假的時候，不僅會用自己的私鑰對內(nèi)容進行簽名，還會把數(shù)字證書給到老師。

老師拿到了數(shù)字證書后，首先會去警察局驗證這個數(shù)字證書是否合法，因為數(shù)字證書里有警察局的數(shù)字簽名，警察局要驗證證書合法性的時候，用自己的公鑰解密。

如果能解密成功，就說明這個數(shù)字證書是在警察局注冊過的，就認為該數(shù)字證書是合法的，然后就會把數(shù)字證書里頭的公鑰(你爸爸的)給到老師。

由于通過警察局驗證了數(shù)字證書是合法的，那么就能證明這個公鑰就是你父親的，于是老師就可以安心的用這個公鑰解密出清教條，如果能解密出，就證明是你爸爸寫的請假條。

正是通過了一個權威的機構來證明你爸爸的身份，所以你的偽造公私鑰這個小伎倆就沒用了。

在計算機里，這個權威的機構就是 CA (數(shù)字證書認證機構)，將服務器公鑰放在數(shù)字證書(由數(shù)字證書認證機構頒發(fā))中，只要證書是可信的，公鑰就是可信的。

數(shù)字證書的工作流程，我也畫了一張圖，方便大家理解：

數(shù)子證書工作流程

①數(shù)字證書簽發(fā)和驗證流程

接下來，詳細說一下實際中數(shù)字證書簽發(fā)和驗證流程。

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

CA 簽發(fā)證書的過程，如上圖左邊部分：

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

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

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

②證書鏈

但事實上，證書的驗證過程中還存在一個證書信任鏈的問題，因為我們向 CA 申請的證書一般不是根證書簽發(fā)的，而是由中間證書簽發(fā)的，比如百度的證書，從下圖你可以看到，證書的層級有三級：

對于這種三級層級關系的證書的驗證過程如下：

客戶端收到 baidu.com 的證書后，發(fā)現(xiàn)這個證書的簽發(fā)者不是根證書，就無法根據(jù)本地已有的根證書中的公鑰去驗證 baidu.com 證書是否可信。

于是，客戶端根據(jù) baidu.com 證書中的簽發(fā)者，找到該證書的頒發(fā)機構是 “GlobalSign Organization Validation CA - SHA256 - G2”，然后向 CA 請求該中間證書。

請求到證書后發(fā)現(xiàn) “GlobalSign Organization Validation CA - SHA256 - G2” 證書是由 “GlobalSign Root CA” 簽發(fā)的，由于 “GlobalSign Root CA” 沒有再上級簽發(fā)機構，說明它是根證書，也就是自簽證書。

應用軟件會檢查此證書有否已預載于根證書清單上，如果有，則可以利用根證書中的公鑰去驗證 “GlobalSign Organization Validation CA - SHA256 - G2” 證書，如果發(fā)現(xiàn)驗證通過，就認為該中間證書是可信的。

“GlobalSign Organization Validation CA - SHA256 - G2” 證書被信任后，可以使用 “GlobalSign Organization Validation CA - SHA256 - G2” 證書中的公鑰去驗證 baidu.com 證書的可信性，如果驗證通過，就可以信任 baidu.com 證書。

在這四個步驟中，最開始客戶端只信任根證書 GlobalSign Root CA 證書的，然后 “GlobalSign Root CA” 證書信任 “GlobalSign Organization Validation CA - SHA256 - G2” 證書。

而 “GlobalSign Organization Validation CA - SHA256 - G2” 證書又信任 baidu.com 證書，于是客戶端也信任 baidu.com 證書。

總括來說，由于用戶信任 GlobalSign，所以由 GlobalSign 所擔保的 baidu.com 可以被信任，另外由于用戶信任操作系統(tǒng)或瀏覽器的軟件商，所以由軟件商預載了根證書的 GlobalSign 都可被信任。

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

這樣的一層層地驗證就構成了一條信任鏈路，整個證書信任鏈驗證流程如下圖所示：

最后一個問題，為什么需要證書鏈這么麻煩的流程?Root CA 為什么不直接頒發(fā)證書，而是要搞那么多中間層級呢?

這是為了確保根證書的絕對安全性，將根證書隔離地越嚴格越好，不然根證書如果失守了，那么整個信任鏈都會有問題。

作者：小林

編輯：陶家龍

出處：轉(zhuǎn)載自公眾號小林 coding(ID：CodingLin)