本文詳細(xì)介紹了 HTTPS 相較于 HTTP 更安全的原因，包括對(duì)稱加密、非對(duì)稱加密、完整性摘要、數(shù)字證書以及 SSL/TLS 握手等內(nèi)容，圖文并茂、理論與實(shí)戰(zhàn)結(jié)合、建議收藏！

1. 不安全的 HTTP

近些年來(lái)，越來(lái)越多的網(wǎng)站使用 HTTPS 協(xié)議進(jìn)行數(shù)據(jù)傳輸，原因在于 HTTPS 相較于 HTTP 能夠提供更加安全的服務(wù)。

很多瀏覽器對(duì)于使用 HTTP 協(xié)議的網(wǎng)站會(huì)加上『警告』的標(biāo)志表示數(shù)據(jù)傳輸不安全，而對(duì)于使用 HTTPS 協(xié)議的網(wǎng)站會(huì)加上一把『鎖』標(biāo)志表示數(shù)據(jù)傳輸安全。

為什么 HTTP 協(xié)議不安全呢？主要表現(xiàn)在以下三個(gè)方面：

容易被竊聽(tīng)：HTTP 傳輸?shù)臄?shù)據(jù)是明文。黑客很容易通過(guò)嗅探技術(shù)截獲報(bào)文，由于數(shù)據(jù)沒(méi)有加密，內(nèi)容可以被黑客所理解。

舉個(gè)例子：如果用戶輸入密碼取款，那么黑客竊聽(tīng)了此密碼后，就可以為所欲為了！

容易被篡改：黑客可以在截獲 HTTP 報(bào)文后，對(duì)報(bào)文進(jìn)行修改，然后再發(fā)送到目的地。

舉個(gè)例子：如果用戶想要轉(zhuǎn)賬給家人，而黑客將收款人修改成了自己，將會(huì)造成用戶出現(xiàn)損失！

容易被偽造身份：黑客可以偽造 HTTP 報(bào)文，假裝自己是用戶真正想要訪問(wèn)的網(wǎng)站，然后與用戶進(jìn)行通信。

舉個(gè)例子：如果用戶想要訪問(wèn)淘寶網(wǎng)站進(jìn)行購(gòu)物，而黑客冒充自己是淘寶網(wǎng)站，用戶就可能在此假淘寶網(wǎng)站上買東西，造成損失！

HTTPS 是如何解決以上安全性問(wèn)題的呢？主要方法如下所示：

數(shù)據(jù)加密：HTTPS 傳輸?shù)牟辉偈?strong>明文，而是采用加密算法傳輸密文，黑客即使截獲了報(bào)文，也無(wú)法理解內(nèi)容！

完整性摘要：HTTPS 通過(guò)摘要算法得到報(bào)文的一個(gè)摘要，如果黑客篡改了報(bào)文內(nèi)容，那么重新生成的摘要將發(fā)生變化，接收方校驗(yàn)后就知道數(shù)據(jù)不再完整，被篡改了！

數(shù)字證書：HTTPS 通過(guò)數(shù)字證書來(lái)驗(yàn)證通信實(shí)體的身份，而黑客因?yàn)闆](méi)有相應(yīng)的證書，一旦冒充其他網(wǎng)站將會(huì)被識(shí)破！

2. 加密算法

加密算法用于解決 HTTP 傳輸數(shù)據(jù)容易被竊聽(tīng)的問(wèn)題。

為了防止傳輸數(shù)據(jù)被黑客所竊聽(tīng)，客戶端與服務(wù)器之間需要對(duì)數(shù)據(jù)進(jìn)行加解密處理。

發(fā)送方使用加密算法將明文加密為密文，而接收方使用相應(yīng)的解密算法將密文解密為明文。黑客只能看到密文，因而并不能獲取到任何有用信息。如下圖所示：

一般來(lái)說(shuō)，加密算法分為兩大類，對(duì)稱加密和非對(duì)稱加密。

對(duì)稱加密：指加密和解碼使用同一把密鑰，即圖中的密鑰 A 等于密鑰 B；

非對(duì)稱加密：指加密和解密使用不同的密鑰，即圖中的密鑰 A 不等于密鑰 B。

（1）對(duì)稱加密

對(duì)稱加密算法中加密和解密的鑰匙是同一把，稱之為密鑰。

凱撒密碼是一種較為簡(jiǎn)單的對(duì)稱加密算法，可用于對(duì)英語(yǔ)文本進(jìn)行加解密。其主要思想是：將明文中的每個(gè)字母按照字母表所在位置右移 K 位，得到密文（允許回繞）。

