柚子快報(bào)邀請(qǐng)碼778899分享：探究 HTTPS 的工作過(guò)程

http://yzkb.51969.com/

目錄

1. HTTPS 協(xié)議原理

1.1. 為什么要有HTTPS協(xié)議

1.2. 如何理解安全

1.3.?HTTPS 協(xié)議是什么

2. HTTPS 的前置概念

2.1. 什么是加密 &&?解密

2.2. 為什么要加密

2.3. 常見(jiàn)的加密方式

2.3.1. 對(duì)稱(chēng)加密

2.3.2. 非對(duì)稱(chēng)加密

2.4. 數(shù)據(jù)摘要 && 數(shù)據(jù)指紋

2.5. 數(shù)據(jù)簽名

2.6. 中間人攻擊??

2.7. 理解鏈 (承上啟下)

3. HTTPS的工作過(guò)程探究

3.1. 方案一：只使用對(duì)稱(chēng)加密

3.2. 方案二：只使用非對(duì)稱(chēng)加密

3.3. 方案三：通信雙方都使用非對(duì)稱(chēng)加密

3.4. 方案四：使用對(duì)稱(chēng)加密 + 非對(duì)稱(chēng)加密

3.5. 證書(shū)的認(rèn)識(shí)

3.5.1. CA認(rèn)證

3.5.2. 申請(qǐng)CA證書(shū)的流程 (了解)

3.5.3. CA機(jī)構(gòu)如何簽發(fā)證書(shū)的

3.6. 方案五：對(duì)稱(chēng)加密 + 非對(duì)稱(chēng)加密 + 證書(shū)認(rèn)證

3.6.1. 情景一：修改證書(shū)明文

3.6.2. 情景二：修改證書(shū)明文 + 數(shù)據(jù)簽名?

3.6.3. 證書(shū)能否整體掉包

3.6.4. 總結(jié)

3.7. 常見(jiàn)問(wèn)題

3.7.1. 為什么數(shù)據(jù)摘要在網(wǎng)絡(luò)傳輸?shù)臅r(shí)候一定要加密形成簽名？

3.7.2. 如何成為中間人 (了解)

1. HTTPS 協(xié)議原理

1.1. 為什么要有HTTPS協(xié)議

在 HTTP 文章中，我們談過(guò)，HTTP在傳輸網(wǎng)絡(luò)數(shù)據(jù)的時(shí)候，是明文傳送的，信息容易被竊聽(tīng)甚至被篡改，因此它是一個(gè)不安全的協(xié)議。

在當(dāng)今網(wǎng)絡(luò)環(huán)境中， 數(shù)據(jù)安全至關(guān)重要 (例如你的支付密碼、各種私密信息等等)，因此，為了解決這一問(wèn)題，HTTPS 協(xié)議誕生了。HTTPS（Hyper Text Transfer Protocol Secure）在 HTTP 的基礎(chǔ)上加入了 SSL/TLS 加密機(jī)制，通過(guò)對(duì)傳輸?shù)臄?shù)據(jù)進(jìn)行加密，確保數(shù)據(jù)在傳輸過(guò)程中是安全的，從而有效防止信息被竊聽(tīng)和篡改的風(fēng)險(xiǎn)，確保用戶(hù)數(shù)據(jù)的安全性，是目前互聯(lián)網(wǎng)上應(yīng)用最廣泛的安全傳輸協(xié)議。

因?yàn)?HTTP 是明文傳輸數(shù)據(jù)的，即 HTTP 不會(huì)對(duì)數(shù)據(jù)進(jìn)行保護(hù) (加密/解密)，那么另一層意思就是： HTTP 在傳輸數(shù)據(jù)時(shí)，會(huì)做更少的事情， 因此它的效率是比 HTTPS 高的。

因此，一般情況下， 如果網(wǎng)絡(luò)環(huán)境比較安全，例如在公司的內(nèi)網(wǎng)中傳輸數(shù)據(jù)，可能會(huì)優(yōu)先使用 HTTP， 以提高數(shù)據(jù)傳輸?shù)男屎徒档蛡鬏斞舆t。

當(dāng)然，如果對(duì)數(shù)據(jù)機(jī)密性和完整性要求非常高的話(huà)， 那么還是優(yōu)先使用 HTTPS 協(xié)議，確保數(shù)據(jù)在傳輸過(guò)程中受到保護(hù)。

總而言之， 使用 HTTP? 或者 HTTPS 需要根據(jù)場(chǎng)景而定。

在學(xué)習(xí) HTTP 的時(shí)候，我們也說(shuō)過(guò)，無(wú)論是 GET 或者 POST 方法傳輸網(wǎng)絡(luò)數(shù)據(jù)時(shí)，都是不安全的， POST 只不過(guò)數(shù)據(jù)具有隱秘性 (因?yàn)樗窃谡?qǐng)求正文中的)， 但隱秘性不等同于安全性。

那么問(wèn)題來(lái)了， 什么是安全呢？

1.2. 如何理解安全

首先，傳輸網(wǎng)絡(luò)數(shù)據(jù)要具有安全性，是需要對(duì)數(shù)據(jù)進(jìn)行加密的，而加密自然也要伴隨著解密的工作。即對(duì)數(shù)據(jù)加密，數(shù)據(jù)才是安全的。

可是，什么是安全呢？ 難道說(shuō)，對(duì)數(shù)據(jù)按照特定邏輯對(duì)其加密后，別人永遠(yuǎn)無(wú)法破譯，才叫安全嗎？

首先， 在我們這個(gè)世界中， 沒(méi)有絕對(duì)的安全， 就算有， 也是短暫的， 隨著各項(xiàng)技術(shù)的發(fā)展 (比如算力的發(fā)展)， 任何加密算法都一定會(huì)有漏洞的產(chǎn)生。

因此， 我們?cè)谶@里為安全下一個(gè)定義： 對(duì)數(shù)據(jù)進(jìn)行加密后， 破解這個(gè)數(shù)據(jù)的成本遠(yuǎn)遠(yuǎn)大于破解的收益， 我們就稱(chēng)之為它是安全的。比如， 對(duì)數(shù)據(jù)加密的成本只有一元錢(qián)， 但破解它需要一個(gè)億， 我們稱(chēng)這就是安全的； 再比如，對(duì)數(shù)據(jù)加密只用了一秒鐘， 但破解它需要一千年， 這也是安全的。

1.3.?HTTPS 協(xié)議是什么

在應(yīng)用層添加一個(gè)模塊， 這個(gè)模塊我們稱(chēng)之為 TLS/SSL， 這一層是可選的，一般負(fù)責(zé)對(duì)數(shù)據(jù)進(jìn)行加密和解密。如圖所示：

