當(dāng)前位置:首頁 > 公眾號精選 > 架構(gòu)師社區(qū)
[導(dǎo)讀]HTTPS 常用的密鑰交換算法有兩種,分別是 RSA 和 ECDHE 算法。

HTTPS 常用的密鑰交換算法有兩種,分別是 RSA 和 ECDHE 算法。

其中,RSA 是比較傳統(tǒng)的密鑰交換算法,它不具備前向安全的性質(zhì),因此現(xiàn)在很少服務(wù)器使用的。而 ECDHE 算法具有前向安全,所以被廣泛使用。

我在上一篇已經(jīng)介紹了 RSA 握手的過程,今天這一篇就「從理論再到實(shí)戰(zhàn)抓包」介紹 ECDHE 算法

這 HTTPS,真滴牛逼!

離散對數(shù)

ECDHE 密鑰協(xié)商算法是 DH 算法演進(jìn)過來的,所以我們先從 DH 算法說起。

DH 算法是非對稱加密算法, 因此它可以用于密鑰交換,該算法的核心數(shù)學(xué)思想是離散對數(shù)。

是不是聽到這個(gè)數(shù)學(xué)概念就慫了?不怕,這次不會說離散對數(shù)推到的過程,只簡單提一下它的數(shù)學(xué)公式。

離散對數(shù)是「離散 + 對數(shù)」的兩個(gè)數(shù)學(xué)概念的組合,所以我們先來復(fù)習(xí)一遍對數(shù)。

要說起對數(shù),必然要說指數(shù),因?yàn)樗鼈兪腔榉春瘮?shù),指數(shù)就是冪運(yùn)算,對數(shù)是指數(shù)的逆運(yùn)算。

舉個(gè)栗子,如果以 2 作為底數(shù),那么指數(shù)和對數(shù)運(yùn)算公式,如下圖所示:

這 HTTPS,真滴牛逼!

那么對于底數(shù)為 2 的時(shí)候, 32 的對數(shù)是 5,64 的對數(shù)是 6,計(jì)算過程如下:

這 HTTPS,真滴牛逼!

對數(shù)運(yùn)算的取值是可以連續(xù)的,而離散對數(shù)的取值是不能連續(xù)的,因此也以「離散」得名,

離散對數(shù)是在對數(shù)運(yùn)算的基礎(chǔ)上加了「模運(yùn)算」,也就說取余數(shù),對應(yīng)編程語言的操作符是「%」,也可以用 mod 表示。離散對數(shù)的概念如下圖:

這 HTTPS,真滴牛逼!

上圖的,底數(shù) a 和模數(shù) p 是離散對數(shù)的公共參數(shù),也就說是公開的,b 是真數(shù),i 是對數(shù)。知道了對數(shù),就可以用上面的公式計(jì)算出真數(shù)。但反過來,知道真數(shù)卻很難推算出對數(shù)。

特別是當(dāng)模數(shù) p 是一個(gè)很大的質(zhì)數(shù),即使知道底數(shù) a 和真數(shù) b ,在現(xiàn)有的計(jì)算機(jī)的計(jì)算水平是幾乎無法算出離散對數(shù)的,這就是 DH 算法的數(shù)學(xué)基礎(chǔ)。


DH 算法

認(rèn)識了離散對數(shù),我們來看看 DH 算法是如何密鑰交換的。

現(xiàn)假設(shè)小紅和小明約定使用 DH 算法來交換密鑰,那么基于離散對數(shù),小紅和小明需要先確定模數(shù)和底數(shù)作為算法的參數(shù),這兩個(gè)參數(shù)是公開的,用 P 和 G 來代稱。

然后小紅和小明各自生成一個(gè)隨機(jī)整數(shù)作為私鑰,雙方的私鑰要各自嚴(yán)格保管,不能泄漏,小紅的私鑰用 a 代稱,小明的私鑰用 b 代稱。

現(xiàn)在小紅和小明雙方都有了 P 和 G 以及各自的私鑰,于是就可以計(jì)算出公鑰

  • 小紅的公鑰記作 A,A = G ^ a ( mod P );

  • 小明的公鑰記作 B,B = G ^ b ( mod P );

A 和 B 也是公開的,因?yàn)楦鶕?jù)離散對數(shù)的原理,從真數(shù)(A 和 B)反向計(jì)算對數(shù) a 和 b 是非常困難的,至少在現(xiàn)有計(jì)算機(jī)的計(jì)算能力是無法破解的,如果量子計(jì)算機(jī)出來了,那就有可能被破解,當(dāng)然如果量子計(jì)算機(jī)真的出來了,那么密鑰協(xié)商算法就要做大的升級了。

