當(dāng)前位置:首頁 > 公眾號(hào)精選 > 小林coding
[導(dǎo)讀]我很早之前寫過一篇關(guān)于 HTTP 和 HTTPS 的文章,但對(duì)于 HTTPS 介紹還不夠詳細(xì),只講了比較基礎(chǔ)的部分,所以這次我們?cè)賮砩钊胍幌?HTTPS,用 實(shí)戰(zhàn)抓包的方式,帶大家再來窺探一次 HTTPS。

我很早之前寫過一篇關(guān)于 HTTP 和 HTTPS 的文章,但對(duì)于 HTTPS 介紹還不夠詳細(xì),只講了比較基礎(chǔ)的部分,所以這次我們?cè)賮砩钊胍幌?HTTPS,用 實(shí)戰(zhàn)抓包的方式,帶大家再來窺探一次 HTTPS。

對(duì)于還不知道對(duì)稱加密和非對(duì)稱加密的同學(xué),你先復(fù)習(xí)我以前的這篇文章「硬核!30 張圖解 HTTP 常見的面試題」,本篇文章默認(rèn)大家已經(jīng)具備了這些知識(shí)。


TLS 握手過程

HTTP 由于是明文傳輸,所謂的明文,就是說客戶端與服務(wù)端通信的信息都是肉眼可見的,隨意使用一個(gè)抓包工具都可以截獲通信的內(nèi)容。

所以安全上存在以下三個(gè)風(fēng)險(xiǎn):

  • 竊聽風(fēng)險(xiǎn),比如通信鏈路上可以獲取通信內(nèi)容,用戶號(hào)容易沒。

  • 篡改風(fēng)險(xiǎn),比如強(qiáng)制植入垃圾廣告,視覺污染,用戶眼容易瞎。

  • 冒充風(fēng)險(xiǎn),比如冒充淘寶網(wǎng)站,用戶錢容易沒。

HTTPS 在 HTTP 與 TCP 層之間加入了 TLS 協(xié)議,來解決上述的風(fēng)險(xiǎn)。

TLS 協(xié)議是如何解決 HTTP 的風(fēng)險(xiǎn)的呢?

  • 信息加密:HTTP 交互信息是被加密的,第三方就無法被竊??;

  • 校驗(yàn)機(jī)制:校驗(yàn)信息傳輸過程中是否有被第三方篡改過,如果被篡改過,則會(huì)有警告提示;

  • 身份證書:證明淘寶是真的淘寶網(wǎng);

可見,有了 TLS 協(xié)議,能保證 HTTP 通信是安全的了,那么在進(jìn)行 HTTP 通信前,需要先進(jìn)行 TLS 握手。TLS 的握手過程,如下圖:

上圖簡要概述來 TLS 的握手過程,其中每一個(gè)「框」都是一個(gè)記錄(record),記錄是 TLS 收發(fā)數(shù)據(jù)的基本單位,類似于 TCP 里的 segment。多個(gè)記錄可以組合成一個(gè) TCP 包發(fā)送,所以通常經(jīng)過「四個(gè)消息」就可以完成 TLS 握手,也就是需要 2個(gè) RTT 的時(shí)延,然后就可以在安全的通信環(huán)境里發(fā)送 HTTP 報(bào)文,實(shí)現(xiàn) HTTPS 協(xié)議。

所以可以發(fā)現(xiàn),HTTPS 是應(yīng)用層協(xié)議,需要先完成 TCP 連接建立,然后走 TLS 握手過程后,才能建立通信安全的連接。

事實(shí)上,不同的密鑰交換算法,TLS 的握手過程可能會(huì)有一些區(qū)別。

這里先簡單介紹下密鑰交換算法,因?yàn)榭紤]到性能的問題,所以雙方在加密應(yīng)用信息時(shí)使用的是對(duì)稱加密密鑰,而對(duì)稱加密密鑰是不能被泄漏的,為了保證對(duì)稱加密密鑰的安全性,所以使用非對(duì)稱加密的方式來保護(hù)對(duì)稱加密密鑰的協(xié)商,這個(gè)工作就是密鑰交換算法負(fù)責(zé)的。

