面試官：你了解數(shù)據(jù)安全傳輸嗎？
看到這個(gè)標(biāo)題，很多老鐵會(huì)斬釘截鐵的說，這道題我會(huì)!就是用 HTTPS 來進(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 到頁面呈現(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)：
- 握手階段：使用 非對(duì)稱加密技術(shù) 對(duì) 公鑰 進(jìn)行加密
- 傳輸階段：使用 對(duì)稱加密技術(shù) 對(duì) 報(bào)文 進(jìn)行加密
由于 HTTPS 多了一層使用非對(duì)稱加密算法對(duì)公鑰進(jìn)行加密的過程，因此建立連接的時(shí)間比 HTTP 要慢。
握手階段保證了連接是安全的，那么后續(xù)的數(shù)據(jù)傳輸就可以安全的進(jìn)行傳輸，因此可采用耗時(shí)較少的對(duì)稱加密算法對(duì)報(bào)文進(jìn)行加密傳輸。
HTTPS 解構(gòu)：
在上圖中，我們看到 SSL 協(xié)議的作用，在了解保證數(shù)據(jù)安全的 SSL 協(xié)議之前，我們先了解一些關(guān)于數(shù)據(jù)安全涉及的一些概念。
加解密相關(guān)概念
1. 對(duì)稱加密
別名： 私鑰加密、單密鑰算法、傳統(tǒng)密碼算法。
概念： 指使用 相同的密鑰 進(jìn)行加解密，因此從加密密鑰可以推算出解密密鑰，也可以從解密密鑰推算出加密密鑰。
常見的對(duì)稱加密算法： DES(Data Encryption Standard)、AES(Advanced Encryption Standard)、RC4、IDEA
2. 非對(duì)稱加密
別名： 公鑰加密
概念： 公鑰是對(duì)外公開的，私鑰存儲(chǔ)在通信兩端的各自手里。客戶端跟加密的公鑰形成一對(duì)密鑰對(duì)， 服務(wù)端跟加密的公鑰形成另外一對(duì)密鑰對(duì)，加解密的密鑰是成對(duì)的
限制： 加密內(nèi)容的長(zhǎng)度不能超過公鑰的長(zhǎng)度
3. 數(shù)字摘要
別名： 數(shù)字指紋
概念： 明文采用單項(xiàng) Hash 函數(shù)生成的一串固定長(zhǎng)度(128 位)的密文。
4. 數(shù)字簽名
概念：非對(duì)稱密鑰加密技術(shù)和數(shù)字摘要的混合應(yīng)用
(1) 數(shù)字簽名過程
- 發(fā)送者使用 Hash 函數(shù) (H) 將原文生成數(shù)字摘要 A
- 發(fā)送者使用自己的私鑰， 對(duì)數(shù)字摘要 A 進(jìn)行加密， 生成密文 CypherA
- 將密文 CypherA 與原文一起傳送給接收者
(2) 數(shù)字簽名驗(yàn)證(信息的完整性)過程
- 接收者使用 Hash 函數(shù) (H) 將接收到的原文生成數(shù)字摘要 B (B === A, H 函數(shù)是一樣的)
- 接收者使用公鑰，對(duì)接收到的加密密文 (CypherA) 進(jìn)行解密， 得到數(shù)字摘要 B'
- 對(duì)比 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)
- // 返回固定長(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 decryptdecryptedAbstract = 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ù)字簽名過程
- 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í)對(duì)持有者的身份進(jìn)行驗(yàn)證，它讓客戶端有能力去識(shí)別公鑰是否來自合法的服務(wù)器。
證書頒發(fā)機(jī)構(gòu)(CA) 頒發(fā)包含公鑰和所有者身份的數(shù)字證書。匹配的私鑰不是公開的，而是由生成密鑰對(duì)的最終用戶保密。證書還是 CA 的確認(rèn)或驗(yàn)證，證書中包含的公鑰屬于證書中標(biāo)注的個(gè)人，組織，服務(wù)器或其他實(shí)體。CA 在此類方案中的義務(wù)是驗(yàn)證申請(qǐng)人的憑證，以便用戶和信賴方可以信任 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)勢(shì)。
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) 客戶端對(duì)服務(wù)端發(fā)送過來的證書進(jìn)行驗(yàn)證，驗(yàn)證通過后，進(jìn)行如下操作：
- 客戶端再次產(chǎn)生一個(gè)隨機(jī)數(shù) CRandom2
- 使用服務(wù)器證書中的公鑰對(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ì)稱加密算法進(jìn)行傳輸數(shù)據(jù)時(shí)所用到的對(duì)稱加密密鑰，還可用來 會(huì)話恢復(fù), 節(jié)約 SSL 的握手時(shí)間)
(4) 服務(wù)器再次響應(yīng)：
- 使用自己的私鑰對(duì) CRandom3 進(jìn)行解密、并對(duì)解密后的數(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)確定了密鑰，就可以對(duì)消息進(jìn)行加密傳輸了。
到此，握手過程結(jié)束。
整個(gè)握手階段的安全，取決于第三個(gè)隨機(jī)數(shù) CRandom3 能否被破解，因?yàn)檫@個(gè)隨機(jī)數(shù)是使用服務(wù)端的公鑰進(jìn)行加密的、服務(wù)端的私鑰進(jìn)行解密的;而私鑰只存儲(chǔ)在了服務(wù)端本身。
在所有的握手階段都完成之后，就可以使用對(duì)稱加密技術(shù)開始傳送應(yīng)用數(shù)據(jù)了。
QA
1. 客戶端如何對(duì)接收到的證書進(jìn)行驗(yàn)證的?
證書本身就已經(jīng)告訴客戶端怎么驗(yàn)證證書的真?zhèn)巍Ｒ簿褪亲C書上寫著如何根據(jù)證書的內(nèi)容生成證書編號(hào)。客戶端拿到證書后根據(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 生成一對(duì)公鑰、私鑰，并用私鑰將中間 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ǎn)?^^)
總結(jié)
網(wǎng)絡(luò)安全傳輸數(shù)據(jù)依賴 SSL 協(xié)議，而網(wǎng)絡(luò)傳輸?shù)膮f(xié)議是 HTTP, 因此構(gòu)成了 HTTPS 協(xié)議。而 HTTPS 要保證客戶端與服務(wù)器端的高效通信安全，必須使用對(duì)稱加密算法，但是協(xié)商對(duì)稱加密算法的過程，需要使用非對(duì)稱加密算法來保證安全，然而直接使用非對(duì)稱加密的過程本身也不安全，會(huì)有中間人篡改公鑰的可能性，所以客戶端與服務(wù)器不直接使用公鑰，而是使用數(shù)字證書簽發(fā)機(jī)構(gòu)頒發(fā)的證書來保證非對(duì)稱加密過程本身的安全。
這樣通過這些機(jī)制協(xié)商出一個(gè)對(duì)稱加密算法，就此雙方使用該算法對(duì)數(shù)據(jù)進(jìn)行加密解密傳輸，從而解決了客戶端與服務(wù)器端之間的通信安全問題。
分享到微信 
分享到微博
2020-10-08 14:15:15