簡(jiǎn)而言之， 在網(wǎng)絡(luò)通信中，當(dāng) HTTP 協(xié)議使用 TLS/SSL 協(xié)議進(jìn)行加密和解密數(shù)據(jù)時(shí)，就形成了 HTTPS 協(xié)議。

簡(jiǎn)單了解一下 TLS && SSL

TLS（傳輸層安全性協(xié)議）和SSL（安全套接層協(xié)議）是用于保障網(wǎng)絡(luò)通信安全的加密通信協(xié)議。SSL 是較早的版本，而 TLS 則是SSL的繼任者，目前主要使用的是TLS協(xié)議。TLS/SSL 協(xié)議通過(guò)在通信雙方之間建立加密連接，確保數(shù)據(jù)在傳輸過(guò)程中不被竊聽(tīng)、篡改或偽造。它們使用加密算法對(duì)數(shù)據(jù)進(jìn)行加密和解密，同時(shí)通過(guò)數(shù)字證書(shū)來(lái)驗(yàn)證通信雙方的身份，保證通信的安全性和可靠性。TLS/SSL 協(xié)議廣泛應(yīng)用于Web瀏覽器和服務(wù)器之間的安全通信（HTTPS）、電子郵件系統(tǒng)、聊天應(yīng)用以及其他需要加密保護(hù)的網(wǎng)絡(luò)通信場(chǎng)景。TLS/SSL協(xié)議的使用可以有效防止中間人攻擊、數(shù)據(jù)泄露和篡改等安全威脅，是保障網(wǎng)絡(luò)通信安全的重要工具。因此，TLS/SSL 協(xié)議在網(wǎng)絡(luò)安全領(lǐng)域扮演著非常關(guān)鍵的角色。

2. HTTPS 的前置概念

2.1. 什么是加密 &&?解密

加密： 將明文進(jìn)行一系列變換，生成密文；

解密： 將密文進(jìn)行一系列變換，生成明文；

在加密和解密的過(guò)程中，往往需要一個(gè)或者多個(gè)中間數(shù)據(jù)，輔助這個(gè)過(guò)程，這樣的數(shù)據(jù)我們稱(chēng)之為密鑰。

2.2. 為什么要加密

由于 HTTP 協(xié)議傳輸?shù)臄?shù)據(jù)是明文傳輸?shù)?(在互聯(lián)網(wǎng)上，傳輸明文數(shù)據(jù)是比較危險(xiǎn)的)， 明文數(shù)據(jù)會(huì)經(jīng)過(guò)路由器、wifi 熱點(diǎn)、通信服務(wù)運(yùn)營(yíng)商、代理服務(wù)器等多個(gè)物理節(jié)點(diǎn)， 如果信息在傳輸過(guò)程中被劫持，傳輸?shù)膬?nèi)容就被泄露了， 甚至劫持者可能會(huì)篡改傳輸?shù)臄?shù)據(jù)且不被雙方察覺(jué)到， 而這就是中間人攻擊， 因此為了避免上面的問(wèn)題，我們需要對(duì)網(wǎng)絡(luò)傳輸中的數(shù)據(jù)進(jìn)行加密。

2.3. 常見(jiàn)的加密方式

2.3.1. 對(duì)稱(chēng)加密

對(duì)稱(chēng)加密是采用單鑰密碼系統(tǒng)的加密算法，即用同一個(gè)密鑰對(duì)信息進(jìn)行加密和解密， 這種方式也稱(chēng)之為單密鑰加密；對(duì)稱(chēng)加密的特征是加密和解密所用的密鑰是相同的；?常見(jiàn)對(duì)稱(chēng)加密算法 (了解)：DES、3DES、Blowfish、AES、TDEA等等；特點(diǎn)： 算法公開(kāi)(不是密鑰公開(kāi))， 計(jì)算量小， 加密解密效率高；密鑰需要私有， 不能公開(kāi)；

對(duì)稱(chēng)加密本質(zhì)上就是通過(guò)同一個(gè)密鑰，將明文加密成密文，同時(shí)也能將密文加密成明文。

一個(gè)簡(jiǎn)單的對(duì)稱(chēng)加密：按位異或。 在C我們學(xué)習(xí)過(guò)，不使用第三方變量，如何交換兩個(gè)整數(shù)，這本質(zhì)上就是一個(gè)對(duì)稱(chēng)加密。

int a = 10;

int b = 20;

std::cout << "a = " << a << ", " << " b = " << b << std::endl;

a = a ^ b;

b = a ^ b; // b = (a ^ b) ^ b = a

a = a ^ b; // a = a^ b = a ^ (a ^ b) = b

std::cout << "a = " << a << ", " << " b = " << b << std::endl;

上面的代碼本質(zhì)上是下面這個(gè)思路：

a 就相當(dāng)于明文數(shù)據(jù)， c 就相當(dāng)于密文數(shù)據(jù)， b 就相當(dāng)于一把密鑰。

a 這個(gè)明文數(shù)據(jù)通過(guò)密鑰 b 加密成了c， 就是一個(gè)加密的動(dòng)作；

c 這個(gè)密文數(shù)據(jù)再通過(guò)密鑰 b 解密成了a， 就是一個(gè)解密的動(dòng)作。

因此， 這里的 b 實(shí)質(zhì)上是一個(gè)對(duì)稱(chēng)密鑰。

2.3.2. 非對(duì)稱(chēng)加密

非對(duì)稱(chēng)加密需要兩個(gè)密鑰來(lái)進(jìn)行加密和解密， 這兩個(gè)密鑰分別是公開(kāi)密鑰 (public key， 簡(jiǎn)稱(chēng)公鑰) 和 私有密鑰? (private key， 簡(jiǎn)稱(chēng)私鑰)。

對(duì)外公開(kāi)的密鑰就是公鑰， 自己私有的密鑰就是私鑰；公鑰和私鑰必須配對(duì)使用；常見(jiàn)非對(duì)稱(chēng)加密算法 (了解)：RSA、DSA、ECDSA；特點(diǎn)：算法強(qiáng)度復(fù)雜， 安全性依賴(lài)于算法和密鑰， 但是由于算法復(fù)雜，使得加密和解密速度沒(méi)有對(duì)稱(chēng)密鑰快，效率比對(duì)稱(chēng)密鑰慢；沒(méi)有強(qiáng)制誰(shuí)必須加密，誰(shuí)必須解密。 但要求一方負(fù)責(zé)加密數(shù)據(jù)，那么另一方就需要負(fù)責(zé)解密數(shù)據(jù)；比如， 如果是用公鑰對(duì)明文進(jìn)行加密形成密文，那么就必須用私鑰對(duì)密文進(jìn)行解密形成明文，同時(shí)，由于私鑰是私有的，故只有持有這個(gè)私鑰的人才能進(jìn)行解密，得到明文；如果用私鑰對(duì)明文加密形成密文， 那么就必須用公鑰對(duì)密文進(jìn)行解密形成明文，同時(shí)，由于公鑰是對(duì)外公開(kāi)的， 故實(shí)際上，這個(gè)數(shù)據(jù)也是對(duì)外公開(kāi)的；