舉個(gè)例子，設(shè) K = 2，那么明文中的字母 "a" 用字母 "c" 代替，字母 "z" 用 字母 "b" 代替。此時(shí) K = 2 就是對(duì)稱加密算法中的密鑰。

這種方式的缺點(diǎn)在于：每個(gè)字母經(jīng)過(guò)加密后只有唯一的密文表示，如果黑客收集了很多數(shù)據(jù)后進(jìn)行統(tǒng)計(jì)分析，很可能就破解了加密手段。

更好的方式是采用多個(gè)凱撒密碼 K 輪詢進(jìn)行加密，比如位置為奇數(shù)的字母采用密鑰 K = 2 加密，位置為偶數(shù)的字母采用密鑰 K = 3 加密。

然而凱撒密碼只能加密英文文本，若想要加密所有字符，可以采用分組加密的方式。

我們知道任何數(shù)據(jù)在計(jì)算機(jī)中實(shí)際存儲(chǔ)的是 0/1 比特的組合。分組加密的主要思想是：將要加密的報(bào)文處理為 K 比特的分組，每個(gè)分組通過(guò)一對(duì)一的映射表進(jìn)行加密。

舉個(gè)例子，設(shè) K = 3，映射表如下圖，那么報(bào)文 010110001111 將會(huì)被加密為 101000111001。此時(shí) K=3 以及映射表就是對(duì)稱加密算法中的密鑰。

與前面采用多個(gè)凱撒密碼 K 作為密鑰的方式一樣，為了增加破解的難度，一種更好的方式是采用多個(gè)映射表，輪詢對(duì)數(shù)據(jù)進(jìn)行加密。

計(jì)算機(jī)網(wǎng)絡(luò)中常用的對(duì)稱加密算法有：DES、3DES、AES 等，都屬于分組加密算法。

（2）非對(duì)稱加密

非對(duì)稱加密算法中加密和解密的鑰匙不同，分別稱為公鑰和私鑰。其特點(diǎn)在于：

如果用公鑰加密，則只能用私鑰解密，此時(shí)公鑰是不能解密的。

如果用私鑰加密，則只能用公鑰解密，此時(shí)私鑰是不能解密的。

公鑰是對(duì)外公開(kāi)的，任何人都能夠得到；私鑰只有自己知道，不能泄露。

為什么有了對(duì)稱加密后還會(huì)出現(xiàn)非對(duì)稱加密呢？

原因在于對(duì)稱加密的前提是通信雙方需要商量出一個(gè)密鑰，而商量密鑰的時(shí)候傳輸?shù)氖敲魑?，如果此密鑰被黑客所截獲，即使后面的報(bào)文進(jìn)行了加密，黑客也可以通過(guò)此密鑰進(jìn)行解密！

非對(duì)稱加密的一個(gè)特點(diǎn)是：公鑰加密，只有私鑰可以解密。那么就無(wú)需像對(duì)稱加密那樣提前協(xié)商好密鑰。通信雙方可以直接將自己的公鑰發(fā)送給另一方，這個(gè)公鑰即使黑客知道也無(wú)所謂，當(dāng)一方用此公鑰加密后，即使黑客截獲了報(bào)文，也無(wú)法用公鑰解密，只有擁有私鑰的另一方才能解密成功！

計(jì)算機(jī)網(wǎng)絡(luò)中常用的非對(duì)稱加密算法有：RSA、 ECDHE 等。

相較于對(duì)稱加密，非對(duì)稱加密算法更加復(fù)雜難懂，數(shù)學(xué)推理較多，如果對(duì)具體算法感興趣的，可以看一下阮一峰的兩篇文章：RSA 算法原理（一）和 RSA 算法原理（二）。

https://www.ruanyifeng.com/blog/2013/06/rsa_algorithm_part_one.html

http://www.ruanyifeng.com/blog/2013/07/rsa_algorithm_part_two.html

（3）混合加密

前面提到，對(duì)稱加密算法需要提前協(xié)商出密鑰，而協(xié)商的過(guò)程用的是明文（因?yàn)檫€沒(méi)有密鑰），如果黑客截獲了明文密鑰，那么之后即使加密了，黑客也可以用密鑰進(jìn)行解密，此時(shí)就無(wú)安全性可言了！

非對(duì)稱加密算法解決了此問(wèn)題，但是其存在大量的指數(shù)運(yùn)算，加密速度非常慢！而對(duì)稱加密算法的加密速度非?？欤话闶欠菍?duì)稱加密算法的 100-10000 倍！