接下來,我們就以最簡單的 RSA密鑰交換算法,來看看它的 TLS 握手過程。


RSA 握手過程

傳統(tǒng)的 TLS 握手基本都是使用 RSA 算法來實(shí)現(xiàn)密鑰交換的,在將 TLS 證書部署服務(wù)端時(shí),證書文件中包含一對(duì)公私鑰,其中公鑰會(huì)在 TLS 握手階段傳遞給客戶端,私鑰則一直留在服務(wù)端,一定要確保私鑰不能被竊取。

在 RSA 密鑰協(xié)商算法中,客戶端會(huì)生成隨機(jī)密鑰,并使用服務(wù)端的公鑰加密后再傳給服務(wù)端。根據(jù)非對(duì)稱加密算法,公鑰加密的消息僅能通過私鑰解密,這樣服務(wù)端解密后,雙方就得到了相同的密鑰,再用它加密應(yīng)用消息。

我用 Wireshark 工具抓了用 RSA 密鑰交換的 TLS 握手過程,你可以從下面看到,一共經(jīng)歷來四次握手:





對(duì)應(yīng) Wireshark 的抓包,我也畫了一幅圖,你可以從下圖很清晰地看到該過程:

那么,接下來針對(duì)每一個(gè) TLS 握手做進(jìn)一步的介紹。

TLS 第一次握手

客戶端首先會(huì)發(fā)一個(gè)「Client Hello」消息,字面意思我們也能理解到,這是跟服務(wù)器「打招呼」。

消息里面有客戶端使用的 TLS 版本號(hào)、支持的密碼套件列表,以及生成的隨機(jī)數(shù)(Client Random,這個(gè)隨機(jī)數(shù)會(huì)被服務(wù)端保留,它是生成對(duì)稱加密密鑰的材料之一。

TLS 第二次握手

當(dāng)服務(wù)端收到客戶端的「Client Hello」消息后,會(huì)確認(rèn) TLS 版本號(hào)是否支持,和從密碼套件列表中選擇一個(gè)密碼套件,以及生成隨機(jī)數(shù)(Server Random。

接著,返回「Server Hello」消息,消息里面有服務(wù)器確認(rèn)的 TLS 版本號(hào),也給出了隨機(jī)數(shù)(Server Random),然后從客戶端的密碼套件列表選擇了一個(gè)合適的密碼套件。

可以看到,服務(wù)端選擇的密碼套件是 “Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256”。

這個(gè)密碼套件看起來真讓人頭暈,好一大串,但是其實(shí)它是有固定格式和規(guī)范的?;镜男问绞恰?strong>密鑰交換算法 + 簽名算法 + 對(duì)稱加密算法 + 摘要算法」, 一般 WITH 單詞前面有兩個(gè)單詞,第一個(gè)單詞是約定密鑰交換的算法,第二個(gè)單詞是約定證書的驗(yàn)證算法。比如剛才的密碼套件的意思就是:

  • 由于 WITH 單詞只有一個(gè) RSA,則說明握手時(shí)密鑰交換算法和簽名算法都是使用 RSA;

  • 握手后的通信使用 AES 對(duì)稱算法,密鑰長度 128 位,分組模式是 GCM;

  • 摘要算法 SHA384 用于消息認(rèn)證和產(chǎn)生隨機(jī)數(shù);

就前面這兩個(gè)客戶端和服務(wù)端相互「打招呼」的過程,客戶端和服務(wù)端就已確認(rèn)了 TLS 版本和使用的密碼套件,而且你可能發(fā)現(xiàn)客戶端和服務(wù)端都會(huì)各自生成一個(gè)隨機(jī)數(shù),并且還會(huì)把隨機(jī)數(shù)傳遞給對(duì)方。

那這個(gè)隨機(jī)數(shù)有啥用呢?其實(shí)這兩個(gè)隨機(jī)數(shù)是后續(xù)作為生成「會(huì)話密鑰」的條件,所謂的會(huì)話密鑰就是數(shù)據(jù)傳輸時(shí),所使用的對(duì)稱加密密鑰。

然后,服務(wù)端為了證明自己的身份,會(huì)發(fā)送「Server Certificate」給客戶端,這個(gè)消息里含有數(shù)字證書。

隨后,服務(wù)端發(fā)了「Server Hello Done」消息,目的是告訴客戶端,我已經(jīng)把該給你的東西都給你了,本次打招呼完畢。

客戶端驗(yàn)證證書

在這里剎個(gè)車,客戶端拿到了服務(wù)端的數(shù)字證書后,要怎么校驗(yàn)該數(shù)字證書是真實(shí)有效的呢?

數(shù)字證書和 CA 機(jī)構(gòu)

在說校驗(yàn)數(shù)字證書是否可信的過程前,我們先來看看數(shù)字證書是什么,一個(gè)數(shù)字證書通常包含了:

  • 公鑰;

  • 持有者信息;

  • 證書認(rèn)證機(jī)構(gòu)(CA)的信息;

  • CA 對(duì)這份文件的數(shù)字簽名及使用的算法;

  • 證書有效期;

  • 還有一些其他額外信息;

那數(shù)字證書的作用,是用來認(rèn)證公鑰持有者的身份,以防止第三方進(jìn)行冒充。說簡單些,證書就是用來告訴客戶端,該服務(wù)端是否是合法的,因?yàn)橹挥凶C書合法,才代表服務(wù)端身份是可信的。

我們用證書來認(rèn)證公鑰持有者的身份(服務(wù)端的身份),那證書又是怎么來的?又該怎么認(rèn)證證書呢?

為了讓服務(wù)端的公鑰被大家信任,服務(wù)端的證書都是由 CA (Certificate Authority,證書認(rèn)證機(jī)構(gòu))簽名的,CA 就是網(wǎng)絡(luò)世界里的公安局、公證中心,具有極高的可信度,所以由它來給各個(gè)公鑰簽名,信任的一方簽發(fā)的證書,那必然證書也是被信任的。

之所以要簽名,是因?yàn)楹灻淖饔每梢员苊庵虚g人在獲取證書時(shí)對(duì)證書內(nèi)容的篡改。

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

