大家好,我是小林,
上周吳某凢和都某竹的瓜大家都吃了吧,結果前幾天北京朝陽警方通報了這是一個金錢詐騙案,
我讀了那份通報,我直接炸開了,沒想到這次的瓜里,還有第三個人,它就是中間人劉某,具體怎么詐騙的呢?
整個詐騙程序可以概括成如下圖,下圖中的 ID_A 表示都某竹的銀行卡,ID_E 表示中間人劉某的銀行卡,

這個詐騙案牛逼在于,中間人劉某有雙重身份,不僅冒充都某竹的身份來向吳某凢索取賠償,而且又冒充吳某凢的身份騙都某竹把退款的錢轉到中間人劉某的銀行卡,從而獲取利益,
這波操作說實話比電影還精彩,劉某把中間人的角色演技到了極致,它做到了三件事情:
- 冒充身份,不僅冒充了都某竹的身份,而且冒充了吳某凢的身份;
- 篡改資訊,騙都某竹把退款的錢,退到中間人劉某的銀行卡;
- 竊聽資訊,因為冒充了身份,所以都某竹和吳某凢雙方的資訊,劉某都牢牢的掌握在手中,
不知道大家有沒有察覺中間人劉某做的這三件事情,正是 HTTP 協議的安全風險?
HTTP 協議不僅傳輸的資訊是明文,而且沒有身份認證,所以存在竊聽風險、篡改風險、冒充風險,
為了解決 HTTP 協議的安全性,后面就出現了 HTTPS 協議,在 HTTP 層與 TCP 層之間加入了 TLS 協議,來保證安全可靠的資訊傳輸,

具體怎么做到安全可靠的資訊傳輸,這就涉及到了數字簽名和數字證書,
沒想到吧,畫風突轉的很快吧,
沒錯,今天這不是吃瓜文,而是技術文,讓大家在吃瓜中學習,小林真是煞費苦心,
先說個事,我在 csdn 寫了很多圖解網路的文章,質量非常高,幫助到了很多同學,每次面試他們被問到網路,一點都不慌,不少同學去了位元組、騰訊、阿里等一線大廠,
然后問把我的 15 萬字的圖解系列文章整理成了 PDF ,主要是為了方便閱讀,現在開源給大家:15萬字的圖解網路開放下載(點擊瞧一瞧)
如何保證訊息不被篡改?
為了保證傳輸的內容不被篡改,我們需要對內容計算出一個「指紋」,然后同內容一起傳輸給對方,
對方收到后,先是對內容也計算出一個「指紋」,然后跟發送方發送的「指紋」做一個比較,如果「指紋」相同,說明內容沒有被篡改,否則就可以判斷出內容被篡改了,
那么,在計算機里會用哈希函式來計算出內容的哈希值,也就是內容的「指紋」,這個哈希值是唯一的,且無法通過哈希值推匯出內容,

如何保證訊息的來源可靠?
通過哈希演算法可以確保內容不會被篡改,但是并不能保證「內容 + 哈希值」不會被中間人替換,因為這里缺少對客戶端收到的訊息是否來源于服務端的證明,
舉個例子,你想向老師請假,一般來說是要求由家長寫一份請假理由并簽名,老師才能允許你請假,
但是你有模仿你爸爸字跡的能力,你用你爸爸的字跡寫了一份請假理由然后簽上你爸爸的名字,老師一看到這個請假條,查看字跡和簽名,就誤以為是你爸爸寫的,就會允許你請假,
那作為老師,要如何避免這種情況發生呢?現實生活中的,可以通過電話或視頻來確認是否是由父母發出的請假,但是計算機里可沒有這種操作,
那為了避免這種情況,計算機里會用非對稱加密演算法來解決,共有兩個密鑰:
- 一個是公鑰,這個是可以公開給所有人的;
- 一個是私鑰,這個必須由本人管理,不可泄露,
這兩個密鑰可以雙向加解密的,比如可以用公鑰加密內容,然后用私鑰解密,也可以用私鑰加密內容,公鑰解密內容,
流程的不同,意味著目的也不相同:
- 公鑰加密,私鑰解密,這個目的是為了保證內容傳輸的安全,因為被公鑰加密的內容,其他人是無法解密的,只有持有私鑰的人,才能解密出實際的內容;
- 私鑰加密,公鑰解密,這個目的是為了保證訊息不會被冒充,因為私鑰是不可泄露的,如果公鑰能正常解密出私鑰加密的內容,就能證明這個訊息是來源于持有私鑰身份的人發送的,
一般我們不會用非對稱加密來加密實際的傳輸內容,因為非對稱加密的計算比較耗費性能的,
所以非對稱加密的用途主要在于通過「私鑰加密,公鑰解密」的方式,來確認訊息的身份,我們常說的數字簽名演算法,就是用的是這種方式,不過私鑰加密內容不是內容本身,而是對內容的哈希值加密,

