面試官：你了解數(shù)據(jù)安全傳輸嗎？

鄢棟，微醫(yī)云服務(wù)團(tuán)隊(duì)前端工程師。有志成為一名全棧開(kāi)發(fā)工程師甚至架構(gòu)師，路漫漫，吾求索。生活中通過(guò)健身釋放壓力，思考問(wèn)題。

看到這個(gè)標(biāo)題，很多老鐵會(huì)斬釘截鐵的說(shuō)，這道題我會(huì)！就是用 HTTPS 來(lái)進(jìn)行安全傳輸?shù)摹?/p>

對(duì)，很優(yōu)秀，那你知道 HTTPS 底層是如何對(duì)數(shù)據(jù)進(jìn)行安全保障的嗎？下面就進(jìn)入我們今天的主題介紹：HTTPS 是如何實(shí)現(xiàn)數(shù)據(jù)安全傳輸?shù)摹?/p>

HTTPS 認(rèn)知

HTTPS 其實(shí)是 HTTP + SSL 協(xié)議組成的安全協(xié)議。

我們知道，從我們輸入 URL 到頁(yè)面呈現(xiàn)的過(guò)程是作用于 HTTP 協(xié)議的，HTTP 協(xié)議保證我們網(wǎng)絡(luò)傳輸數(shù)據(jù)的基礎(chǔ)，但是安全性無(wú)法保證，而 SSL 協(xié)議作用于 Http 協(xié)議就能解決安全問(wèn)題。

HTTPS 保證以下三點(diǎn)：

• 數(shù)據(jù)內(nèi)容加密
• 數(shù)據(jù)完整性保護(hù)（數(shù)字摘要、數(shù)字簽名）
• 身份認(rèn)證

HTTPS 保證安全性要點(diǎn)：

• 握手階段：使用 非對(duì)稱(chēng)加密技術(shù) 對(duì) 公鑰 進(jìn)行加密
• 傳輸階段：使用 對(duì)稱(chēng)加密技術(shù) 對(duì) 報(bào)文 進(jìn)行加密

由于 HTTPS 多了一層使用非對(duì)稱(chēng)加密算法對(duì)公鑰進(jìn)行加密的過(guò)程，因此建立連接的時(shí)間比 HTTP 要慢。

握手階段保證了連接是安全的，那么后續(xù)的數(shù)據(jù)傳輸就可以安全的進(jìn)行傳輸，因此可采用耗時(shí)較少的對(duì)稱(chēng)加密算法對(duì)報(bào)文進(jìn)行加密傳輸。

HTTPS 解構(gòu)

在上圖中，我們看到 SSL 協(xié)議的作用，在了解保證數(shù)據(jù)安全的 SSL 協(xié)議之前，我們先了解一些關(guān)于數(shù)據(jù)安全涉及的一些概念。

加解密相關(guān)概念

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

別名： 私鑰加密、單密鑰算法、傳統(tǒng)密碼算法。

概念： 指使用 相同的密鑰 進(jìn)行加解密，因此從加密密鑰可以推算出解密密鑰，也可以從解密密鑰推算出加密密鑰。

常見(jiàn)的對(duì)稱(chēng)加密算法： DES（Data Encryption Standard）、AES（Advanced Encryption Standard）、RC4、IDEA

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

別名： 公鑰加密

概念： 公鑰是對(duì)外公開(kāi)的，私鑰存儲(chǔ)在通信兩端的各自手里。客戶(hù)端跟加密的公鑰形成一對(duì)密鑰對(duì)， 服務(wù)端跟加密的公鑰形成另外一對(duì)密鑰對(duì)，加解密的密鑰是成對(duì)的

限制： 加密內(nèi)容的長(zhǎng)度不能超過(guò)公鑰的長(zhǎng)度

數(shù)字摘要

別名： 數(shù)字指紋

概念： 明文采用單項(xiàng) Hash 函數(shù)生成的一串固定長(zhǎng)度（128 位）的密文。

