[[376816]]

本文轉(zhuǎn)載自微信公眾號「 小林coding」，作者 小林coding。轉(zhuǎn)載本文請聯(lián)系 小林coding公眾號。

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

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

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

離散對數(shù)

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

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

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

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

要說起對數(shù)，必然要說指數(shù)，因為它們是互為反函數(shù)，指數(shù)就是冪運算，對數(shù)是指數(shù)的逆運算。

舉個栗子，如果以 2 作為底數(shù)，那么指數(shù)和對數(shù)運算公式，如下圖所示：

那么對于底數(shù)為 2 的時候， 32 的對數(shù)是 5，64 的對數(shù)是 6，計算過程如下：

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

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

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

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

DH 算法

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

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

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

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

• 小紅的公鑰記作 A，A = G ^ a ( mod P );
• 小明的公鑰記作 B，B = G ^ b ( mod P );

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

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

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

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

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

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

DHE 算法

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

• static DH 算法，這個是已經(jīng)被廢棄了;
• DHE 算法，現(xiàn)在常用的;

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

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

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

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

ECDHE 算法

DHE 算法由于計算性能不佳，因為需要做大量的乘法，為了提升 DHE 算法的性能，所以就出現(xiàn)了現(xiàn)在廣泛用于密鑰交換算法 —— ECDHE 算法。

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

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

• 雙方事先確定好使用哪種橢圓曲線，和曲線上的基點 G，這兩個參數(shù)都是公開的;
• 雙方各自隨機生成一個隨機數(shù)作為私鑰d，并與基點 G相乘得到公鑰Q(Q = dG)，此時小紅的公私鑰為 Q1 和 d1，小明的公私鑰為 Q2 和 d2;
• 雙方交換各自的公鑰，最后小紅計算點(x1，y1) = d1Q2，小明計算點(x2，y2) = d2Q1，由于橢圓曲線上是可以滿足乘法交換和結(jié)合律，所以 d1Q2 = d1d2G = d2d1G = d2Q1 ，因此雙方的 x 坐標是一樣的，所以它是共享密鑰，也就是會話密鑰。

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

ECDHE 握手過程

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

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

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

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

接下來，分析每一個 ECDHE 握手過程。

TLS 第一次握手

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

TLS 第二次握手

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

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

「 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384」

• 密鑰協(xié)商算法使用 ECDHE;
• 簽名算法使用 RSA;
• 握手后的通信使用 AES 對稱算法，密鑰長度 256 位，分組模式是 GCM;
• 摘要算法使用 SHA384;

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

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

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

• 選擇了名為 named_curve 的橢圓曲線，選好了橢圓曲線相當于橢圓曲線基點 G 也定好了，這些都會公開給客戶端;
• 生成隨機數(shù)作為服務(wù)端橢圓曲線的私鑰，保留到本地;
• 根據(jù)基點 G 和私鑰計算出服務(wù)端的橢圓曲線公鑰，這個會公開給客戶端。

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

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

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

TLS 第三次握手

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

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

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

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

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

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

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

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

TLS 第四次握手

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

總結(jié)

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

• RSA 密鑰協(xié)商算法「不支持」前向保密，ECDHE 密鑰協(xié)商算法「支持」前向保密;
• 使用了 RSA 密鑰協(xié)商算法，TLS 完成四次握手后，才能進行應(yīng)用數(shù)據(jù)傳輸，而對于 ECDHE 算法，客戶端可以不用等服務(wù)端的最后一次 TLS 握手，就可以提前發(fā)出加密的 HTTP 數(shù)據(jù)，節(jié)省了一個消息的往返時間;
• 使用 ECDHE， 在 TLS 第 2 次握手中，會出現(xiàn)服務(wù)器端發(fā)出的「Server Key Exchange」消息，而 RSA 握手過程沒有該消息;

巨人的肩膀

https://zh.wikipedia.org/wiki/橢圓曲線迪菲-赫爾曼金鑰交換

https://zh.wikipedia.org/wiki/橢圓曲線

https://zh.wikipedia.org/wiki/迪菲-赫爾曼密鑰交換

https://time.geekbang.org/column/article/148188

https://zhuanlan.zhihu.com/p/106967180

原文鏈接：https://mp.weixin.qq.com/s/pLyR8zuw4l7Z6sdUZ4IL5w