雙方交換各自 DH 公鑰后,小紅手上共有 5 個(gè)數(shù):P、G、a、A、B,小明手上也同樣共有 5 個(gè)數(shù):P、G、b、B、A。

然后小紅執(zhí)行運(yùn)算:B ^ a ( mod P ),其結(jié)果為 K,因?yàn)殡x散對數(shù)的冪運(yùn)算有交換律,所以小明執(zhí)行運(yùn)算:A ^ b ( mod P ),得到的結(jié)果也是 K。

這 HTTPS,真滴牛逼!

這個(gè) K 就是小紅和小明之間用的對稱加密密鑰,可以作為會話密鑰使用。

可以看到,整個(gè)密鑰協(xié)商過程中,小紅和小明公開了 4 個(gè)信息:P、G、A、B,其中 P、G 是算法的參數(shù),A 和 B 是公鑰,而 a、b 是雙方各自保管的私鑰,黑客無法獲取這 2 個(gè)私鑰,因此黑客只能從公開的 P、G、A、B 入手,計(jì)算出離散對數(shù)(私鑰)。

前面也多次強(qiáng)調(diào), 根據(jù)離散對數(shù)的原理,如果 P 是一個(gè)大數(shù),在現(xiàn)有的計(jì)算機(jī)的計(jì)算能力是很難破解出 私鑰 a、b 的,破解不出私鑰,也就無法計(jì)算出會話密鑰,因此 DH 密鑰交換是安全的。


DHE 算法

根據(jù)私鑰生成的方式,DH 算法分為兩種實(shí)現(xiàn):

  • static DH 算法,這個(gè)是已經(jīng)被廢棄了;

  • DHE 算法,現(xiàn)在常用的;

static DH 算法里有一方的私鑰是靜態(tài)的,也就說每次密鑰協(xié)商的時(shí)候有一方的私鑰都是一樣的,一般是服務(wù)器方固定,即 a 不變,客戶端的私鑰則是隨機(jī)生成的。

于是,DH 交換密鑰時(shí)就只有客戶端的公鑰是變化,而服務(wù)端公鑰是不變的,那么隨著時(shí)間延長,黑客就會截獲海量的密鑰協(xié)商過程的數(shù)據(jù),因?yàn)槊荑€協(xié)商的過程有些數(shù)據(jù)是公開的,黑客就可以依據(jù)這些數(shù)據(jù)暴力破解出服務(wù)器的私鑰,然后就可以計(jì)算出會話密鑰了,于是之前截獲的加密數(shù)據(jù)會被破解,所以 static DH 算法不具備前向安全性。

既然固定一方的私鑰有被破解的風(fēng)險(xiǎn),那么干脆就讓雙方的私鑰在每次密鑰交換通信時(shí),都是隨機(jī)生成的、臨時(shí)的,這個(gè)方式也就是 DHE 算法,E 全稱是 ephemeral(臨時(shí)性的)。

所以,即使有個(gè)牛逼的黑客破解了某一次通信過程的私鑰,其他通信過程的私鑰仍然是安全的,因?yàn)?strong>每個(gè)通信過程的私鑰都是沒有任何關(guān)系的,都是獨(dú)立的,這樣就保證了「前向安全」。


ECDHE 算法

DHE 算法由于計(jì)算性能不佳,因?yàn)樾枰龃罅康某朔?,為了提?DHE 算法的性能,所以就出現(xiàn)了現(xiàn)在廣泛用于密鑰交換算法 —— ECDHE 算法

ECDHE 算法是在 DHE 算法的基礎(chǔ)上利用了 ECC 橢圓曲線特性,可以用更少的計(jì)算量計(jì)算出公鑰,以及最終的會話密鑰。

小紅和小明使用 ECDHE 密鑰交換算法的過程:

  • 雙方事先確定好使用哪種橢圓曲線,和曲線上的基點(diǎn) G,這兩個(gè)參數(shù)都是公開的;

  • 雙方各自隨機(jī)生成一個(gè)隨機(jī)數(shù)作為私鑰d,并與基點(diǎn) G相乘得到公鑰Q(Q = dG),此時(shí)小紅的公私鑰為 Q1 和 d1,小明的公私鑰為 Q2 和 d2;

  • 雙方交換各自的公鑰,最后小紅計(jì)算點(diǎn)(x1,y1) = d1Q2,小明計(jì)算點(diǎn)(x2,y2) = d2Q1,由于橢圓曲線上是可以滿足乘法交換和結(jié)合律,所以 d1Q2 = d1d2G = d2d1G = d2Q1 ,因此雙方的 x 坐標(biāo)是一樣的,所以它是共享密鑰,也就是會話密鑰。