如下圖圖所示,為數(shù)字證書簽發(fā)和驗(yàn)證流程:

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

  • 首先 CA 會(huì)把持有者的公鑰、用途、頒發(fā)者、有效時(shí)間等信息打成一個(gè)包,然后對(duì)這些信息進(jìn)行 Hash 計(jì)算,得到一個(gè) Hash 值;

  • 然后 CA 會(huì)使用自己的私鑰將該 Hash 值加密,生成 Certificate Signature,也就是 CA 對(duì)證書做了簽名;

  • 最后將 Certificate Signature 添加在文件證書上,形成數(shù)字證書;

客戶端校驗(yàn)服務(wù)端的數(shù)字證書的過程,如上圖右邊部分:

  • 首先客戶端會(huì)使用同樣的 Hash 算法獲取該證書的 Hash 值 H1;

  • 通常瀏覽器和操作系統(tǒng)中集成了 CA 的公鑰信息,瀏覽器收到證書后可以使用 CA 的公鑰解密 Certificate Signature 內(nèi)容,得到一個(gè) Hash 值 H2 ;

  • 最后比較 H1 和 H2,如果值相同,則為可信賴的證書,否則則認(rèn)為證書不可信。

證書鏈

但事實(shí)上,證書的驗(yàn)證過程中還存在一個(gè)證書信任鏈的問題,因?yàn)槲覀兿?CA 申請(qǐng)的證書一般不是根證書簽發(fā)的,而是由中間證書簽發(fā)的,比如百度的證書,從下圖你可以看到,證書的層級(jí)有三級(jí):