2.4. 數(shù)據(jù)摘要 && 數(shù)據(jù)指紋

數(shù)據(jù)摘要也稱(chēng)之為數(shù)字指紋， 其基本原理是利用單向散列函數(shù) (Hash函數(shù)) 對(duì)信息進(jìn)行運(yùn)算， 生成一固定長(zhǎng)度的數(shù)字摘要。

數(shù)字摘要并不是一種加密機(jī)制， 因?yàn)椋?如果是加密，那么必然要有解密，而哈希是無(wú)法逆推的，一旦對(duì)原始文本經(jīng)過(guò) Hash 形成數(shù)據(jù)摘要， 很難 (幾乎不可能) 根據(jù)數(shù)據(jù)摘要逆推原始文本；數(shù)字摘要主要用來(lái)判斷數(shù)據(jù)有沒(méi)有被篡改；摘要常見(jiàn)算法：有MD5、SHA1、SHA256、SHA512等；這些 Hash 算法有個(gè)特點(diǎn)： 任意的文本， 經(jīng)過(guò) Hash?形成的摘要，都是不一樣的， 哪怕之更改一點(diǎn)點(diǎn)內(nèi)容所形成的數(shù)據(jù)摘要也是千差萬(wàn)別的，因此碰撞概率非常低；這里的數(shù)據(jù)摘要就可以理解為原始文本形成的指紋，因此我們也稱(chēng)之為數(shù)據(jù)指紋；?

2.5. 數(shù)據(jù)簽名

數(shù)據(jù)摘要經(jīng)過(guò)加密， 就得到了數(shù)據(jù)簽名。

2.6. 中間人攻擊??

中間人攻擊（Man-in-the-Middle Attack，簡(jiǎn)稱(chēng)MITM攻擊）是一種網(wǎng)絡(luò)攻擊手段，其中攻擊者插入自己在通信雙方之間，以獲取或篡改雙方之間傳輸?shù)男畔?。在HTTP/HTTPS中，中間人攻擊可能發(fā)生在通信的任何環(huán)節(jié)，導(dǎo)致通信雙方被欺騙以為他們正在直接通信。

2.7. 理解鏈 (承上啟下)

對(duì) HTTP 只進(jìn)行對(duì)稱(chēng)加密， 能否解決數(shù)據(jù)通信安全的問(wèn)題？ 如果不能， 問(wèn)題是什么？

為什么要用非對(duì)稱(chēng)加密？

為什么不全用非對(duì)稱(chēng)加密？

為了解決上面的疑問(wèn)， 我們需要對(duì) HTTPS 的工作過(guò)程進(jìn)行探究；

3. HTTPS的工作過(guò)程探究

經(jīng)過(guò)上面的分析， 我們能明白一點(diǎn)： 要保證網(wǎng)路傳輸?shù)臄?shù)據(jù)是安全的， 那么就需要對(duì)數(shù)據(jù)進(jìn)行加密。換句話(huà)說(shuō)， 網(wǎng)絡(luò)傳輸不能直接傳輸明文數(shù)據(jù)， 而應(yīng)該傳輸加密后的密文數(shù)據(jù)。加密的方式很多， 但是整體都可以分為兩大類(lèi)， 對(duì)稱(chēng)加密 && 非對(duì)稱(chēng)加密；

3.1. 方案一：只使用對(duì)稱(chēng)加密

如果通信雙方都持有同一個(gè)密鑰X， 且沒(méi)有其他人知道， 那么此時(shí)雙方通信數(shù)據(jù)的安全就可以保證， 如下：

由于此時(shí)這把對(duì)稱(chēng)密鑰只有通信雙方知道， 因此， 即使中間人截取了這個(gè)請(qǐng)求， 因?yàn)椴恢烂荑€， 也無(wú)法對(duì)其進(jìn)行解密， 也就無(wú)法監(jiān)聽(tīng)篡改內(nèi)容了。

但是，事實(shí)上，由于服務(wù)端是可能為多個(gè)客戶(hù)端提供服務(wù)的， 因此，一般情況下， 每個(gè)客戶(hù)端所用的對(duì)稱(chēng)密鑰都應(yīng)該是不同的 (如果是相同的，那么太容易擴(kuò)散了，中間人可以輕而易舉的獲取到)。?

因此，服務(wù)器就需要維護(hù)每個(gè)客戶(hù)端和每個(gè)密鑰的關(guān)系。?

但是，現(xiàn)在問(wèn)題就來(lái)了， 這么多客戶(hù)端和密鑰， 服務(wù)端如何得知客戶(hù)端使用的是哪一把密鑰呢？

那么是不是需要服務(wù)端將自己的密鑰傳輸給客戶(hù)端，讓客戶(hù)端使用特定的密鑰和我通信呢？

可是，如果用網(wǎng)絡(luò)傳送這個(gè)密鑰，那這個(gè)密鑰不就可以被劫持了嗎？因?yàn)槲疫@把密鑰是用來(lái)保護(hù)后續(xù)網(wǎng)絡(luò)傳輸信息的安全，可是，誰(shuí)來(lái)保護(hù)我這個(gè)密鑰的安全呢？?如果密鑰都泄露了， 那后續(xù)的信息，就無(wú)法保證安全性了。 這就是一個(gè)典型的雞生蛋，蛋生雞的問(wèn)題了。

因此， 上面問(wèn)題的關(guān)鍵不在于誰(shuí)提供這一把密鑰，最主要的問(wèn)題是持有密鑰的一方，如何讓另一方安全的獲得這把密鑰呢？

我們可以發(fā)現(xiàn)，上面的問(wèn)題本質(zhì)：持有對(duì)稱(chēng)密鑰的一方，如何讓對(duì)方安全獲得這把密鑰？?即這把密鑰也是需要加密傳輸 (安全性) 的。

因此， 只用對(duì)稱(chēng)密鑰無(wú)法解決上面的問(wèn)題。

3.2. 方案二：只使用非對(duì)稱(chēng)加密

前提條件：

服務(wù)端具有非對(duì)稱(chēng)公鑰S，私鑰S'；