那能不能將二者綜合起來(lái)，使得數(shù)據(jù)傳輸不僅安全且高效呢？答案是肯定的！HTTPS 采用混合加密方式，既采用對(duì)稱加密，也采用非對(duì)稱加密。

對(duì)稱加密算法的弱點(diǎn)在于協(xié)商密鑰的過(guò)程采用明文不安全，存在密鑰泄漏的可能，那么我們是不是可以不采用明文，而是采用非對(duì)稱加密算法來(lái)協(xié)商此密鑰，之后傳輸數(shù)據(jù)時(shí)再采用對(duì)稱加密算法進(jìn)行加密。

也就是說(shuō)，用非對(duì)稱加密算法傳輸密鑰，用對(duì)稱加密算法傳輸實(shí)際數(shù)據(jù)。此密鑰一般稱為『會(huì)話密鑰』。

會(huì)話密鑰通過(guò)非對(duì)稱加密算法傳輸，非常安全；

大量數(shù)據(jù)通過(guò)對(duì)稱加密算法傳輸（多次），會(huì)話密鑰只需要傳一次，非常高效！????

3. 摘要算法

摘要算法用于解決 HTTP 傳輸數(shù)據(jù)容易被篡改的問(wèn)題。

摘要算法也稱為哈希算法，其輸入為任意數(shù)據(jù)，輸出為固定長(zhǎng)度的字符串（稱為摘要）。主要特點(diǎn)如下：

不可逆，即無(wú)法通過(guò)輸出反推輸入。

相同的輸入必會(huì)產(chǎn)生相同的輸出。

不同的輸入大概率會(huì)產(chǎn)生不同的輸出。

無(wú)論輸入的數(shù)據(jù)有多長(zhǎng)，輸出摘要的長(zhǎng)度固定不變。

舉個(gè)例子：如果將數(shù)據(jù)的比特流每 8 個(gè)比特進(jìn)行分組（不足的補(bǔ)零），然后將所有分組進(jìn)行按位異或運(yùn)算，那么生成的結(jié)果就可以稱為摘要，此算法就是一種簡(jiǎn)單的摘要算法。

如果兩個(gè)輸入數(shù)據(jù)經(jīng)過(guò)摘要算法得到的輸出摘要一致，則稱為出現(xiàn)了哈希碰撞。一個(gè)好的摘要算法出現(xiàn)哈希碰撞的概率非常低，而且非常難以通過(guò)輸出猜測(cè)輸入的內(nèi)容！

計(jì)算機(jī)網(wǎng)絡(luò)中常用的摘要算法有：MD5、SHA-1、SHA-256 等。

為了防止傳輸數(shù)據(jù)被黑客所篡改，發(fā)送方除了發(fā)送實(shí)際數(shù)據(jù)外，還利用摘要算法得到數(shù)據(jù)的一個(gè)摘要，并將此摘要一并發(fā)送。

接收方收到數(shù)據(jù)后，利用同樣的摘要算法再次得到數(shù)據(jù)的摘要，并將其與發(fā)送方發(fā)送的摘要進(jìn)行比對(duì)校驗(yàn)，如果二者不一致，則說(shuō)明數(shù)據(jù)被篡改了，反之則沒(méi)有。

小伙伴們很容易看出來(lái)上述方式存在明顯缺陷，如果黑客不僅篡改了數(shù)據(jù)，而且同時(shí)篡改了摘要，接收方不就無(wú)法判斷數(shù)據(jù)是否被篡改了嗎？

為了防止這種情況的發(fā)生，發(fā)送方與接收方必須有一個(gè)只有二者知道的，而黑客不能知道的東西，比如對(duì)稱加密的會(huì)話密鑰。不過(guò)為了提升安全性，此時(shí)一般不使用會(huì)話密鑰，而是使用一個(gè)新的密鑰，稱之為鑒別密鑰，這個(gè)密鑰的獲取同會(huì)話密鑰。

有了鑒別密鑰后，摘要算法的輸入就不僅僅是傳輸數(shù)據(jù)了，而是傳輸數(shù)據(jù)和鑒別密鑰！黑客由于不知道鑒別密鑰，就無(wú)法再偽造輸入，篡改的摘要也就不正確了，從而保證了安全性！

數(shù)據(jù)和鑒別密鑰級(jí)聯(lián)后經(jīng)過(guò)摘要算法所生成的摘要有個(gè)專用名字，稱為報(bào)文鑒別碼，簡(jiǎn)稱 MAC。