數(shù)字簽名

概念：非對(duì)稱(chēng)密鑰加密技術(shù)和數(shù)字摘要的混合應(yīng)用

數(shù)字簽名過(guò)程

1、發(fā)送者使用 Hash 函數(shù) (H) 將原文生成數(shù)字摘要 A

2、發(fā)送者使用自己的私鑰， 對(duì)數(shù)字摘要 A 進(jìn)行加密， 生成密文 CypherA

3、將密文 CypherA 與原文一起傳送給接收者

數(shù)字簽名驗(yàn)證（信息的完整性）過(guò)程

1、接收者使用 Hash 函數(shù) ?(H) 將接收到的原文生成數(shù)字摘要 B (B === A, H 函數(shù)是一樣的)

2、接收者使用公鑰，對(duì)接收到的加密密文 (CypherA) 進(jìn)行解密， 得到數(shù)字摘要 B'

3、對(duì)比 B' 與 B 是否相等， 如果相等，說(shuō)明收到的信息是完整的并且消息確實(shí)是由該發(fā)送方簽名并發(fā)送的（因?yàn)樗借€只有發(fā)送方自己知道），在傳輸過(guò)程中沒(méi)有被修改；否則信息被修改

最后比較數(shù)字摘要 A 與數(shù)字摘要 A'是否相等，也可以逆向使用 Hash()函數(shù)，將摘要 A'進(jìn)行還原得到明文，比較改明文與傳過(guò)來(lái)的原文是否一致（都是 pig）。

數(shù)字簽名 是個(gè) 加密 的過(guò)程，數(shù)字簽名驗(yàn)證 是個(gè) 解密 的過(guò)程。一次數(shù)字簽名涉及到一個(gè)哈希函數(shù)、接收者的公鑰、發(fā)送方的[私鑰]。

偽代碼

//?單項(xiàng)?Hash?函數(shù)
fucntion?Hash?(plainText)?{?//?傳入明文參數(shù)
??//?明文加密過(guò)程
??const?encryptedAbstract?=?encrypt(plainText)
??//?返回固定長(zhǎng)度（128?位）的數(shù)字摘要
??return?encryptedAbstract
}

//?發(fā)送者使用自己的私鑰對(duì)明文產(chǎn)生的數(shù)字摘要進(jìn)行加密,?生成密文?CypherA
function?doEncrypt?(senderPrivateKey,?encryptedAbstract)?{
??const?CypherA?=?encrypt(senderPrivateKey,?encryptedAbstract)
??return?CypherA
}

//?發(fā)送報(bào)文
function?sendMessage?(plainText)?{
??const?encryptedAbstract?=?Hash(plainText)
??const?CypherA?=?doEncrypt(senderPrivateKey,?encryptedAbstract)?//?加密
??return?{
????CypherText:?CypherA,
????originText:?plainText
??}
}

//?接收者用公鑰解密
function?doDecrypt?(publicKey,?encryptedAbstract)?{
??const?decryptedAbstract?=?decrypt(publicKey,?encryptedAbstract)
??return?decryptedAbstract
}

//?接收?qǐng)?bào)文
function?receiveMessage?(CypherA,?plainText)?{
??const?encryptedAbstract?=?Hash(plainText)
??const?decryptedAbstract?=?doDecrypt(publicKey,?encryptedAbstract)?//?解密
??if?(decryptedAbstract?===?encryptedAbstract)?{
????console.log('1、the?sender?is?true')?//?消息發(fā)送者的確認(rèn)
????console.log('2、the?message?is?complete')?//?消息完整性的確認(rèn)
??}
}

const?message?=?sendMessage(plainText)?//?數(shù)字簽名過(guò)程
receiveMessage?(message.CypherText,?message.originText)?//?數(shù)字簽名認(rèn)證過(guò)程

數(shù)字證書(shū)

在上述數(shù)字簽名的過(guò)程中，我們?nèi)绾伪ＷC這個(gè)公鑰是可信任的？這就是數(shù)字證書(shū)存在的必要性。