客戶(hù)端發(fā)起請(qǐng)求； 服務(wù)端收到后， 將自己的公鑰S附加到響應(yīng)中，傳輸給客戶(hù)端 (服務(wù)端有自己的私鑰S'，且只有服務(wù)端知道)； 客戶(hù)端收到響應(yīng)后，提取公鑰S，通過(guò)公鑰S對(duì)數(shù)據(jù)進(jìn)行加密，形成密文，向服務(wù)端傳輸密文。因?yàn)楸还€加密的數(shù)據(jù)，在這個(gè)世界上，只有擁有與之匹配的私鑰的人才能夠解密， 因此，即使此時(shí)中間人來(lái)了，就算他拿到了公鑰S以及網(wǎng)絡(luò)傳輸?shù)拿芪模?他也無(wú)法對(duì)其進(jìn)行解密，信息也無(wú)法被監(jiān)聽(tīng)篡改。服務(wù)端收到之后，通過(guò)私鑰S'對(duì)其傳輸?shù)男畔⑦M(jìn)行解密，就會(huì)得到明文數(shù)據(jù)。

上面的過(guò)程好像已經(jīng)保證了數(shù)據(jù)在傳輸是安全的 (真的嗎？) 。

但是，事實(shí)上，上面的場(chǎng)景只能滿(mǎn)足客戶(hù)端向服務(wù)端發(fā)送信息是安全的， 可是服務(wù)端向客戶(hù)端發(fā)送消息呢，此時(shí)還是安全的嗎？

服務(wù)端向客戶(hù)端發(fā)送消息 (密文)， 該消息是被私鑰加密的?？蛻?hù)端收到后， 用公鑰對(duì)消息進(jìn)行解密，得到了服務(wù)端發(fā)送的明文數(shù)據(jù)?？墒牵袉?wèn)題啊， 這把公鑰不是對(duì)外公開(kāi)的嗎？ 換言之， 中間人完全可以拿到這把公鑰啊， 如果服務(wù)端在發(fā)送數(shù)據(jù)的時(shí)候，中間人劫持了數(shù)據(jù)， 并通過(guò)公鑰對(duì)其進(jìn)行解密， 這不就導(dǎo)致信息被泄露了嗎？ 這如何能體現(xiàn)安全呢？

因此，只使用非對(duì)稱(chēng)加密也是無(wú)法保證客戶(hù)端和服務(wù)端互相通信時(shí)信息的安全性，最多只能保證單向通信的安全。

不僅于此， 方案二還有一個(gè)隱藏的安全問(wèn)題，這個(gè)問(wèn)題在方案二、三、四都存在，我們?cè)诜桨杆慕忉尅?/p>

3.3. 方案三：通信雙方都使用非對(duì)稱(chēng)加密

前提條件：

服務(wù)端具有非對(duì)稱(chēng)公鑰S，私鑰S'；

客戶(hù)端具有非對(duì)稱(chēng)公鑰M，私鑰M'；

客戶(hù)端向服務(wù)端發(fā)起請(qǐng)求 (明文)， 將自己的公鑰M傳給服務(wù)端。服務(wù)端收到請(qǐng)求后， 并向客戶(hù)端發(fā)起響應(yīng) (明文)，將自己的公鑰S傳給客戶(hù)端。此時(shí)， 客戶(hù)端有自己的私鑰M'以及服務(wù)端的公鑰S (當(dāng)然也有自己的公鑰M，在這就不考慮了)；服務(wù)端有自己的私鑰S'以及客戶(hù)端的公鑰M。當(dāng)然， 中間人經(jīng)過(guò)上面的網(wǎng)絡(luò)傳輸完全可以獲得到客戶(hù)端和服務(wù)端的公鑰?？蛻?hù)端向服務(wù)端發(fā)送信息 (密文)，該信息是通過(guò)服務(wù)端的公鑰S進(jìn)行加密的， 經(jīng)過(guò)網(wǎng)絡(luò)，發(fā)送給服務(wù)端， 此時(shí)就算中間人獲得了這個(gè)數(shù)據(jù)， 也無(wú)法對(duì)其進(jìn)行解密，因?yàn)橹虚g人沒(méi)有服務(wù)端的私鑰S'。服務(wù)端收到之后，用服務(wù)端的私鑰S'對(duì)其進(jìn)行解密，得到了客戶(hù)端發(fā)送的明文。同理， 服務(wù)端向客戶(hù)端發(fā)送信息 (密文)， 該信息需要被客戶(hù)端的公鑰M進(jìn)行加密， 通過(guò)網(wǎng)絡(luò)傳輸給客戶(hù)端， 客戶(hù)端收到之后，利用客戶(hù)端的私鑰M'對(duì)其進(jìn)行解密。就得到了服務(wù)端發(fā)送的明文數(shù)據(jù)。

此時(shí)，服務(wù)端和客戶(hù)端都采用對(duì)稱(chēng)加密的方案，并在通信之前，交互雙方的公鑰，然后后續(xù)就可以保證雙方信息傳輸?shù)陌踩浴?/p>

看似沒(méi)有任何問(wèn)題， 但實(shí)際上，依舊存在著一個(gè)安全問(wèn)題?(這個(gè)問(wèn)題和方案二隱藏的問(wèn)題一模一樣)， 這個(gè)隱患我們?cè)诜桨杆慕忉尅?/p>

但是我們知道，非對(duì)稱(chēng)加密算法復(fù)雜，潛臺(tái)詞就是它比對(duì)稱(chēng)加密所做的工作更多，即加密和解密的效率更低， 那么在這里雙方都是用非對(duì)稱(chēng)加密，那么效率太低了， 能不能在保證安全的前提下，提高效率呢？

3.4. 方案四：使用對(duì)稱(chēng)加密 + 非對(duì)稱(chēng)加密

先解決效率問(wèn)題。

前提條件：

服務(wù)端采用非對(duì)稱(chēng)加密 (公鑰S，私鑰S')；

客戶(hù)端采用對(duì)稱(chēng)加密，密鑰M；

客戶(hù)端向服務(wù)端發(fā)起請(qǐng)求；服務(wù)端收到請(qǐng)求后，并向客戶(hù)端發(fā)送響應(yīng) (明文)，將自己的公鑰S傳輸給客戶(hù)端。 當(dāng)然， 中間人完全可以獲得服務(wù)端的公鑰S。客戶(hù)端收到服務(wù)端的公鑰S之后， 因?yàn)榭蛻?hù)端采用的是對(duì)稱(chēng)加密，有一把密鑰M， 因此， 客戶(hù)端就用服務(wù)端傳過(guò)來(lái)的公鑰S對(duì)客戶(hù)端自己的密鑰M進(jìn)行加密， 加密之后，通過(guò)網(wǎng)絡(luò)傳輸給服務(wù)端。 由于中間人沒(méi)有服務(wù)端的私鑰S'，因此，無(wú)法對(duì)網(wǎng)絡(luò)傳輸?shù)男畔⑦M(jìn)行解密。服務(wù)端收到加密后的信息，用自己的私鑰S'對(duì)其進(jìn)行解密。就得到了客戶(hù)端的唯一的公鑰M。此時(shí)，就達(dá)到了一種目的， 客戶(hù)端的這把密鑰M，只有客戶(hù)端和服務(wù)端雙方知道，因此后續(xù)雙方就可以通過(guò)這把密鑰M對(duì)數(shù)據(jù)進(jìn)行加密解密，保證數(shù)據(jù)傳輸?shù)陌踩?。由于?duì)稱(chēng)加密的加密解密成本低，因此，此時(shí)既保證了傳輸數(shù)據(jù)的安全也提高了效率。

