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

作者：鄢棟 2020-09-26 22:04:32

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

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

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

[[343999]]

HTTPS 認(rèn)知

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

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

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

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

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

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

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

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

HTTPS 解構(gòu)：

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

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

1. 對稱加密

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

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

常見的對稱加密算法： DES(Data Encryption Standard)、AES(Advanced Encryption Standard)、RC4、IDEA

2. 非對稱加密

別名：公鑰加密

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

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

3. 數(shù)字摘要

別名：數(shù)字指紋

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

4. 數(shù)字簽名

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

(1) 數(shù)字簽名過程

發(fā)送者使用 Hash 函數(shù) (H) 將原文生成數(shù)字摘要 A
發(fā)送者使用自己的私鑰，對數(shù)字摘要 A 進(jìn)行加密，生成密文 CypherA
將密文 CypherA 與原文一起傳送給接收者

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

接收者使用 Hash 函數(shù) (H) 將接收到的原文生成數(shù)字摘要 B (B === A, H 函數(shù)是一樣的)
接收者使用公鑰，對接收到的加密密文 (CypherA) 進(jìn)行解密，得到數(shù)字摘要 B'
對比 B' 與 B 是否相等，如果相等，說明收到的信息是完整的并且消息確實(shí)是由該發(fā)送方簽名并發(fā)送的(因?yàn)樗借€只有發(fā)送方自己知道)，在傳輸過程中沒有被修改;否則信息被修改

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

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

(3) 偽代碼

// 單項(xiàng) Hash 函數(shù) 
fucntion Hash (plainText) { // 傳入明文參數(shù) 
  // 明文加密過程 
  const encryptencryptedAbstract = encrypt(plainText) 
  // 返回固定長度（128 位）的數(shù)字摘要 
  return encryptedAbstract 
} 
 
// 發(fā)送者使用自己的私鑰對明文產(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 decryptdecryptedAbstract = decrypt(publicKey, encryptedAbstract) 
  return decryptedAbstract 
} 
 
// 接收報(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ù)字簽名過程 
receiveMessage (message.CypherText, message.originText) // 數(shù)字簽名認(rèn)證過程

5. 數(shù)字證書

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

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

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

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

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

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

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

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

公鑰和數(shù)字簽名

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

SSL/TLS

1. SSL(Secure Socket Layer, 安全套接字層)

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

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

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

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

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

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

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

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

3. SSL、TLS 的握手過程

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

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

(3) 客戶端對服務(wù)端發(fā)送過來的證書進(jìn)行驗(yàn)證，驗(yàn)證通過后，進(jìn)行如下操作：

客戶端再次產(chǎn)生一個(gè)隨機(jī)數(shù) CRandom2
使用服務(wù)器證書中的公鑰對數(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)的加密算法對 CRandom1、CRandom2、CRandom3 三個(gè)隨機(jī)數(shù)進(jìn)行加密，生成 Session Secret(這個(gè)就是后邊使用對稱加密算法進(jìn)行傳輸數(shù)據(jù)時(shí)所用到的對稱加密密鑰，還可用來會(huì)話恢復(fù), 節(jié)約 SSL 的握手時(shí)間)

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

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

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

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

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

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

1. 客戶端如何對接收到的證書進(jìn)行驗(yàn)證的?

證書本身就已經(jīng)告訴客戶端怎么驗(yàn)證證書的真?zhèn)?。也就是證書上寫著如何根據(jù)證書的內(nèi)容生成證書編號(hào)?？蛻舳四玫阶C書后根據(jù)證書上的方法自己生成一個(gè)證書編號(hào)，如果生成的證書編號(hào)與證書上的證書編號(hào)相同，那么說明這個(gè)證書是真實(shí)的。

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

通過證書鏈。

root：根證書，權(quán)威證書認(rèn)證機(jī)構(gòu) (CA, Certificate Authority) 給自己頒發(fā)的數(shù)字證書，也就是自己認(rèn)證自己。在上圖中根證書就是由 DigiCert Global Root CA 自己給自己簽發(fā)的。
intermediates：中間證書，根 CA 生成一對公鑰、私鑰，并用私鑰將中間 CA 的信息和公鑰進(jìn)行 “加密” 生成簽名，封裝得到中間證書。需要注意的是，中間 CA 可能不止一個(gè)。上一級(jí) CA 同樣按照這個(gè)邏輯給下一級(jí) CA 進(jìn)行簽發(fā)證書。在這里中間 CA 就是 RapidSSL RSA CA 2018，它給末端使用者簽發(fā)證書。
end-user：末端使用者(證書)。圖中的末端證書就是 *.juejin.im 使用的數(shù)字證書。

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

總結(jié)

網(wǎng)絡(luò)安全傳輸數(shù)據(jù)依賴 SSL 協(xié)議，而網(wǎng)絡(luò)傳輸?shù)膮f(xié)議是 HTTP, 因此構(gòu)成了 HTTPS 協(xié)議。而 HTTPS 要保證客戶端與服務(wù)器端的高效通信安全，必須使用對稱加密算法，但是協(xié)商對稱加密算法的過程，需要使用非對稱加密算法來保證安全，然而直接使用非對稱加密的過程本身也不安全，會(huì)有中間人篡改公鑰的可能性，所以客戶端與服務(wù)器不直接使用公鑰，而是使用數(shù)字證書簽發(fā)機(jī)構(gòu)頒發(fā)的證書來保證非對稱加密過程本身的安全。

這樣通過這些機(jī)制協(xié)商出一個(gè)對稱加密算法，就此雙方使用該算法對數(shù)據(jù)進(jìn)行加密解密傳輸，從而解決了客戶端與服務(wù)器端之間的通信安全問題。

責(zé)任編輯：趙寧寧來源：微醫(yī)大前端技術(shù)