私鑰是由服務端保管,然后服務端會向客戶端頒發對應的公鑰,如果客戶端收到的資訊,能被公鑰解密,就說明該訊息是由服務器發送的,
引入了數字簽名演算法后,你就無法模仿你爸爸的字跡來請假了,你爸爸手上持有著私鑰,你老師持有著公鑰,
這樣只有用你爸爸手上的私鑰才對請假條進行「簽名」,老師通過公鑰看能不能解出這個「簽名」,如果能解出并且確認內容的完整性,就能證明是由你爸爸發起的請假條,這樣老師才允許你請假,否則老師就不認,
如果保證對方的身份?
前面我們知道:
- 可以通過哈希演算法來保證訊息的完整性;
- 可以通過數字簽名來保證訊息的來源可靠性(能確認訊息是由持有私鑰的一方發送的);
但是這還遠遠不夠,還缺少身份驗證的環節,萬一公鑰是被偽造的呢?
還是拿請假的例子,雖然你爸爸持有私鑰,老師通過是否能用公鑰解密來確認這個請假條是不是來源你父親的,
但是我們還可以自己偽造出一對公私鑰啊!
你找了個夜晚,偷偷把老師桌面上和你爸爸配對的公鑰,換成了你的公鑰,那么下次你在請假的時候,你繼續模仿你爸爸的字跡寫了個請假條,然后用你的私鑰做個了「數字簽名」,
但是老師并不知道自己的公鑰被你替換過了,所以他還是按照往常一樣用公鑰解密,由于這個公鑰和你的私鑰是配對的,老師當然能用這個被替換的公鑰解密出來,并且確認了內容的完整性,于是老師就會以為是你父親寫的請假條,又允許你請假了,
好家伙,為了一個請假,真的是斗智斗勇,
后面你的老師和父親發現了你偽造公私鑰的事情后,決定重新商量一個對策來應對你這個臭家伙,
正所謂魔高一丈,道高一尺,
既然偽造公私鑰那么隨意,所以你爸把他的公鑰注冊
到警察局,警察局用他們自己的私鑰對你父親的公鑰做了個數字簽名,然后把你爸爸的「個人資訊 + 公鑰 + 數字簽名」打包成一個數字證書,也就是說這個數字證書包含你爸爸的公鑰,
這樣,你爸爸如果因為家里確實有事要向老師幫你請假的時候,不僅會用自己的私鑰對內容進行簽名,還會把數字證書給到老師,
老師拿到了數字證書后,首先會去警察局驗證這個數字證書是否合法,因為數字證書里有警察局的數字簽名,警察局要驗證證書合法性的時候,用自己的公鑰解密,如果能解密成功,就說明這個數字證書是在警察局注冊過的,就認為該數字證書是合法的,然后就會把數字證書里頭的公鑰(你爸爸的)給到老師,
由于通過警察局驗證了數字證書是合法的,那么就能證明這個公鑰就是你父親的,于是老師就可以安心的用這個公鑰解密出清教條,如果能解密出,就證明是你爸爸寫的請假條,
正是通過了一個權威的機構來證明你爸爸的身份,所以你的偽造公私鑰這個小伎倆就沒用了,
在計算機里,這個權威的機構就是 CA (數字證書認證機構),將服務器公鑰放在數字證書(由數字證書認證機構頒發)中,只要證書是可信的,公鑰就是可信的,
數字證書的作業流程,我也畫了一張圖,方便大家理解:

數字證書簽發和驗證流程
接下來,詳細說一下實際中數字證書簽發和驗證流程,
如下圖圖所示,為數字證書簽發和驗證流程:

CA 簽發證書的程序,如上圖左邊部分:
- 首先 CA 會把持有者的公鑰、用途、頒發者、有效時間等資訊打成一個包,然后對這些資訊進行 Hash 計算,得到一個 Hash 值;
- 然后 CA 會使用自己的私鑰將該 Hash 值加密,生成 Certificate Signature,也就是 CA 對證書做了簽名;
- 最后將 Certificate Signature 添加在檔案證書上,形成數字證書;
客戶端校驗服務端的數字證書的程序,如上圖右邊部分:
- 首先客戶端會使用同樣的 Hash 演算法獲取該證書的 Hash 值 H1;
- 通常瀏覽器和作業系統中集成了 CA 的公鑰資訊,瀏覽器收到證書后可以使用 CA 的公鑰解密 Certificate Signature 內容,得到一個 Hash 值 H2 ;
- 最后比較 H1 和 H2,如果值相同,則為可信賴的證書,否則則認為證書不可信,
證書鏈
但事實上,證書的驗證程序中還存在一個證書信任鏈的問題,因為我們向 CA 申請的證書一般不是根證書簽發的,而是由中間證書簽發的,比如百度的證書,從下圖你可以看到,證書的層級有三級:

對于這種三級層級關系的證書的驗證程序如下:
- 客戶端收到 baidu.com 的證書后,發現這個證書的簽發者不是根證書,就無法根據本地已有的根證書中的公鑰去驗證 baidu.com 證書是否可信,于是,客戶端根據 baidu.com 證書中的簽發者,找到該證書的頒發機構是 “GlobalSign Organization Validation CA - SHA256 - G2”,然后向 CA 請求該中間證書,
- 請求到證書后發現 “GlobalSign Organization Validation CA - SHA256 - G2” 證書是由 “GlobalSign Root CA” 簽發的,由于 “GlobalSign Root CA” 沒有再上級簽發機構,說明它是根證書,也就是自簽證書,應用軟體會檢查此證書有否已預載于根證書清單上,如果有,則可以利用根證書中的公鑰去驗證 “GlobalSign Organization Validation CA - SHA256 - G2” 證書,如果發現驗證通過,就認為該中間證書是可信的,
- “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 可以被信任,另外由于用戶信任作業系統或瀏覽器的軟體商,所以由軟體商預載了根證書的 GlobalSign 都可被信任,

作業系統里一般都會內置一些根證書,比如我的 MAC 電腦里內置的根證書有這么多:

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

最后一個問題,為什么需要證書鏈這么麻煩的流程?Root CA 為什么不直接頒發證書,而是要搞那么多中間層級呢?
這是為了確保根證書的絕對安全性,將根證書隔離地越嚴格越好,不然根證書如果失守了,那么整個信任鏈都會有問題,
本次分享沒有談到 HTTPS 握手程序,因為我之前寫過很詳細的 HTTPS 協議的 TLS 握手流程,想深入學習的同學,可以看看這兩篇:
- 圖解 | HTTPS - RSA 握手程序
- 圖解 | HTTPS - ECDHE 握手程序
絮叨絮叨
小林在 CSDN 寫了很多圖解網路和作業系統的系列文章,很高興識訓到很朋友的認可和支持,正好最近圖解網路和作業系統的文章連載的有 20+ 篇了,也算有個體系了,

所以為了方便大家閱讀,小林把自己原創的圖解網路和圖解作業系統整理成了 PDF,一整理后,沒想到每個圖解都輸出了 15 萬字 + 500 張圖,質量也是杠杠的,有很多朋友特地私信我,看了我的圖解拿到了大廠的offer,
圖解系統 PDF 開源下載:圖解系統 PDF 下載地址(點擊)
圖解網路 PDF 開源下載:圖解網路 PDF 下載地址(點擊)
最后,這瓜你覺得甜嗎?
我們下次見啦,
轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/290319.html
標籤:其他
下一篇:從家里到阿里,學弟求職的一年