總結(jié)：

通過(guò)非對(duì)稱(chēng)加密保證對(duì)稱(chēng)密鑰的安全，讓這把對(duì)稱(chēng)密鑰安全的讓另一方得到， 這個(gè)階段我們稱(chēng)之為密鑰協(xié)商階段；

后續(xù)通過(guò)這把對(duì)稱(chēng)密鑰安全地進(jìn)行網(wǎng)絡(luò)傳輸數(shù)據(jù)，我們稱(chēng)之為數(shù)據(jù)通信階段；

這樣就好了嗎？ 就一定安全了嗎？?

首先，我們要知道， 中間人不僅可以讀數(shù)據(jù)， 還可以寫(xiě)數(shù)據(jù)， 換言之，它是有可能對(duì)數(shù)據(jù)進(jìn)行篡改的。

實(shí)際上，方案二、三、四都存在一個(gè)潛在的問(wèn)題， 如果最開(kāi)始的時(shí)候，中間人就開(kāi)始攻擊了呢？即中間人在密鑰協(xié)商的過(guò)程中就開(kāi)始攻擊了呢？此時(shí)就出現(xiàn)問(wèn)題了。

中間人攻擊 Man-in-the-MiddleAttack，簡(jiǎn)稱(chēng) MITM 攻擊；

我們就以方案四舉例：?

前提條件：

服務(wù)端采用非對(duì)稱(chēng)加密 (公鑰S，私鑰S')；

中間人采用非對(duì)稱(chēng)加密 (公鑰K，私鑰K')；

客戶(hù)端采用對(duì)稱(chēng)加密，密鑰X；

客戶(hù)端向服務(wù)端發(fā)起請(qǐng)求；服務(wù)端明文傳輸公鑰S給客戶(hù)端；注意：此時(shí)，中間人劫持了數(shù)據(jù)報(bào)文，得到公鑰S，并保存好， 其次，中間人還將公鑰S替換成自己的公鑰K，并將偽造后的報(bào)文發(fā)送給客戶(hù)端?？蛻?hù)端收到報(bào)文，對(duì)于客戶(hù)端而言，他并不知道自己收到的報(bào)文已經(jīng)被篡改過(guò)，他依舊認(rèn)為自己獲得的是服務(wù)端發(fā)送的原始報(bào)文，提取公鑰，得到的是公鑰K (已被篡改)， 客戶(hù)端形成自己的對(duì)稱(chēng)密鑰X，通過(guò)公鑰K對(duì)其進(jìn)行加密，形成報(bào)文發(fā)送給服務(wù)端。中間人又劫持了該報(bào)文，因?yàn)橹虚g人是有私鑰K'的，因此，可以對(duì)這個(gè)報(bào)文進(jìn)行解密，得到通信的對(duì)稱(chēng)密鑰X，并在通過(guò)第一次劫持?jǐn)?shù)據(jù)報(bào)文獲得的服務(wù)端公鑰S對(duì)對(duì)稱(chēng)密鑰X進(jìn)行加密，將報(bào)文推送給服務(wù)端。服務(wù)端拿到報(bào)文之后，用自己的私鑰S'對(duì)其進(jìn)行解密，得到了對(duì)稱(chēng)密鑰X。此時(shí)，對(duì)于服務(wù)端和客戶(hù)端而言，他們認(rèn)為只有他們雙方知道這把對(duì)稱(chēng)密鑰X， 因此認(rèn)為，未來(lái)通過(guò)這把對(duì)稱(chēng)密鑰X進(jìn)行網(wǎng)絡(luò)傳輸是安全的。但實(shí)際上， 這把對(duì)稱(chēng)密鑰X還有第三方知道，即中間人也知道這把對(duì)稱(chēng)密鑰X。因此，未來(lái)服務(wù)端和客戶(hù)端在進(jìn)行網(wǎng)絡(luò)傳輸數(shù)據(jù)時(shí)，中間人可以通過(guò)這把對(duì)稱(chēng)密鑰X隨意劫持?jǐn)?shù)據(jù)，進(jìn)行竊聽(tīng)甚至修改。

因此，無(wú)論是方案二、三、四都存在這個(gè)隱藏的安全問(wèn)題， 無(wú)法保證雙方通信是的數(shù)據(jù)安全。

那么該如何解決這個(gè)問(wèn)題呢？

我們發(fā)現(xiàn)，只要通信雙方已經(jīng)交換了密鑰了 (密鑰協(xié)商)，中間人來(lái)了就晚了， 而中間人在最開(kāi)始的時(shí)候 (在密鑰協(xié)商完成之前)，就可以進(jìn)行監(jiān)聽(tīng)篡改數(shù)據(jù)。

中間人之所以能夠成功的本質(zhì)： 中間人可以對(duì)數(shù)據(jù)進(jìn)行篡改 && 客戶(hù)端無(wú)法驗(yàn)證收到的公鑰是合法的 (服務(wù)端的公鑰)。

有沒(méi)有一種方式確定，客戶(hù)端收到的公鑰就是服務(wù)端傳輸?shù)墓€， 中間人一旦進(jìn)行篡改， 客戶(hù)端就會(huì)判別出來(lái)。

因此， 我們需要引入證書(shū)。

3.5. 證書(shū)的認(rèn)識(shí)

為了解決上面的問(wèn)題， 客戶(hù)端需要對(duì)服務(wù)器公鑰的合法性進(jìn)行認(rèn)證。

3.5.1. CA認(rèn)證

服務(wù)端在使用HTTPS之前， 需要向CA機(jī)構(gòu)申請(qǐng)一份數(shù)字證書(shū)， 數(shù)字證書(shū)里包含了申請(qǐng)者信息、服務(wù)端的公鑰等等。

服務(wù)器把證書(shū)傳輸給瀏覽器， 瀏覽器從證書(shū)里獲取服務(wù)端的公鑰就行了， 證書(shū)就如同現(xiàn)實(shí)生活中的身份證， 身份證標(biāo)明一個(gè)人的合法性，而CA證書(shū)，就標(biāo)明了服務(wù)端公鑰的合法性。?