數(shù)字證書(shū)主要用于加密、簽名、身份認(rèn)證。

數(shù)字證書(shū)由 證書(shū)頒發(fā)機(jī)構(gòu)（CA, Certification Agent） 頒發(fā), CA 會(huì)在頒發(fā)證書(shū)之前以及使用證書(shū)時(shí)對(duì)持有者的身份進(jìn)行驗(yàn)證，它讓客戶(hù)端有能力去識(shí)別公鑰是否來(lái)自合法的服務(wù)器。

證書(shū)頒發(fā)機(jī)構(gòu)（CA） 頒發(fā)包含公鑰和所有者身份的數(shù)字證書(shū)。匹配的私鑰不是公開(kāi)的，而是由生成密鑰對(duì)的最終用戶(hù)保密。證書(shū)還是 CA 的確認(rèn)或驗(yàn)證，證書(shū)中包含的公鑰屬于證書(shū)中標(biāo)注的個(gè)人，組織，服務(wù)器或其他實(shí)體。CA 在此類(lèi)方案中的義務(wù)是驗(yàn)證申請(qǐng)人的憑證，以便用戶(hù)和信賴(lài)方可以信任 CA 證書(shū)中的信息。

當(dāng)您訪(fǎng)問(wèn)使用 HTTPS（安全連接）的網(wǎng)站時(shí)，該網(wǎng)站的服務(wù)器會(huì)使用證書(shū)向?yàn)g覽器（如 Chrome）證明該網(wǎng)站的身份。證書(shū)中包含的公鑰信息是可信任的, 如果證書(shū)不存在、證書(shū)被篡改、證書(shū)失效等情況，瀏覽器會(huì)在左上角提示你該網(wǎng)站不安全。

簽名驗(yàn)證鏈條：client <- 服務(wù)器 <- CA

數(shù)字證書(shū)的內(nèi)容

• 證書(shū)頒發(fā)機(jī)構(gòu)的名稱(chēng)
• 證書(shū)本身的數(shù)字簽名
• 證書(shū)持有者公鑰
• 證書(shū)簽名用到的 Hash 算法
• ... 等等

公鑰和數(shù)字簽名

了解這些基本概念后， 進(jìn)入我們今天的主題：SSL 協(xié)議如何保障數(shù)據(jù)安全傳輸

SSL/TLS

SSL（Secure Socket Layer, 安全套接字層）

利用加密技術(shù)，確保數(shù)據(jù)在網(wǎng)絡(luò)傳輸過(guò)程中不會(huì)被竊取。

TLS (Transport Layer Security，傳輸層安全協(xié)議)

用于兩個(gè)應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性。

該協(xié)議建立在 SSL3.0 協(xié)議的基礎(chǔ)之上，可理解為 SSL3.1 版本。只不過(guò)在 SSL3.0 的基礎(chǔ)上采用了一些更安全的策略，讓數(shù)據(jù)更加安全，其他的協(xié)議分層與功能與 SSL 一致。有興趣的可自行了解其與 SSL 的區(qū)別與優(yōu)勢(shì)。

SSL/TLS 協(xié)議的作用：

• 數(shù)據(jù)加密，防止被竊取
• 保護(hù)數(shù)據(jù)的完整性，確保數(shù)據(jù)不會(huì)被改變
• 身份認(rèn)證，確保數(shù)據(jù)被發(fā)送到正確的客戶(hù)端和服務(wù)器

可以看到， 這正是 HTTPS 協(xié)議發(fā)揮作用的三點(diǎn)。

那么， SSL 協(xié)議到底是如何把我們數(shù)據(jù)進(jìn)行加密，從而進(jìn)行安全傳輸?shù)哪兀?/p>

SSL、TLS 的握手過(guò)程

1、客戶(hù)端告知服務(wù)端自己支持的 安全協(xié)議版本（如 TLS1.0）、加密算法、壓縮方法、隨機(jī)數(shù) CRandom1；

