這 HTTPS，真滴牛逼！

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

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

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

離散對數(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)算公式，如下圖所示：

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

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

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

上圖的，底數(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。

這個(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 握手過程，可以看到是四次握手：

細(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）。

TLS 第二次握手

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

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

「 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384」

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

• 簽名算法使用 RSA；

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

• 摘要算法使用 SHA384；

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

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

這個(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ù)端跟客戶端表明：“這些就是我提供的信息，打招呼完畢”。

至此，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ù)端。

至此，雙方都有對方的橢圓曲線公鑰、自己的橢圓曲線私鑰、橢圓曲線基點(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ù)改用對稱算法加密通信。

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

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 握手過程沒有該消息；