如果需要用證書(shū)來(lái)證明服務(wù)端公鑰的合法性，那么就必須要有：

一個(gè)權(quán)威機(jī)構(gòu)，CA機(jī)構(gòu)， 它是一個(gè)全球性的機(jī)構(gòu)；CA機(jī)構(gòu)需要頒發(fā)相關(guān)證書(shū)，? CA證書(shū)。

有了證書(shū)之后， 我們的問(wèn)題就發(fā)生變化了。

以前我們的問(wèn)題是： 保證服務(wù)端公鑰的合法性。

現(xiàn)在問(wèn)題就是： 保證證書(shū)的合法性。

證書(shū)里面包含的公鑰， 就是上面服務(wù)端給客戶(hù)端要推送的公鑰， 也就是服務(wù)端的公鑰。

未來(lái)，服務(wù)到和客戶(hù)端在進(jìn)行密鑰協(xié)商之前， 服務(wù)端推送的是證書(shū)，不僅僅是服務(wù)端的公鑰， 通過(guò)證書(shū)確保服務(wù)端公鑰的合法性。

只要證書(shū)是合法的， 那么證書(shū)里面的公鑰就一定是服務(wù)端的公鑰。

因?yàn)樽C書(shū)也有可能被造假， 甚至整體掉包，因此客戶(hù)端需要證明證書(shū)是合法的， 這里的合法不僅指的是這個(gè)證書(shū)是真的， 還需要證明這個(gè)證書(shū)是客戶(hù)端需要的證書(shū)；

3.5.2. 申請(qǐng)CA證書(shū)的流程 (了解)

上面的證書(shū)可以理解成一個(gè)結(jié)構(gòu)化的字符串， 里邊包含了如下信息：

證書(shū)發(fā)布機(jī)構(gòu)證書(shū)有效期公鑰 (服務(wù)端的公鑰)證書(shū)所有者簽名......

需要注意的是：申請(qǐng)證書(shū)的時(shí)候，需要在特定平臺(tái)下生成，同時(shí)會(huì)生成一對(duì)密鑰對(duì)，即服務(wù)端的公鑰和私鑰。

其中公鑰會(huì)隨著CSR文件，一起發(fā)給CA進(jìn)行權(quán)威認(rèn)證，私鑰服務(wù)端自己保留，用來(lái)后續(xù)進(jìn)行通信 (其實(shí)主要就是用來(lái)交換客戶(hù)端生成的對(duì)稱(chēng)秘鑰)；

3.5.3. CA機(jī)構(gòu)如何簽發(fā)證書(shū)的

理解數(shù)據(jù)簽名

數(shù)據(jù)簽名是基于非對(duì)稱(chēng)加密算法的， 對(duì)數(shù)據(jù)摘要進(jìn)行加密就得到了數(shù)據(jù)簽名。

當(dāng)服務(wù)端申請(qǐng)CA證書(shū)的時(shí)候， CA機(jī)構(gòu)會(huì)對(duì)該服務(wù)端進(jìn)行審核， 并專(zhuān)門(mén)為服務(wù)端形成數(shù)字簽名， 過(guò)程如下：

CA機(jī)構(gòu)擁有非對(duì)稱(chēng)加密的公鑰S和私鑰S'；CA機(jī)構(gòu)對(duì)服務(wù)端申請(qǐng)的證書(shū)明文數(shù)據(jù)進(jìn)行Hash，得到數(shù)據(jù)摘要。CA機(jī)構(gòu)用自己的私鑰S' 對(duì)形成的數(shù)據(jù)摘要進(jìn)行加密得到數(shù)據(jù)簽名M。

此時(shí)，服務(wù)端申請(qǐng)的證書(shū)明文和數(shù)字簽名M共同組成了數(shù)字證書(shū)， 這樣的一份數(shù)字證書(shū)就可以頒發(fā)給服務(wù)端了。

3.6. 方案五：對(duì)稱(chēng)加密 + 非對(duì)稱(chēng)加密 + 證書(shū)認(rèn)證

前提條件： 服務(wù)端采用非對(duì)稱(chēng)加密，公鑰X，私鑰X'；

CA機(jī)構(gòu)采用非對(duì)稱(chēng)加密，公鑰Y，私鑰Y'；

中間人采用非對(duì)稱(chēng)加密， 公鑰H，私鑰H'；

客戶(hù)端采用對(duì)稱(chēng)加密，密鑰Q；

客戶(hù)端和服務(wù)端剛建立連接的時(shí)候 (密鑰協(xié)商之前)， 服務(wù)端返回給客戶(hù)端一個(gè) 證書(shū)，證書(shū)包含了服務(wù)端的公鑰， 也包含了網(wǎng)站的身份信息。

如果在傳輸證書(shū)的時(shí)候，中間人來(lái)截獲證書(shū)了呢？?

首先， 由于證書(shū)是以明文傳輸?shù)模?中間人完全可以截獲這個(gè)證書(shū)。

因此， 客戶(hù)端在密鑰協(xié)商階段之前， 必須對(duì)證書(shū)進(jìn)行驗(yàn)證。 在這里，我們列出中間人攻擊的情景：

3.6.1. 情景一：修改證書(shū)明文

服務(wù)端向客戶(hù)端明文發(fā)送證書(shū)，被中間人截獲；中間人修改了證書(shū)明文，客戶(hù)端收到后對(duì)其進(jìn)行認(rèn)證；由于中間人修改了證書(shū)明文，因此，客戶(hù)端再認(rèn)證的時(shí)候，證書(shū)明文所形成的數(shù)據(jù)摘要一定有了變化；客戶(hù)端在用CA機(jī)構(gòu)的公鑰Y解密數(shù)據(jù)簽名得到數(shù)據(jù)摘要；此時(shí)這兩個(gè)數(shù)據(jù)摘要一定不相等，故客戶(hù)端判斷，證書(shū)已被篡改，從而終止向服務(wù)端傳輸信息，防止將信息泄露給中間人；

首先，我們要知道：

其一：證書(shū)里面的數(shù)據(jù)簽名是由CA機(jī)構(gòu)的私鑰Y'加密得到的，而CA機(jī)構(gòu)的私鑰Y'，只有CA自己知道，中間人不可能知道。

其二：客戶(hù)端 (瀏覽器) 一般是會(huì)內(nèi)置CA機(jī)構(gòu)的公鑰Y的。

在情景一中，中間人只對(duì)證書(shū)明文做了修改， 而由于CA機(jī)構(gòu)的公鑰Y是對(duì)外公開(kāi)的， 因此，中間人完全可以通過(guò)CA的公鑰Y解密數(shù)據(jù)簽名，得到數(shù)據(jù)摘要，即也可以篡改數(shù)據(jù)摘要。

基于上面的理解，我們推出情景二：