2、服務(wù)端首次響應(yīng)，返回給客戶(hù)端 安全協(xié)議的版本、加密算法、壓縮方法、隨機(jī)數(shù) SRandom, 還有一個(gè) 數(shù)字證書(shū)(服務(wù)器證書(shū))；

3、客戶(hù)端對(duì)服務(wù)端發(fā)送過(guò)來(lái)的證書(shū)進(jìn)行驗(yàn)證，驗(yàn)證通過(guò)后，進(jìn)行如下操作：

• 客戶(hù)端再次產(chǎn)生一個(gè)隨機(jī)數(shù) CRandom2
• 使用服務(wù)器證書(shū)中的公鑰對(duì)數(shù)據(jù)進(jìn)行進(jìn)行加密，生成隨機(jī)數(shù) CRandom3
• 發(fā)送 ChangeCipherSpec（編碼改變）的消息通知（告知服務(wù)器我已經(jīng)準(zhǔn)備好用我們之前商量好的加密套件進(jìn)行加密并傳輸數(shù)據(jù)了） 、前面 所有消息的 hash 值 以及 加密數(shù)據(jù) CRandom3 進(jìn)行服務(wù)器驗(yàn)證
• 使用與服務(wù)器確認(rèn)的加密算法對(duì) CRandom1、CRandom2、CRandom3 三個(gè)隨機(jī)數(shù)進(jìn)行加密，生成 Session Secret（這個(gè)就是后邊使用對(duì)稱(chēng)加密算法進(jìn)行傳輸數(shù)據(jù)時(shí)所用到的對(duì)稱(chēng)加密密鑰，還可用來(lái) 會(huì)話(huà)恢復(fù), 節(jié)約 SSL 的握手時(shí)間）

4、服務(wù)器再次響應(yīng)：

• 使用自己的私鑰對(duì) CRandom3 進(jìn)行解密、并對(duì)解密后的數(shù)據(jù)進(jìn)行驗(yàn)證
• 發(fā)送 ChangeCipherSpec（編碼改變）的消息通知（告知客戶(hù)端我也準(zhǔn)備好了用我們之前商量好的加密套件和 Session Secret 進(jìn)行加密數(shù)據(jù)了）
• 使用 Session Secret 加密一段 Finish 的消息發(fā)送給客戶(hù)端， 以驗(yàn)證之前通過(guò)握手建立起來(lái)的加解密通道是否成功

到上面四步，客戶(hù)端與服務(wù)器已經(jīng)確定了密鑰，就可以對(duì)消息進(jìn)行加密傳輸了。

到此，握手過(guò)程結(jié)束。

整個(gè)握手階段的安全，取決于第三個(gè)隨機(jī)數(shù) CRandom3 能否被破解，因?yàn)檫@個(gè)隨機(jī)數(shù)是使用服務(wù)端的公鑰進(jìn)行加密的、服務(wù)端的私鑰進(jìn)行解密的；而私鑰只存儲(chǔ)在了服務(wù)端本身。

在所有的握手階段都完成之后，就可以使用對(duì)稱(chēng)加密技術(shù)開(kāi)始傳送應(yīng)用數(shù)據(jù)了。

QA

1、客戶(hù)端如何對(duì)接收到的證書(shū)進(jìn)行驗(yàn)證的？

證書(shū)本身就已經(jīng)告訴客戶(hù)端怎么驗(yàn)證證書(shū)的真?zhèn)巍Ｒ簿褪亲C書(shū)上寫(xiě)著如何根據(jù)證書(shū)的內(nèi)容生成證書(shū)編號(hào)。客戶(hù)端拿到證書(shū)后根據(jù)證書(shū)上的方法自己生成一個(gè)證書(shū)編號(hào)，如果生成的證書(shū)編號(hào)與證書(shū)上的證書(shū)編號(hào)相同，那么說(shuō)明這個(gè)證書(shū)是真實(shí)的。