這個(gè)過程中,雙方的私鑰都是隨機(jī)、臨時(shí)生成的,都是不公開的,即使根據(jù)公開的信息(橢圓曲線、公鑰、基點(diǎn) G)也是很難計(jì)算出橢圓曲線上的離散對數(shù)(私鑰)。


ECDHE 握手過程

知道了 ECDHE 算法基本原理后,我們就結(jié)合實(shí)際的情況來看看。

我用 Wireshark 工具抓了用 ECDHE 密鑰協(xié)商算法的 TSL 握手過程,可以看到是四次握手:

這 HTTPS,真滴牛逼!

細(xì)心的小伙伴應(yīng)該發(fā)現(xiàn)了,使用了 ECDHE,在 TLS 第四次握手前,客戶端就已經(jīng)發(fā)送了加密的 HTTP 數(shù)據(jù),而對于 RSA 握手過程,必須要完成 TLS 四次握手,才能傳輸應(yīng)用數(shù)據(jù)。

所以,ECDHE 相比 RSA 握手過程省去了一個(gè)消息往返的時(shí)間,這個(gè)有點(diǎn)「搶跑」的意思,它被稱為是「TLS False Start」,跟「TCP Fast Open」有點(diǎn)像,都是在還沒連接完全建立前,就發(fā)送了應(yīng)用數(shù)據(jù),這樣便提高了傳輸?shù)男省?

接下來,分析每一個(gè) ECDHE 握手過程。

TLS 第一次握手

客戶端首先會發(fā)一個(gè)「Client Hello」消息,消息里面有客戶端使用的 TLS 版本號、支持的密碼套件列表,以及生成的隨機(jī)數(shù)(Client Random。

這 HTTPS,真滴牛逼!

TLS 第二次握手

服務(wù)端收到客戶端的「打招呼」,同樣也要回禮,會返回「Server Hello」消息,消息面有服務(wù)器確認(rèn)的 TLS 版本號,也給出了一個(gè)隨機(jī)數(shù)(Server Random,然后從客戶端的密碼套件列表選擇了一個(gè)合適的密碼套件。

這 HTTPS,真滴牛逼!

不過,這次選擇的密碼套件就和 RSA 不一樣了,我們來分析一下這次的密碼套件的意思。

「 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384」

  • 密鑰協(xié)商算法使用 ECDHE;

  • 簽名算法使用 RSA;

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

  • 摘要算法使用 SHA384;

接著,服務(wù)端為了證明自己的身份,發(fā)送「Certificate」消息,會把證書也發(fā)給客戶端。

這 HTTPS,真滴牛逼!

這一步就和 RSA 握手過程有很大到區(qū)別了,因?yàn)榉?wù)端選擇了 ECDHE 密鑰協(xié)商算法,所以會在發(fā)送完證書后,發(fā)送「Server Key Exchange」消息。

這 HTTPS,真滴牛逼!

這個(gè)過程服務(wù)器做了三件事:

  • 選擇了名為 named_curve 的橢圓曲線,選好了橢圓曲線相當(dāng)于橢圓曲線基點(diǎn) G 也定好了,這些都會公開給客戶端;

  • 生成隨機(jī)數(shù)作為服務(wù)端橢圓曲線的私鑰,保留到本地;

  • 根據(jù)基點(diǎn) G 和私鑰計(jì)算出服務(wù)端的橢圓曲線公鑰,這個(gè)會公開給客戶端。

為了保證這個(gè)橢圓曲線的公鑰不被第三方篡改,服務(wù)端會用 RSA 簽名算法給服務(wù)端的橢圓曲線公鑰做個(gè)簽名。

隨后,就是「Server Hello Done」消息,服務(wù)端跟客戶端表明:“這些就是我提供的信息,打招呼完畢”。

這 HTTPS,真滴牛逼!

至此,TLS 兩次握手就已經(jīng)完成了,目前客戶端和服務(wù)端通過明文共享了這幾個(gè)信息:Client Random、Server Random 、使用的橢圓曲線、橢圓曲線基點(diǎn) G、服務(wù)端橢圓曲線的公鑰,這幾個(gè)信息很重要,是后續(xù)生成會話密鑰的材料。