3.6.2. 情景二：修改證書(shū)明文 + 數(shù)據(jù)簽名?

服務(wù)端向客戶(hù)端明文發(fā)送證書(shū)，被中間人截獲；此時(shí)，中間人不僅修改了證書(shū)明文，并對(duì)修改后的證書(shū)明文重新 Hash 得到新的數(shù)據(jù)摘要；且通過(guò)自己的私鑰H'對(duì)新的數(shù)據(jù)摘要進(jìn)行加密得到新的數(shù)據(jù)簽名；同時(shí)，中間人還將自己的數(shù)據(jù)簽名把CA機(jī)構(gòu)形成的數(shù)據(jù)簽名替換。 那么此時(shí)客戶(hù)端可以識(shí)別出來(lái)嗎？客戶(hù)端當(dāng)然可以識(shí)別，?因?yàn)榭蛻?hù)端不會(huì)用中間人的公鑰來(lái)驗(yàn)證證書(shū)是否合法，客戶(hù)端也不想知道中間人的公鑰，客戶(hù)端只會(huì)用瀏覽器內(nèi)置的CA機(jī)構(gòu)的公鑰Y來(lái)驗(yàn)證證書(shū)是否合法， 因此，即便中間人篡改了證書(shū)明文，也篡改了數(shù)據(jù)簽名，但客戶(hù)端依舊能夠識(shí)別出來(lái)。 一旦客戶(hù)端識(shí)別到證書(shū)被篡改，就會(huì)終止向服務(wù)端傳輸信息，防止將信息泄露給中間人；

因此，我們的總結(jié)：

中間人只要篡改了證書(shū)， 客戶(hù)端一定可以識(shí)別出來(lái)， 因此， 只要客戶(hù)端驗(yàn)證了證書(shū)是合法的，那么就能間接證明證書(shū)里的公鑰一定是服務(wù)端的公鑰。

由于中間人無(wú)法合法的篡改證書(shū)， 那么也無(wú)法將證書(shū)中的服務(wù)端的公鑰給替換成自己的公鑰， 也就解決了方案二、三、四中的問(wèn)題。

3.6.3. 證書(shū)能否整體掉包

既然中間人不能合法的篡改證書(shū)， 那能否整體掉包呢？

中間人無(wú)法合法篡改證書(shū)：由于中間人沒(méi)有CA私鑰，因此無(wú)法創(chuàng)建一個(gè)由CA機(jī)構(gòu)簽發(fā)的合法證書(shū)，因此中間人只能自己偽造證書(shū)，但這些偽造的證書(shū)將不會(huì)被客戶(hù)端信任，因?yàn)樗鼈兊暮灠l(fā)者不是可信的CA機(jī)構(gòu)；客戶(hù)端能夠識(shí)別證書(shū)被整體掉包：由于中間人無(wú)法制作合法的證書(shū)，因此， 中間人只能向CA機(jī)構(gòu)申請(qǐng)合法證書(shū)， 用自己申請(qǐng)的合法證書(shū)進(jìn)行整體掉包，雖然能夠做到證書(shū)的整體掉包，但是證書(shū)可不僅僅只包含數(shù)據(jù)簽名，它還包含一些與服務(wù)端相關(guān)的信息，如域名等。因此，如果證書(shū)被整體掉包了，客戶(hù)端也會(huì)識(shí)別出來(lái)；驗(yàn)證成功的證書(shū)一定包含服務(wù)端公鑰：在SSL/TLS握手過(guò)程中，客戶(hù)端會(huì)驗(yàn)證服務(wù)器提供的證書(shū)，只要驗(yàn)證成功，那么證書(shū)里面的公鑰一定是服務(wù)端的公鑰。

總而言之， 不管中間人對(duì)證書(shū)做如何篡改， 客戶(hù)端都能識(shí)別出來(lái)；

最后，在強(qiáng)調(diào)一點(diǎn)， 中間人沒(méi)有CA私鑰， 因此，無(wú)法對(duì)任何證書(shū)進(jìn)行合法篡改， 包括中間人自己的證書(shū)。

3.6.4. 總結(jié)

HTTPS通常采用的是混合加密機(jī)制，包括非對(duì)稱(chēng)加密（公鑰加密）、對(duì)稱(chēng)加密和證書(shū)認(rèn)證。

非對(duì)稱(chēng)加密（公鑰加密）：在連接的初始階段 (密鑰協(xié)商階段之前)，服務(wù)器會(huì)將其公鑰以數(shù)字證書(shū)的形式發(fā)送給客戶(hù)端?？蛻?hù)端使用服務(wù)器的公鑰來(lái)加密一個(gè)對(duì)稱(chēng)密鑰，并將其發(fā)送給服務(wù)器。這一過(guò)程確保了通信的機(jī)密性，因?yàn)橹挥蟹?wù)器擁有相應(yīng)的私鑰才能解密這個(gè)對(duì)稱(chēng)密鑰；對(duì)稱(chēng)加密：一旦客戶(hù)端和服務(wù)器之間建立了共享的對(duì)稱(chēng)密鑰，之后的通信將使用對(duì)稱(chēng)加密算法來(lái)加密和解密數(shù)據(jù)。對(duì)稱(chēng)加密的優(yōu)勢(shì)在于其高效性，因?yàn)橄鄬?duì)于非對(duì)稱(chēng)加密，對(duì)稱(chēng)加密的加密解密速度更快；證書(shū)認(rèn)證：數(shù)字證書(shū)用于驗(yàn)證服務(wù)器的身份?？蛻?hù)端會(huì)檢查服務(wù)器發(fā)送的數(shù)字證書(shū)，驗(yàn)證其是否由受信任的證書(shū)頒發(fā)機(jī)構(gòu)簽發(fā)，以及證書(shū)中的信息是否與連接的實(shí)際服務(wù)器匹配。如果證書(shū)驗(yàn)證成功，客戶(hù)端就可以信任服務(wù)器的身份。

證書(shū)的作用

證書(shū)的作用是用來(lái)驗(yàn)證服務(wù)器的身份，并確保通信的安全性。如果證書(shū)被篡改，客戶(hù)端通常會(huì)發(fā)出警告或者直接拒絕連接，從而防止中間人攻擊的發(fā)生。?

HTTPS 工作過(guò)程中涉及到的密鑰有三組：