2、公鑰的安全性是通過(guò)證書(shū)來(lái)確認(rèn)的， 但是證書(shū)是由頒發(fā)機(jī)構(gòu)來(lái)頒發(fā)的， 那如何確認(rèn)這個(gè)頒發(fā)者是可信的呢？

通過(guò)證書(shū)鏈。

• root：根證書(shū)，權(quán)威證書(shū)認(rèn)證機(jī)構(gòu) (CA, Certificate Authority) 給自己頒發(fā)的數(shù)字證書(shū)，也就是自己認(rèn)證自己。在上圖中根證書(shū)就是由 DigiCert Global Root CA 自己給自己簽發(fā)的。

• intermediates：中間證書(shū)，根 CA 生成一對(duì)公鑰、私鑰，并用私鑰將中間 CA 的信息和公鑰進(jìn)行 “加密” 生成簽名，封裝得到中間證書(shū)。需要注意的是，中間 CA 可能不止一個(gè)。上一級(jí) CA 同樣按照這個(gè)邏輯給下一級(jí) CA 進(jìn)行簽發(fā)證書(shū)。在這里中間 CA 就是 RapidSSL RSA CA 2018，它給末端使用者簽發(fā)證書(shū)。

• end-user：末端使用者（證書(shū)）。圖中的末端證書(shū)就是 *.juejin.im 使用的數(shù)字證書(shū)。

可以看到證書(shū)鏈由多個(gè)證書(shū)一層一層組成的。末端證書(shū)的公鑰是給用戶(hù)加密報(bào)文外，其他層證書(shū)中的公鑰均用于解密下一層的證書(shū)指紋簽名。最高層的根證書(shū)是自簽名的，也就是自己頒發(fā)給自己，所以 根證書(shū)一定是可信的(難道自己還不能信任自己?jiǎn)?？^^)

總結(jié)

網(wǎng)絡(luò)安全傳輸數(shù)據(jù)依賴(lài) SSL 協(xié)議，而網(wǎng)絡(luò)傳輸?shù)膮f(xié)議是 HTTP, 因此構(gòu)成了 HTTPS 協(xié)議。而 HTTPS 要保證客戶(hù)端與服務(wù)器端的高效通信安全，必須使用對(duì)稱(chēng)加密算法，但是協(xié)商對(duì)稱(chēng)加密算法的過(guò)程，需要使用非對(duì)稱(chēng)加密算法來(lái)保證安全，然而直接使用非對(duì)稱(chēng)加密的過(guò)程本身也不安全，會(huì)有中間人篡改公鑰的可能性，所以客戶(hù)端與服務(wù)器不直接使用公鑰，而是使用數(shù)字證書(shū)簽發(fā)機(jī)構(gòu)頒發(fā)的證書(shū)來(lái)保證非對(duì)稱(chēng)加密過(guò)程本身的安全。這樣通過(guò)這些機(jī)制協(xié)商出一個(gè)對(duì)稱(chēng)加密算法，就此雙方使用該算法對(duì)數(shù)據(jù)進(jìn)行加密解密傳輸，從而解決了客戶(hù)端與服務(wù)器端之間的通信安全問(wèn)題。

筆者簡(jiǎn)單帶大家了解了數(shù)據(jù)安全傳輸?shù)年P(guān)鍵點(diǎn)， 其實(shí)關(guān)于安全的話(huà)題還有很多值得深入的點(diǎn)，歡迎大家給我留言~ 共同學(xué)習(xí)，共同進(jìn)步。創(chuàng)作不易，如果本文對(duì)你有那么一點(diǎn)點(diǎn)幫助的話(huà)， 點(diǎn)個(gè)贊送我上熱搜(#^.^#)，讓我有更多的動(dòng)力繼續(xù)創(chuàng)作~

參考資料

SSL/TLS 協(xié)議詳解：https://cshihong.github.io/2019/05/09/SSL%E5%8D%8F%E8%AE%AE%E8%AF%A6%E8%A7%A3/