對(duì)于這種三級(jí)層級(jí)關(guān)系的證書的驗(yàn)證過程如下:

  • 客戶端收到 baidu.com 的證書后,發(fā)現(xiàn)這個(gè)證書的簽發(fā)者不是根證書,就無法根據(jù)本地已有的根證書中的公鑰去驗(yàn)證 baidu.com 證書是否可信。于是,客戶端根據(jù) baidu.com 證書中的簽發(fā)者,找到該證書的頒發(fā)機(jī)構(gòu)是 “GlobalSign Organization Validation CA - SHA256 - G2”,然后向 CA 請(qǐng)求該中間證書。

  • 請(qǐng)求到證書后發(fā)現(xiàn) “GlobalSign Organization Validation CA - SHA256 - G2” 證書是由 “GlobalSign Root CA” 簽發(fā)的,由于 “GlobalSign Root CA” 沒有再上級(jí)簽發(fā)機(jī)構(gòu),說明它是根證書,也就是自簽證書。應(yīng)用軟件會(huì)檢查此證書有否已預(yù)載于根證書清單上,如果有,則可以利用根證書中的公鑰去驗(yàn)證 “GlobalSign Organization Validation CA - SHA256 - G2” 證書,如果發(fā)現(xiàn)驗(yàn)證通過,就認(rèn)為該中間證書是可信的。

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

在這四個(gè)步驟中,最開始客戶端只信任根證書 GlobalSign Root CA 證書的,然后 “GlobalSign Root CA” 證書信任 “GlobalSign Organization Validation CA - SHA256 - G2” 證書,而 “GlobalSign Organization Validation CA - SHA256 - G2” 證書又信任 baidu.com 證書,于是客戶端也信任 baidu.com 證書。

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

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

這樣的一層層地驗(yàn)證就構(gòu)成了一條信任鏈路,整個(gè)證書信任鏈驗(yàn)證流程如下圖所示:

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

這是為了確保根證書的絕對(duì)安全性,將根證書隔離地越嚴(yán)格越好,不然根證書如果失守了,那么整個(gè)信任鏈都會(huì)有問題。

TLS 第三次握手

客戶端驗(yàn)證完證書后,認(rèn)為可信則繼續(xù)往下走。接著,客戶端就會(huì)生成一個(gè)新的隨機(jī)數(shù) (pre-master),用服務(wù)器的 RSA 公鑰加密該隨機(jī)數(shù),通過「Change Cipher Key Exchange」消息傳給服務(wù)端。

服務(wù)端收到后,用 RSA 私鑰解密,得到客戶端發(fā)來的隨機(jī)數(shù) (pre-master)。

至此,客戶端和服務(wù)端雙方都共享了三個(gè)隨機(jī)數(shù),分別是 Client Random、Server Random、pre-master。

于是,雙方根據(jù)已經(jīng)得到的三個(gè)隨機(jī)數(shù),生成會(huì)話密鑰(Master Secret),它是對(duì)稱密鑰,用于對(duì)后續(xù)的 HTTP 請(qǐng)求/響應(yīng)的數(shù)據(jù)加解密。

生成完會(huì)話密鑰后,然后客戶端發(fā)一個(gè)「Change Cipher Spec」,告訴服務(wù)端開始使用加密方式發(fā)送消息。

然后,客戶端再發(fā)一個(gè)「Encrypted Handshake Message(Finishd)」消息,把之前所有發(fā)送的數(shù)據(jù)做個(gè)摘要,再用會(huì)話密鑰(master secret)加密一下,讓服務(wù)器做個(gè)驗(yàn)證,驗(yàn)證加密通信是否可用和之前握手信息是否有被中途篡改過。

可以發(fā)現(xiàn),「Change Cipher Spec」之前傳輸?shù)?TLS 握手?jǐn)?shù)據(jù)都是明文,之后都是對(duì)稱密鑰加密的密文。

TLS 第四次握手

服務(wù)器也是同樣的操作,發(fā)「Change Cipher Spec」和「Encrypted Handshake Message」消息,如果雙方都驗(yàn)證加密和解密沒問題,那么握手正式完成。

最后,就用「會(huì)話密鑰」加解密 HTTP 請(qǐng)求和響應(yīng)了。


RSA 算法的缺陷