為了進(jìn)一步提升安全性，實(shí)際上客戶端和服務(wù)器將使用不同的會(huì)話密鑰和鑒別密鑰，也就是一共需要四個(gè)密鑰：

用于從客戶端發(fā)送到服務(wù)器的數(shù)據(jù)的會(huì)話密鑰；

用于從服務(wù)器發(fā)送到客戶端的數(shù)據(jù)的會(huì)話密鑰；

用于從客戶端發(fā)送到服務(wù)器的數(shù)據(jù)的鑒別密鑰；

用于從服務(wù)器發(fā)送到客戶端的數(shù)據(jù)的鑒別密鑰。

4. 數(shù)字證書

數(shù)字證書用于解決 HTTP 協(xié)議中身份容易被偽造的問(wèn)題。

前面提到 HTTPS 采用非對(duì)稱加密算法傳輸會(huì)話密鑰。一般是服務(wù)器將公鑰對(duì)外公布，客戶端利用此公鑰加密會(huì)話密鑰，然后服務(wù)器通過(guò)私鑰解密得到會(huì)話密鑰，此時(shí)雙方即協(xié)商好了用于對(duì)稱加密傳輸數(shù)據(jù)的密鑰。

但是萬(wàn)一服務(wù)器的公鑰是被黑客偽造的呢？比如經(jīng)典的『中間人攻擊』問(wèn)題：

客戶端發(fā)送的請(qǐng)求被中間人（黑客）劫持（如使用 DNS 劫持），所有請(qǐng)求均發(fā)送至中間人。

中間人假裝自己是正規(guī)網(wǎng)站（服務(wù)器），向客戶端返回自己的公鑰 2 ，并索要正規(guī)網(wǎng)站的公鑰 1。

客戶端使用中間人的公鑰 2 加密會(huì)話密鑰1，并發(fā)送至中間人。

中間人使用自己的私鑰 2 解密得到會(huì)話密鑰1，同時(shí)假裝自己是客戶端，使用正規(guī)網(wǎng)站的公鑰 1 加密會(huì)話密鑰2（可以與會(huì)話密鑰 1 相同）并發(fā)送至正規(guī)網(wǎng)站。

客戶端使用會(huì)話密鑰1對(duì)數(shù)據(jù)進(jìn)行加密，并發(fā)送至中間人。

中間人使用會(huì)話密鑰1對(duì)數(shù)據(jù)進(jìn)行解密，得到明文數(shù)據(jù)！（實(shí)現(xiàn)了竊聽(tīng)）

中間人使用會(huì)話密鑰2對(duì)數(shù)據(jù)（可能是篡改的）進(jìn)行加密，并發(fā)送至正規(guī)網(wǎng)站。

此時(shí)，客戶端與服務(wù)器的通信再無(wú)安全性可言！中間人不僅能夠竊聽(tīng)到消息內(nèi)容，還能夠進(jìn)行篡改！

客戶端如何知道自己所擁有的公鑰是來(lái)自于正規(guī)網(wǎng)站而不是中間人呢？這時(shí)候就需要數(shù)字證書了！

數(shù)字證書的概念就像是我們的身份證一樣，專門用于驗(yàn)證通信實(shí)體的身份。咱們的身份證是去派出所申請(qǐng)的，而數(shù)字證書則需要向認(rèn)證中心（Certification Authority，CA）申請(qǐng)，而且是需要收費(fèi)的！

通過(guò)數(shù)字證書解決中間人攻擊的具體過(guò)程為：

服務(wù)器（正規(guī)網(wǎng)站）首先生成一對(duì)公鑰和私鑰，然后將域名、申請(qǐng)者、公鑰（注意不是私鑰，私鑰是無(wú)論如何也不能泄露的）等信息整合在一起，生成 .csr 文件，并將此文件發(fā)給認(rèn)證中心 CA。

CA 收到申請(qǐng)后，會(huì)通過(guò)各種手段驗(yàn)證申請(qǐng)者的信息，如無(wú)異常，則使用摘要算法得到 .csr 中明文信息的一個(gè)摘要，再用 CA 自己的私鑰對(duì)這個(gè)摘要進(jìn)行加密，生成一串密文，密文也稱為數(shù)字簽名。數(shù)字證書即包含此數(shù)字簽名和 .csr 中明文信息。CA 把這個(gè)證書返回給申請(qǐng)人。

