主頁 > 軟體設計 > 吳某凢 300 萬詐騙案的瓜,程式員應該怎么吃?

吳某凢 300 萬詐騙案的瓜,程式員應該怎么吃?

2021-07-27 08:04:47 軟體設計

大家好,我是小林,

上周吳某凢和都某竹的瓜大家都吃了吧,結果前幾天北京朝陽警方通報了這是一個金錢詐騙案,

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

整個詐騙程序可以概括成如下圖,下圖中的 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

標籤:其他

上一篇:前端:運用js制作一個隨機點名的程式

下一篇:從家里到阿里,學弟求職的一年

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 面試突擊第一季,第二季,第三季

    第一季必考 https://www.bilibili.com/video/BV1FE411y79Y?from=search&seid=15921726601957489746 第二季分布式 https://www.bilibili.com/video/BV13f4y127ee/?spm_id_fro ......

    uj5u.com 2020-09-10 05:35:24 more
  • 第三單元作業總結

    1.前言 這應該是本學期最后一次寫作業總結了吧。總體來說,對作業的節奏也差不多掌握了,作業做起來的效率也更高了。雖然和之前的作業一樣,作業中都要用到新的知識,但是相比之前,更加懂得了如何利用工具以及資料。雖然之間卡過殼,但總體而言,這幾次作業還算完成的比較好。 2.作業程序總結 相比前兩個單元,此單 ......

    uj5u.com 2020-09-10 05:35:41 more
  • 北航OO(2020)第四單元博客作業暨課程總結博客

    北航OO(2020)第四單元博客作業暨課程總結博客 本單元作業的架構設計 在本單元中,由于UML圖具有比較清晰的樹形結構,因此我對其中需要進行查詢操作的元素進行了包裝,在樹的父節點中存盤所有孩子的參考。考慮到性能問題,我采用了快取機制,一次查詢后盡可能快取已經遍歷過的資訊,以減少遍歷次數。 本單元我 ......

    uj5u.com 2020-09-10 05:35:48 more
  • BUAA_OO_第四單元

    一、UML決議器設計 ? 先看下題目:第四單元實作一個基于JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖,順序圖,狀態圖分析器 MyUmlInteraction,實際上我們要建立一個有向圖模型,UML中的物件(元素)可能與同級元素連接,也可與低級元素相連形成 ......

    uj5u.com 2020-09-10 05:35:54 more
  • 6.1邏輯運算子

    邏輯運算子 1. && 短路與 運算式1 && 運算式2 01.運算式1為true并且運算式2也為true 整體回傳為true 02.運算式1為false,將不會執行運算式2 整體回傳為false 03.只要有一個運算式為false 整體回傳為false 2. || 短路或 運算式1 || 運算式2 ......

    uj5u.com 2020-09-10 05:35:56 more
  • BUAAOO 第四單元 & 課程總結

    1. 第四單元:StarUml檔案決議 本單元采用了圖模型決議UML。 UML檔案可以抽象為圖、子圖、邊的邏輯結構。 在實作中,圖的節點包括類、介面、屬性,子圖包括狀態圖、順序圖等。 采用了三次遍歷UML元素的方法建圖,第一遍遍歷建點,第二、三次遍歷設定屬性、連邊,實作圖物件的初始化。這里借鑒了一些 ......

    uj5u.com 2020-09-10 05:36:06 more
  • 談談我對C# 多型的理解

    面向物件三要素:封裝、繼承、多型。 封裝和繼承,這兩個比較好理解,但要理解多型的話,可就稍微有點難度了。今天,我們就來講講多型的理解。 我們應該經常會看到面試題目:請談談對多型的理解。 其實呢,多型非常簡單,就一句話:呼叫同一種方法產生了不同的結果。 具體實作方式有三種。 一、多載 多載很簡單。 p ......

    uj5u.com 2020-09-10 05:36:09 more
  • Python 資料驅動工具:DDT

    背景 python 的unittest 沒有自帶資料驅動功能。 所以如果使用unittest,同時又想使用資料驅動,那么就可以使用DDT來完成。 DDT是 “Data-Driven Tests”的縮寫。 資料:http://ddt.readthedocs.io/en/latest/ 使用方法 dd. ......

    uj5u.com 2020-09-10 05:36:13 more
  • Python里面的xlrd模塊詳解

    那我就一下面積個問題對xlrd模塊進行學習一下: 1.什么是xlrd模塊? 2.為什么使用xlrd模塊? 3.怎樣使用xlrd模塊? 1.什么是xlrd模塊? ?python操作excel主要用到xlrd和xlwt這兩個庫,即xlrd是讀excel,xlwt是寫excel的庫。 今天就先來說一下xl ......

    uj5u.com 2020-09-10 05:36:28 more
  • 當我們創建HashMap時,底層到底做了什么?

    jdk1.7中的底層實作程序(底層基于陣列+鏈表) 在我們new HashMap()時,底層創建了默認長度為16的一維陣列Entry[ ] table。當我們呼叫map.put(key1,value1)方法向HashMap里添加資料的時候: 首先,呼叫key1所在類的hashCode()計算key1 ......

    uj5u.com 2020-09-10 05:36:38 more
最新发布
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:20:47 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:20:25 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:20:17 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:20:10 more
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:19:44 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:19:07 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:18:57 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:18:49 more
  • 05單件模式

    #經典的單件模式 public class Singleton { private static Singleton uniqueInstance; //一個靜態變數持有Singleton類的唯一實體。 // 其他有用的實體變數寫在這里 //構造器宣告為私有,只有Singleton可以實體化這個類! ......

    uj5u.com 2023-04-19 08:42:51 more
  • 【架構與設計】常見微服務分層架構的區別和落地實踐

    軟體工程的方方面面都遵循一個最基本的道理:沒有銀彈,架構分層模型更是如此,每一種都有各自優缺點,所以請根據不同的業務場景,并遵循簡單、可演進這兩個重要的架構原則選擇合適的架構分層模型即可。 ......

    uj5u.com 2023-04-19 08:42:41 more