使用 RSA 密鑰協(xié)商算法的最大問題是不支持前向保密。因?yàn)榭蛻舳藗鬟f隨機(jī)數(shù)(用于生成對(duì)稱加密密鑰的條件之一)給服務(wù)端時(shí)使用的是公鑰加密的,服務(wù)端收到到后,會(huì)用私鑰解密得到隨機(jī)數(shù)。所以一旦服務(wù)端的私鑰泄漏了,過去被第三方截獲的所有 TLS 通訊密文都會(huì)被破解。

為了解決這一問題,于是就有了 DH 密鑰協(xié)商算法,這里簡單介紹它的工作流程。

客戶端和服務(wù)端各自會(huì)生成隨機(jī)數(shù),并以此作為私鑰,然后根據(jù)公開的 DH 計(jì)算公示算出各自的公鑰,通過 TLS 握手雙方交換各自的公鑰,這樣雙方都有自己的私鑰和對(duì)方的公鑰,然后雙方根據(jù)各自持有的材料算出一個(gè)隨機(jī)數(shù),這個(gè)隨機(jī)數(shù)的值雙方都是一樣的,這就可以作為后續(xù)對(duì)稱加密時(shí)使用的密鑰。

DH 密鑰交換過程中,即使第三方截獲了 TLS 握手階段傳遞的公鑰,在不知道的私鑰的情況下,也是無法計(jì)算出密鑰的,而且每一次對(duì)稱加密密鑰都是實(shí)時(shí)生成的,實(shí)現(xiàn)前向保密

但因?yàn)?DH 算法的計(jì)算效率問題,后面出現(xiàn)了 ECDHE 密鑰協(xié)商算法,我們現(xiàn)在大多數(shù)網(wǎng)站使用的正是 ECDHE 密鑰協(xié)商算法,關(guān)于 ECDHE 握手的過程,將在下一篇揭曉,盡情期待哦。

免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺(tái)立場(chǎng),如有問題,請(qǐng)聯(lián)系我們,謝謝!

本站聲明: 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點(diǎn),本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請(qǐng)聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請(qǐng)及時(shí)聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫?dú)角獸公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關(guān)鍵字: 阿維塔 塞力斯 華為

倫敦2024年8月29日 /美通社/ -- 英國汽車技術(shù)公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認(rèn)證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時(shí)1.5...

關(guān)鍵字: 汽車 人工智能 智能驅(qū)動(dòng) BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務(wù)能7×24不間斷運(yùn)行,同時(shí)企業(yè)卻面臨越來越多業(yè)務(wù)中斷的風(fēng)險(xiǎn),如企業(yè)系統(tǒng)復(fù)雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務(wù)連續(xù)性,提升韌性,成...

關(guān)鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報(bào)道,騰訊和網(wǎng)易近期正在縮減他們對(duì)日本游戲市場(chǎng)的投資。

關(guān)鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會(huì)開幕式在貴陽舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關(guān)鍵字: 華為 12nm EDA 半導(dǎo)體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會(huì)上,華為常務(wù)董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權(quán)最終是由生態(tài)的繁榮決定的。

關(guān)鍵字: 華為 12nm 手機(jī) 衛(wèi)星通信

要點(diǎn): 有效應(yīng)對(duì)環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實(shí)提質(zhì)增效舉措,毛利潤率延續(xù)升勢(shì) 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務(wù)引領(lǐng)增長 以科技創(chuàng)新為引領(lǐng),提升企業(yè)核心競(jìng)爭力 堅(jiān)持高質(zhì)量發(fā)展策略,塑強(qiáng)核心競(jìng)爭優(yōu)勢(shì)...

關(guān)鍵字: 通信 BSP 電信運(yùn)營商 數(shù)字經(jīng)濟(jì)

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺(tái)與中國電影電視技術(shù)學(xué)會(huì)聯(lián)合牽頭組建的NVI技術(shù)創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會(huì)上宣布正式成立。 活動(dòng)現(xiàn)場(chǎng) NVI技術(shù)創(chuàng)新聯(lián)...

關(guān)鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會(huì)上,軟通動(dòng)力信息技術(shù)(集團(tuán))股份有限公司(以下簡稱"軟通動(dòng)力")與長三角投資(上海)有限...

關(guān)鍵字: BSP 信息技術(shù)
關(guān)閉
關(guān)閉