為了防止中間人攻擊，客戶端要求服務(wù)器發(fā)送其證書，并進(jìn)行驗(yàn)證。

客戶端在驗(yàn)證證書時(shí)，把證書里的簽名與及明文信息分別取出來(lái)，然后會(huì)用自身攜帶的 CA 機(jī)構(gòu)的公鑰去解密簽名，得到摘要 1，再利用摘要算法得到明文信息的摘要 2，對(duì)比摘要 1 和摘要 2，如果一樣，說(shuō)明證書是合法的，也就是證書里的公鑰是正確的，否則說(shuō)明證書不合法。????

瀏覽器如何得到認(rèn)證中心的公鑰呢？萬(wàn)一此公鑰是被偽造的呢？為了防止套娃，實(shí)際電腦操作系統(tǒng)中會(huì)內(nèi)置這些認(rèn)證中心的公鑰！因而無(wú)需擔(dān)心認(rèn)證中心公鑰被偽造的問(wèn)題。

Chrome 瀏覽器一旦發(fā)現(xiàn)一個(gè)網(wǎng)站數(shù)字證書無(wú)效，就會(huì)生成如下界面進(jìn)行提示，如果用戶強(qiáng)制訪問(wèn)，則存在一定的風(fēng)險(xiǎn)。

5. SSL/TLS 握手

根據(jù)前面所述，進(jìn)行一下小結(jié)：

HTTPS 通過(guò)混合加密算法解決 HTTP 傳輸數(shù)據(jù)容易被竊聽(tīng)的問(wèn)題，此過(guò)程需要協(xié)商會(huì)話密鑰。

HTTPS 通過(guò)摘要算法解決 HTTP 傳輸數(shù)據(jù)容易被篡改的問(wèn)題，此過(guò)程需要協(xié)商鑒別密鑰。

HTTPS 通過(guò)數(shù)字證書解決 HTTP 協(xié)議中身份容易被偽造的問(wèn)題，此過(guò)程需要客戶端驗(yàn)證服務(wù)器的證書。

那么 HTTPS 具體是怎么做的呢？通信雙方在什么時(shí)候協(xié)商會(huì)話密鑰和鑒別密鑰、什么時(shí)候驗(yàn)證證書合法性的呢？答案是 SSL/TLS 協(xié)議握手的時(shí)候。

HTTPS 比 HTTP 多的那個(gè)『S』就是指 SSL/TLS 協(xié)議。

在 HTTPS 協(xié)議中，當(dāng)客戶端與服務(wù)器通過(guò)三次握手建立 TCP 連接之后，并不會(huì)直接傳輸數(shù)據(jù)，而是先會(huì)經(jīng)過(guò)一個(gè) SSL/TLS 握手的過(guò)程，用于協(xié)商會(huì)話密鑰、鑒別密鑰以及驗(yàn)證證書等，之后就可以安全傳輸數(shù)據(jù)了！

下面通過(guò) Wireshark 抓包，具體講一下 SSL/TLS 1.2 四次握手的過(guò)程。

第一次握手

客戶端向服務(wù)器發(fā)起加密通信請(qǐng)求 ，內(nèi)容主要包括：

客戶端支持的 SSL/TLS 協(xié)議版本，如 TLS 1.2 版本。

客戶端生產(chǎn)的隨機(jī)數(shù) 1，用于后續(xù)生成會(huì)話密鑰和鑒別密鑰。

客戶端支持的密碼套件列表，每個(gè)密碼套件包含：

用于傳輸會(huì)話密鑰的非對(duì)稱加密算法，如 ECDHE、RSA；

用于驗(yàn)證數(shù)字證書的非對(duì)稱加密算法，如 ECDHE、RSA；

用于傳輸數(shù)據(jù)的對(duì)稱加密算法，如 AES_128_GCM、AES_128_CBC；

用于驗(yàn)證報(bào)文完整性的摘要算法，如 SHA256、SHA384；

格式為：TLS_非對(duì)稱加密算法_非對(duì)稱加密算法_對(duì)稱加密算法_摘要算法，如果兩個(gè)非對(duì)稱加密算法一致，可省略不寫。

第二次握手

服務(wù)器收到客戶端加密通信請(qǐng)求后，向客戶端發(fā)出響應(yīng)，內(nèi)容主要包括：

確認(rèn)的 SSL/ TLS 協(xié)議版本，如果雙方支持的版本不同，則關(guān)閉加密通信。

服務(wù)器生產(chǎn)的隨機(jī)數(shù) 2，用于后續(xù)生成會(huì)話密鑰和鑒別密鑰。