第一組(非對(duì)稱(chēng)加密，CA的公鑰和私鑰)：用于簽發(fā)和驗(yàn)證數(shù)字證書(shū)，防止中間人篡改證書(shū)。CA機(jī)構(gòu)用自己的私鑰對(duì)數(shù)據(jù)摘要加密形成數(shù)據(jù)簽名，其與證書(shū)明文共同組成數(shù)字證書(shū)；服務(wù)端在客戶(hù)端請(qǐng)求后，返回?cái)y帶簽名的證書(shū)，客戶(hù)端通過(guò) CA 機(jī)構(gòu)的公鑰進(jìn)行證書(shū)驗(yàn)證，保證證書(shū)的合法性 (確保證書(shū)中的公鑰是服務(wù)端的公鑰)，進(jìn)一步保證證書(shū)中攜帶的服務(wù)端公鑰的權(quán)威性；第二組(非對(duì)稱(chēng)加密，服務(wù)端的公鑰和私鑰)：用于密鑰協(xié)商，對(duì)客戶(hù)端的對(duì)稱(chēng)密鑰進(jìn)行加密。客戶(hù)端用收到的CA證書(shū)中的公鑰 (也就是服務(wù)端的公鑰?) 給客戶(hù)端隨機(jī)生成的對(duì)稱(chēng)加密的密鑰加密，傳輸給服務(wù)器，服務(wù)器通過(guò)自己的私鑰解密獲取到對(duì)稱(chēng)密鑰；第三組(對(duì)稱(chēng)加密)：客戶(hù)端和服務(wù)器后續(xù)傳輸?shù)臄?shù)據(jù)都通過(guò)這個(gè)對(duì)稱(chēng)密鑰加密解密，保證數(shù)據(jù)安全。

其實(shí)一切的關(guān)鍵都是圍繞這個(gè)對(duì)稱(chēng)加密的密鑰，其他的機(jī)制都是輔助這個(gè)密鑰工作的。

第二組非對(duì)稱(chēng)加密的密鑰 (服務(wù)端的公鑰和私鑰) 是為了讓客戶(hù)端把這個(gè)對(duì)稱(chēng)密鑰安全地傳給服務(wù)器；

第一組非對(duì)稱(chēng)加密的密鑰 (CA的公鑰和私鑰)?是為了讓客戶(hù)端安全地拿到第二組非對(duì)稱(chēng)加密的公鑰 (服務(wù)端的公鑰)；

3.7. 常見(jiàn)問(wèn)題

3.7.1. 為什么數(shù)據(jù)摘要在網(wǎng)絡(luò)傳輸?shù)臅r(shí)候一定要加密形成簽名？

常見(jiàn)的摘要算法有：MD5 和 SHA 系列； 以 MD5 為例，我們不需要研究具體的計(jì)算簽名的過(guò)程，只需要了解 MD5 的特點(diǎn)。

定長(zhǎng)：無(wú)論多長(zhǎng)的字符串，計(jì)算出來(lái)的 MD5 值都是固定長(zhǎng)度(16字節(jié)版本或者32字節(jié)版本)；分散：源字符串只要改變一點(diǎn)點(diǎn)，最終得到的 MD5 值都會(huì)差別很大；不可逆：通過(guò)源字符串生成 MD5 很容易,但是通過(guò) MD5 還原成原串理論上是不可能的。

正因?yàn)?MD5 有這樣的特性， 我們可以認(rèn)為如果兩個(gè)字符串的 MD5 值相同， 則認(rèn)為這兩個(gè)字符串相同。

為什么不對(duì)數(shù)據(jù)直接進(jìn)行加密形成數(shù)據(jù)簽名，而是要先Hash形成數(shù)據(jù)摘要？

減小簽名長(zhǎng)度：直接對(duì)數(shù)據(jù)進(jìn)行加密形成簽名可能會(huì)導(dǎo)致簽名長(zhǎng)度較長(zhǎng)，而使用哈希函數(shù)生成數(shù)據(jù)摘要后再簽名可以大大減小簽名的長(zhǎng)度。這是因?yàn)楣：瘮?shù)通常將任意長(zhǎng)度的輸入映射為固定長(zhǎng)度的輸出，因此無(wú)論輸入數(shù)據(jù)有多長(zhǎng)，生成的摘要長(zhǎng)度都是固定的。這樣做不僅有利于減小存儲(chǔ)和傳輸?shù)拈_(kāi)銷(xiāo)，也更方便處理； 提高性能：對(duì)數(shù)據(jù)進(jìn)行哈希形成數(shù)據(jù)摘要后再簽名可以加快數(shù)字簽名的運(yùn)算速度。因?yàn)楣：瘮?shù)通常具有高效的計(jì)算性能，而且生成的數(shù)據(jù)摘要長(zhǎng)度較短，因此簽名的計(jì)算速度更快。相比之下，直接對(duì)數(shù)據(jù)進(jìn)行加密可能需要更多的計(jì)算資源和時(shí)間； 安全性考慮：通過(guò)使用哈希函數(shù)生成數(shù)據(jù)摘要，可以將簽名過(guò)程與具體的加密算法隔離開(kāi)來(lái) (降低耦合度)，從而提高安全性。哈希函數(shù)的特性使得難以從摘要反推出原始數(shù)據(jù)，因此即使簽名被截獲，攻擊者也無(wú)法通過(guò)分析簽名來(lái)獲取原始數(shù)據(jù)的信息；

3.7.2. 如何成為中間人 (了解)

ARP欺騙：在局域網(wǎng)中，hacker經(jīng)過(guò)收到 ARP Request 廣播包，能夠偷聽(tīng)到其它節(jié)點(diǎn)的(IP, MAC)地址。例，黑客收到兩個(gè)主機(jī)A，B的地址，告訴B(受害者)，自己是A，使得B在發(fā)送給A的數(shù)據(jù)包都被黑客截??；ICMP攻擊：由于 ICMP 協(xié)議中有重定向的報(bào)文類(lèi)型，那么我們就可以偽造一個(gè) ICMP 信息然后發(fā)送給局域網(wǎng)中的客戶(hù)端，并偽裝自己是一個(gè)更好的路由通路。從而導(dǎo)致目標(biāo)所有的上網(wǎng)流量都會(huì)發(fā)送到我們指定的接口上，達(dá)到和ARP欺騙同樣的效果；假wifi && 假網(wǎng)站等；

感言

今天是2024/3/26號(hào)，寫(xiě)博客有一年多的時(shí)間了， 其實(shí)我有時(shí)候也懷疑這件事情有沒(méi)有意義， 它非常耗費(fèi)我的時(shí)間， 對(duì)于一個(gè)知識(shí)點(diǎn)， 我往往需要反復(fù)琢磨， 查閱一些其他資料， 甚至有時(shí)候會(huì)得出不一致的結(jié)果， 有時(shí)候感覺(jué)非常無(wú)奈， 但是我還是想要堅(jiān)持下來(lái)， 小人物嘛， 做的多是一些平凡的事情~~~~???

柚子快報(bào)邀請(qǐng)碼778899分享：探究 HTTPS 的工作過(guò)程

http://yzkb.51969.com/

參考閱讀