轉(zhuǎn)載于http://www.likecs.com/default/index/show?id=124371
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é)概念就慫了摆尝？不怕，這次不會(huì)說離散對數(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í)了離散對數(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é)商算法就要做大的升級(jí)了飒箭。
雙方交換各自 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 就是小紅和小明之間用的對稱加密密鑰伊滋，可以作為會(huì)話密鑰使用碳却。
可以看到，整個(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ì)算出會(huì)話密鑰灼卢，因此 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í)間延長零院，黑客就會(huì)截獲海量的密鑰協(xié)商過程的數(shù)據(jù)溉跃，因?yàn)槊荑€協(xié)商的過程有些數(shù)據(jù)是公開的，黑客就可以依據(jù)這些數(shù)據(jù)暴力破解出服務(wù)器的私鑰告抄，然后就可以計(jì)算出會(huì)話密鑰了撰茎，于是之前截獲的加密數(shù)據(jù)會(huì)被破解，所以 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ì)算出公鑰，以及最終的會(huì)話密鑰讽坏。
小紅和小明使用 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)是一樣的朝群，所以它是共享密鑰，也就是會(huì)話密鑰中符。
這個(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ù)男省?/p>
接下來，分析每一個(gè) ECDHE 握手過程售碳。
TLS 第一次握手
客戶端首先會(huì)發(fā)一個(gè)「Client Hello」消息强重，消息里面有客戶端使用的 TLS 版本號(hào)、支持的密碼套件列表贸人，以及生成的隨機(jī)數(shù)（Client Random）**间景。
TLS 第二次握手
服務(wù)端收到客戶端的「打招呼」，同樣也要回禮艺智，會(huì)返回「Server Hello」消息拱燃，消息面有服務(wù)器確認(rèn)的 TLS 版本號(hào)，也給出了一個(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」消息，會(huì)把證書也發(fā)給客戶端蜕着。
這一步就和 RSA 握手過程有很大到區(qū)別了谋竖，因?yàn)榉?wù)端選擇了 ECDHE 密鑰協(xié)商算法红柱，所以會(huì)在發(fā)送完證書后，發(fā)送「Server Key Exchange」消息蓖乘。
這個(gè)過程服務(wù)器做了三件事：
- 選擇了名為 named_curve 的橢圓曲線锤悄，選好了橢圓曲線相當(dāng)于橢圓曲線基點(diǎn) G 也定好了，這些都會(huì)公開給客戶端嘉抒；
- 生成隨機(jī)數(shù)作為服務(wù)端橢圓曲線的私鑰零聚，保留到本地；
- 根據(jù)基點(diǎn) G 和私鑰計(jì)算出服務(wù)端的橢圓曲線公鑰些侍，這個(gè)會(huì)公開給客戶端隶症。
為了保證這個(gè)橢圓曲線的公鑰不被第三方篡改，服務(wù)端會(huì)用 RSA 簽名算法給服務(wù)端的橢圓曲線公鑰做個(gè)簽名娩梨。
隨后沿腰，就是「Server Hello Done」消息，服務(wù)端跟客戶端表明：“這些就是我提供的信息狈定，打招呼完畢”颂龙。
至此，TLS 兩次握手就已經(jīng)完成了纽什，目前客戶端和服務(wù)端通過明文共享了這幾個(gè)信息：Client Random措嵌、Server Random 、使用的橢圓曲線芦缰、橢圓曲線基點(diǎn) G企巢、服務(wù)端橢圓曲線的公鑰戏羽，這幾個(gè)信息很重要亿昏，是后續(xù)生成會(huì)話密鑰的材料稠通。
TLS 第三次握手
客戶端收到了服務(wù)端的證書后藐俺，自然要校驗(yàn)證書是否合法炕置，如果證書合法辩涝，那么服務(wù)端到身份就是沒問題的吏够。校驗(yàn)證書到過程推正，會(huì)走證書鏈逐級(jí)驗(yàn)證顿颅，確認(rèn)證書的真實(shí)性缸濒，再用證書的公鑰驗(yàn)證簽名，這樣就能確認(rèn)服務(wù)端的身份了粱腻，確認(rèn)無誤后庇配，就可以繼續(xù)往下走。
客戶端會(huì)生成一個(gè)隨機(jī)數(shù)作為客戶端橢圓曲線的私鑰绍些，然后再根據(jù)服務(wù)端前面給的信息捞慌，生成客戶端的橢圓曲線公鑰，然后用「Client Key Exchange」消息發(fā)給服務(wù)端柬批。
至此卿闹，雙方都有對方的橢圓曲線公鑰揭糕、自己的橢圓曲線私鑰、橢圓曲線基點(diǎn) G锻霎。于是著角，雙方都就計(jì)算出點(diǎn)（x，y）旋恼，其中 x 坐標(biāo)值雙方都是一樣的吏口，前面說 ECDHE 算法時(shí)候，說 x 是會(huì)話密鑰冰更，但實(shí)際應(yīng)用中产徊，x 還不是最終的會(huì)話密鑰。
還記得 TLS 握手階段蜀细，客戶端和服務(wù)端都會(huì)生成了一個(gè)隨機(jī)數(shù)傳遞給對方嗎舟铜？
最終的會(huì)話密鑰，就是用「客戶端隨機(jī)數(shù) + 服務(wù)端隨機(jī)數(shù) + x（ECDHE 算法算出的共享密鑰） 」三個(gè)材料生成的奠衔。
之所以這么麻煩谆刨，是因?yàn)?TLS 設(shè)計(jì)者不信任客戶端或服務(wù)器「偽隨機(jī)數(shù)」的可靠性，為了保證真正的完全隨機(jī)归斤，把三個(gè)不可靠的隨機(jī)數(shù)混合起來痊夭，那么「隨機(jī)」的程度就非常高了，足夠讓黑客計(jì)算出最終的會(huì)話密鑰脏里，安全性更高她我。
算好會(huì)話密鑰后，客戶端會(huì)發(fā)一個(gè)「Change Cipher Spec」消息迫横，告訴服務(wù)端后續(xù)改用對稱算法加密通信番舆。
接著，客戶端會(huì)發(fā)「Encrypted Handshake Message」消息矾踱，把之前發(fā)送的數(shù)據(jù)做一個(gè)摘要合蔽，再用對稱密鑰加密一下，讓服務(wù)端做個(gè)驗(yàn)證介返，驗(yàn)證下本次生成的對稱密鑰是否可以正常使用。
TLS 第四次握手
最后沃斤，服務(wù)端也會(huì)有一個(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 次握手中压真，會(huì)出現(xiàn)服務(wù)器端發(fā)出的「Server Key Exchange」消息，而 RSA 握手過程沒有該消息蘑险；
