日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間：8:30-17:00
你可能遇到了下面的問(wèn)題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案
面試官：你了解數(shù)據(jù)安全傳輸嗎？

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

創(chuàng)新互聯(lián)是一家專業(yè)提供登封企業(yè)網(wǎng)站建設(shè),專注與成都做網(wǎng)站、網(wǎng)站制作、成都外貿(mào)網(wǎng)站建設(shè)、成都h5網(wǎng)站建設(shè)、小程序制作等業(yè)務(wù)。10年已為登封眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)絡(luò)公司優(yōu)惠進(jìn)行中。

對(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ì)稱加密技術(shù) 對(duì) 公鑰 進(jìn)行加密
  • 傳輸階段：使用 對(duì)稱加密技術(shù) 對(duì) 報(bào)文 進(jìn)行加密

由于 HTTPS 多了一層使用非對(duì)稱加密算法對(duì)公鑰進(jìn)行加密的過(guò)程，因此建立連接的時(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)行加解密，因此從加密密鑰可以推算出解密密鑰，也可以從解密密鑰推算出加密密鑰。

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

2. 非對(duì)稱加密

別名： 公鑰加密

概念： 公鑰是對(duì)外公開(kāi)的，私鑰存儲(chǔ)在通信兩端的各自手里?？蛻舳烁用艿墓€形成一對(duì)密鑰對(duì)， 服務(wù)端跟加密的公鑰形成另外一對(duì)密鑰對(duì)，加解密的密鑰是成對(duì)的

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

3. 數(shù)字摘要

別名： 數(shù)字指紋

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

4. 數(shù)字簽名

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

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

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

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

  • 接收者使用 Hash 函數(shù) (H) 將接收到的原文生成數(shù)字摘要 B (B === A, H 函數(shù)是一樣的)
  • 接收者使用公鑰，對(duì)接收到的加密密文 (CypherA) 進(jìn)行解密， 得到數(shù)字摘要 B'
  • 對(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ā)送方的[私鑰]。

(3) 偽代碼

 
 
 
 
      
  
  
  
  1. // 單項(xiàng) Hash 函數(shù) 
    2.   
  
  
  
  2. fucntion Hash (plainText) { // 傳入明文參數(shù) 
    3.   
  
  
  
  3.   // 明文加密過(guò)程 
    4.   
  
  
  
  4.   const encryptencryptedAbstract = encrypt(plainText) 
    5.   
  
  
  
  5.   // 返回固定長(zhǎng)度（128 位）的數(shù)字摘要 
    6.   
  
  
  
  6.   return encryptedAbstract 
    7.   
  
  
  
  7. } 
    8.   
  
  
  
  8.  
    9.   
  
  
  
  9. // 發(fā)送者使用自己的私鑰對(duì)明文產(chǎn)生的數(shù)字摘要進(jìn)行加密, 生成密文 CypherA 
    10.   
  
  
  
  10. function doEncrypt (senderPrivateKey, encryptedAbstract) { 
    11.   
  
  
  
  11.   const CypherA = encrypt(senderPrivateKey, encryptedAbstract) 
    12.   
  
  
  
  12.   return CypherA 
    13.   
  
  
  
  13. } 
    14.   
  
  
  
  14.  
    15.   
  
  
  
  15. // 發(fā)送報(bào)文 
    16.   
  
  
  
  16. function sendMessage (plainText) { 
    17.   
  
  
  
  17.   const encryptedAbstract = Hash(plainText) 
    18.   
  
  
  
  18.   const CypherA = doEncrypt(senderPrivateKey, encryptedAbstract) // 加密 
    19.   
  
  
  
  19.   return { 
    20.   
  
  
  
  20.     CypherText: CypherA, 
    21.   
  
  
  
  21.     originText: plainText 
    22.   
  
  
  
  22.   } 
    23.   
  
  
  
  23. } 
    24.   
  
  
  
  24.  
    25.   
  
  
  
  25. // 接收者用公鑰解密 
    26.   
  
  
  
  26. function doDecrypt (publicKey, encryptedAbstract) { 
    27.   
  
  
  
  27.   const decryptdecryptedAbstract = decrypt(publicKey, encryptedAbstract) 
    28.   
  
  
  
  28.   return decryptedAbstract 
    29.   
  
  
  
  29. } 
    30.   
  
  
  
  30.  
    31.   
  
  
  
  31. // 接收?qǐng)?bào)文 
    32.   
  
  
  
  32. function receiveMessage (CypherA, plainText) { 
    33.   
  
  
  
  33.   const encryptedAbstract = Hash(plainText) 
    34.   
  
  
  
  34.   const decryptedAbstract = doDecrypt(publicKey, encryptedAbstract) // 解密 
    35.   
  
  
  
  35.   if (decryptedAbstract === encryptedAbstract) { 
    36.   
  
  
  
  36.     console.log('1、the sender is true') // 消息發(fā)送者的確認(rèn) 
    37.   
  
  
  
  37.     console.log('2、the message is complete') // 消息完整性的確認(rèn) 
    38.   
  
  
  
  38.   } 
    39.   
  
  
  
  39. } 
    40.   
  
  
  
  40.  
    41.   
  
  
  
  41. const message = sendMessage(plainText) // 數(shù)字簽名過(guò)程 
    42.   
  
  
  
  42. receiveMessage (message.CypherText, message.originText) // 數(shù)字簽名認(rèn)證過(guò)程 
    43.

5. 數(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)證，它讓客戶端有能力去識(shí)別公鑰是否來(lái)自合法的服務(wù)器。

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

當(dā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)的名稱
  • 證書(shū)本身的數(shù)字簽名
  • 證書(shū)持有者公鑰
  • 證書(shū)簽名用到的 Hash 算法
  • ... 等等

公鑰和數(shù)字簽名

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

SSL/TLS

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

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

2. 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ā)送到正確的客戶端和服務(wù)器

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

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

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

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

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

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

  • 客戶端再次產(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ì)稱加密算法進(jìn)行傳輸數(shù)據(jù)時(shí)所用到的對(duì)稱加密密鑰，還可用來(lái) 會(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)證之前通過(guò)握手建立起來(lái)的加解密通道是否成功

到上面四步，客戶端與服務(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ì)稱加密技術(shù)開(kāi)始傳送應(yīng)用數(shù)據(jù)了。

QA

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

證書(shū)本身就已經(jīng)告訴客戶端怎么驗(yàn)證證書(shū)的真?zhèn)巍Ｒ簿褪亲C書(shū)上寫(xiě)著如何根據(jù)證書(shū)的內(nèi)容生成證書(shū)編號(hào)?？蛻舳四玫阶C書(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ū)的公鑰是給用戶加密報(bào)文外，其他層證書(shū)中的公鑰均用于解密下一層的證書(shū)指紋簽名。最高層的根證書(shū)是自簽名的，也就是自己頒發(fā)給自己，所以 根證書(shū)一定是可信的(難道自己還不能信任自己?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ì)稱加密算法的過(guò)程，需要使用非對(duì)稱加密算法來(lái)保證安全，然而直接使用非對(duì)稱加密的過(guò)程本身也不安全，會(huì)有中間人篡改公鑰的可能性，所以客戶端與服務(wù)器不直接使用公鑰，而是使用數(shù)字證書(shū)簽發(fā)機(jī)構(gòu)頒發(fā)的證書(shū)來(lái)保證非對(duì)稱加密過(guò)程本身的安全。

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


新聞標(biāo)題：面試官：你了解數(shù)據(jù)安全傳輸嗎？
網(wǎng)站網(wǎng)址：http://www.dlmjj.cn/article/dhesesi.html