確認(rèn)的密碼套件，如 TLS_RSA_WITH_AES128_CBC_SHA。

服務(wù)器的數(shù)字證書。

第三次握手

客戶端收到服務(wù)器的回應(yīng)之后，會(huì)驗(yàn)證其數(shù)字證書是否合法（驗(yàn)證方法在數(shù)字證書小節(jié)中有說(shuō)明），如果證書合法，則進(jìn)行第三次握手，內(nèi)容主要包括：

客戶端生產(chǎn)的另一個(gè)隨機(jī)數(shù) 3（稱為前主密鑰，Pre-Master Secret，簡(jiǎn)寫為 PMS），此隨機(jī)數(shù)會(huì)被服務(wù)器公鑰加密。

客戶端根據(jù)隨機(jī)數(shù) 1、隨機(jī)數(shù) 2 以及前主密鑰計(jì)算出主密鑰（Master Secret，MS），接著將主密鑰切片得到兩個(gè)會(huì)話密鑰和兩個(gè)鑒別密鑰。

加密通信算法改變通知，表示之后數(shù)據(jù)都將用會(huì)話密鑰進(jìn)行加密。

客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束?？蛻舳藭?huì)生成所有握手報(bào)文數(shù)據(jù)的摘要，并用會(huì)話密鑰加密后發(fā)送給服務(wù)器，用來(lái)供服務(wù)端校驗(yàn)。

第四次握手

服務(wù)器收到客戶端的消息后，利用自己的私鑰解密出前主密鑰，并根據(jù)隨機(jī)數(shù) 1、隨機(jī)數(shù) 2 以及前主密鑰計(jì)算出主密鑰，接著將主密鑰切片得到兩個(gè)會(huì)話密鑰和兩個(gè)鑒別密鑰。

之后進(jìn)行第四次握手，內(nèi)容主要包括：

加密通信算法改變通知，表示之后數(shù)據(jù)都將用會(huì)話密鑰進(jìn)行加密。

服務(wù)器握手結(jié)束通知，表示服務(wù)器的握手階段已經(jīng)結(jié)束。服務(wù)器會(huì)生成所有握手報(bào)文數(shù)據(jù)的摘要，并用會(huì)話密鑰加密后發(fā)送給客戶端，用來(lái)供客戶端校驗(yàn)。

至此，整個(gè) SSL/TLS 的握手階段全部結(jié)束！

為什么第三、第四次握手要發(fā)送所有握手報(bào)文的摘要呢？

主要原因是防止握手信息被篡改。比如客戶端支持的密碼套件列表中，有些加密算法較弱，有些加密算法較強(qiáng)，而此密碼套件是明文傳輸?shù)?，萬(wàn)一黑客將此密碼套件列表進(jìn)行了修改，只留下一些安全性較低的加密算法，那么服務(wù)器就只能從這些安全性較低的加密算法中選擇，安全性大大降低。因此需要通過(guò)發(fā)送摘要的形式防止握手信息被篡改。

為什么不直接發(fā)送一個(gè)主密鑰，而是用兩個(gè)隨機(jī)數(shù)加一個(gè)前主密鑰重新生成一個(gè)主密鑰呢？

主要原因是防止連接重放。如果沒(méi)有前面兩個(gè)隨機(jī)數(shù)，僅僅由客戶端生成一個(gè)主密鑰，并通過(guò)服務(wù)器公鑰加密發(fā)送給服務(wù)器。那么黑客在嗅探了服務(wù)器與客戶端之間的所有報(bào)文后，可以再次冒充客戶端向服務(wù)器發(fā)送相同的報(bào)文（雖然黑客不知道內(nèi)容是什么），因?yàn)閳?bào)文信息都是之前客戶端和服務(wù)器驗(yàn)證過(guò)的，因此服務(wù)器會(huì)認(rèn)為是客戶端與其通信，導(dǎo)致又一次連接。

假如服務(wù)器是一個(gè)購(gòu)物網(wǎng)站，那么此連接重放會(huì)導(dǎo)致客戶端再一次下單，造成損失。

而如果有了前兩個(gè)隨機(jī)數(shù)，即使黑客冒充客戶端想要連接重放，然而由于隨機(jī)數(shù)不同，生成的密鑰則不同，黑客重新發(fā)送的內(nèi)容將失效（服務(wù)器不能理解、完整性摘要也不對(duì)）。

最后，用一張圖總結(jié) TLS 四次握手的過(guò)程。

編輯：黃飛

?