TLS 第三次握手

客戶端收到了服務(wù)端的證書后,自然要校驗(yàn)證書是否合法,如果證書合法,那么服務(wù)端到身份就是沒問題的。校驗(yàn)證書到過程,會走證書鏈逐級驗(yàn)證,確認(rèn)證書的真實(shí)性,再用證書的公鑰驗(yàn)證簽名,這樣就能確認(rèn)服務(wù)端的身份了,確認(rèn)無誤后,就可以繼續(xù)往下走。

客戶端會生成一個(gè)隨機(jī)數(shù)作為客戶端橢圓曲線的私鑰,然后再根據(jù)服務(wù)端前面給的信息,生成客戶端的橢圓曲線公鑰,然后用「Client Key Exchange」消息發(fā)給服務(wù)端。

這 HTTPS,真滴牛逼!

至此,雙方都有對方的橢圓曲線公鑰、自己的橢圓曲線私鑰、橢圓曲線基點(diǎn) G。于是,雙方都就計(jì)算出點(diǎn)(x,y),其中 x 坐標(biāo)值雙方都是一樣的,前面說 ECDHE 算法時(shí)候,說 x 是會話密鑰,但實(shí)際應(yīng)用中,x 還不是最終的會話密鑰

還記得 TLS 握手階段,客戶端和服務(wù)端都會生成了一個(gè)隨機(jī)數(shù)傳遞給對方嗎?

最終的會話密鑰,就是用「客戶端隨機(jī)數(shù) + 服務(wù)端隨機(jī)數(shù) + x(ECDHE 算法算出的共享密鑰) 」三個(gè)材料生成的。

之所以這么麻煩,是因?yàn)?TLS 設(shè)計(jì)者不信任客戶端或服務(wù)器「偽隨機(jī)數(shù)」的可靠性,為了保證真正的完全隨機(jī),把三個(gè)不可靠的隨機(jī)數(shù)混合起來,那么「隨機(jī)」的程度就非常高了,足夠讓黑客計(jì)算出最終的會話密鑰,安全性更高。

算好會話密鑰后,客戶端會發(fā)一個(gè)「Change Cipher Spec」消息,告訴服務(wù)端后續(xù)改用對稱算法加密通信。

這 HTTPS,真滴牛逼!

接著,客戶端會發(fā)「Encrypted Handshake Message」消息,把之前發(fā)送的數(shù)據(jù)做一個(gè)摘要,再用對稱密鑰加密一下,讓服務(wù)端做個(gè)驗(yàn)證,驗(yàn)證下本次生成的對稱密鑰是否可以正常使用。

這 HTTPS,真滴牛逼!

TLS 第四次握手

最后,服務(wù)端也會有一個(gè)同樣的操作,發(fā)「Change Cipher Spec」和「Encrypted Handshake Message」消息,如果雙方都驗(yàn)證加密和解密沒問題,那么握手正式完成。于是,就可以正常收發(fā)加密的 HTTP 請求和響應(yīng)了。


總結(jié)

RSA 和 ECDHE 握手過程的區(qū)別:

  • RSA 密鑰協(xié)商算法「不支持」前向保密,ECDHE 密鑰協(xié)商算法「支持」前向保密;

  • 使用了 RSA 密鑰協(xié)商算法,TLS 完成四次握手后,才能進(jìn)行應(yīng)用數(shù)據(jù)傳輸,而對于 ECDHE 算法,客戶端可以不用等服務(wù)端的最后一次 TLS 握手,就可以提前發(fā)出加密的 HTTP 數(shù)據(jù),節(jié)省了一個(gè)消息的往返時(shí)間;

  • 使用 ECDHE, 在 TLS 第 2 次握手中,會出現(xiàn)服務(wù)器端發(fā)出的「Server Key Exchange」消息,而 RSA 握手過程沒有該消息;

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

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

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

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

加利福尼亞州圣克拉拉縣2024年8月30日 /美通社/ -- 數(shù)字化轉(zhuǎn)型技術(shù)解決方案公司Trianz今天宣布,該公司與Amazon Web Services (AWS)簽訂了...

關(guān)鍵字: AWS AN BSP 數(shù)字化

倫敦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ū)動 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)易近期正在縮減他們對日本游戲市場的投資。

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

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

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

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

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

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

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

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

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

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

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