消息摘要算法管钳、對(duì)稱(chēng)加密算法、非對(duì)稱(chēng)加密算法之應(yīng)用場(chǎng)景
上一篇文章主要向大家介紹了三種加密算法和它們的特點(diǎn)羡滑，這篇文章作為上一篇文章的續(xù)就來(lái)講講它們的應(yīng)用場(chǎng)景丝格，也順帶著講一下HTTPS相對(duì)于HTTP的安全性是做了哪些防護(hù)。
數(shù)字信封
首先假定一個(gè)場(chǎng)景碴萧，應(yīng)用的開(kāi)發(fā)需要加密大量的數(shù)據(jù)乙嘀，且要密鑰需要在使用過(guò)程中傳輸。在這種情況下使用非對(duì)稱(chēng)加密能夠保證分發(fā)密鑰的安全性破喻，因?yàn)橹恍枰獙⒐€分發(fā)給用戶(hù)虎谢，私鑰保存在自己手里，只要不被盜竊走或者被破解是沒(méi)有問(wèn)題的曹质。但是別忘了婴噩，這里的要求是對(duì)大量的數(shù)據(jù)進(jìn)行加密，這種情況下使用非對(duì)稱(chēng)加密會(huì)使得加密的時(shí)間變得漫長(zhǎng)羽德，所以這里顯然是不適合非對(duì)稱(chēng)加密的几莽。再來(lái)看看對(duì)稱(chēng)加密，速度加快了宅静，這很好章蚣，但是別忘了密鑰傳輸?shù)膯?wèn)題，一旦密鑰在傳輸過(guò)程中被截取姨夹，數(shù)據(jù)的安全性也無(wú)從談起了纤垂，這就必須專(zhuān)門(mén)安排安全的信道給密鑰矾策，似乎也不是一個(gè)很好的方法。
這個(gè)情況下不同解密算法的靈活結(jié)合就成了更為合理的解決方式洒忧。數(shù)字信封這種結(jié)合的一個(gè)優(yōu)秀典范蝴韭。數(shù)字信封采用對(duì)稱(chēng)加密算法加密數(shù)據(jù)，非對(duì)稱(chēng)加密算法加密對(duì)稱(chēng)密鑰的方式解決了以上的問(wèn)題熙侍，也適用于一些其他的加密場(chǎng)景榄鉴。以下是其示意圖。
SSL協(xié)議
SSL（Secure Sockets Layer）協(xié)議是HTTPS協(xié)議的安全性基石蛉抓，相較于HTTP庆尘，HTTPS正是加入了SSL層來(lái)確保數(shù)據(jù)傳輸?shù)陌踩浴Ｒ韵峦ㄟ^(guò)模擬幾種數(shù)據(jù)傳輸過(guò)程來(lái)了解SSL協(xié)議巷送。
- Round 1
客戶(hù)端 >>>> 服務(wù)器：你好驶忌！
服務(wù)器 >>>> 客戶(hù)端：你好！這是我們傳輸過(guò)程中需要的公鑰{公鑰|RSA}
客戶(hù)端 >>>> 服務(wù)器：收到公鑰笑跛，讓我們來(lái)驗(yàn)證一下付魔，這是我加密的一個(gè)隨機(jī)數(shù)，解出來(lái)給我看看飞蹂。{加密過(guò)的隨機(jī)數(shù)}[公鑰|RSA]
服務(wù)器 >>>> 客戶(hù)端：{解密過(guò)的隨機(jī)數(shù)}[私鑰|RSA]
客戶(hù)端 >>>> 服務(wù)器：驗(yàn)證成功几苍，這是我的賬號(hào)和密碼，給我看看我的私密日記{用戶(hù)名陈哑，密碼}[公鑰|RSA]
服務(wù)器 >>>> 客戶(hù)端：{我喜歡xxx}[私鑰|RSA]
這種加密方式粗看起來(lái)沒(méi)有問(wèn)題妻坝，數(shù)據(jù)都是加密后再傳輸，但是仔細(xì)想想惊窖，似乎有很大的問(wèn)題。首先回憶一下界酒，RSA的公鑰是共享的，一旦數(shù)據(jù)在傳輸過(guò)程中被抓取售担，再通過(guò)公開(kāi)的公鑰進(jìn)行解密，數(shù)據(jù)的安全性就不能得到保障了署辉。在數(shù)據(jù)傳輸過(guò)程中，單獨(dú)使用非對(duì)稱(chēng)加密似乎是不可靠的岩四，這種情況下上面介紹的數(shù)組信封就起作用了。
- Round 2
<pre><code>
客戶(hù)端>>>>服務(wù)器：你好材鹦！
服務(wù)器>>>>客戶(hù)端：你好逝淹！這是我們傳輸過(guò)程中需要的公鑰{公鑰|RSA}
客戶(hù)端>>>>服務(wù)器：收到公鑰，讓我們來(lái)驗(yàn)證一下桶唐，這是我加密的一個(gè)隨機(jī)數(shù)栅葡，解出來(lái)給我看看。{加密過(guò)的隨機(jī)數(shù)}[公鑰|RSA]
服務(wù)器>>>>客戶(hù)端：{解密過(guò)的隨機(jī)數(shù)}[私鑰|RSA]
客戶(hù)端>>>>服務(wù)器：驗(yàn)證成功欣簇，這是數(shù)據(jù)傳輸過(guò)程中需要用到的對(duì)稱(chēng)密鑰坯约，{對(duì)稱(chēng)密鑰}[公鑰|RSA]
服務(wù)器>>>>客戶(hù)端：{收到密鑰}[密鑰|AES]
客戶(hù)端>>>>服務(wù)器：這是我的銀行卡號(hào)和密碼，給我查查余額{卡號(hào)横殴，密碼}[密鑰|AES]
服務(wù)器>>>>客戶(hù)端：{你的銀行卡余額卿拴，五毛}[密鑰}|AES]
</code></pre>
相比Round1,Round2的數(shù)據(jù)傳輸?shù)陌踩缘玫搅吮Ｕ希灰话l(fā)生密鑰被盜或者破解堕花，就不會(huì)出現(xiàn)數(shù)據(jù)安全問(wèn)題，但是這樣就真的安全了嗎如贷？來(lái)看看Round3到踏。
- Round 3
<pre><code>客戶(hù)端>>>>黑 客：你好！
黑 客>>>>客戶(hù)端：你好窝稿！這是我們傳輸過(guò)程中需要的公鑰{公鑰|RSA}
客戶(hù)端>>>>黑 客：收到公鑰伴榔，讓我們來(lái)驗(yàn)證一下，這是我加密的一個(gè)隨機(jī)數(shù)踪少，解出來(lái)給我看看。{加密過(guò)的隨機(jī)數(shù)}[公鑰|RSA]
黑 客>>>>客戶(hù)端：{解密過(guò)的隨機(jī)數(shù)}[私鑰|RSA]
客戶(hù)端>>>>黑 客：驗(yàn)證成功兼犯，這是數(shù)據(jù)傳輸過(guò)程中需要用到的對(duì)稱(chēng)密鑰，{對(duì)稱(chēng)密鑰}[公鑰|RSA]
黑 客>>>>客戶(hù)端：{收到密鑰}[密鑰|AES]
客戶(hù)端>>>>黑 客：這是我的銀行卡號(hào)和密碼砸脊，給我查查余額{卡號(hào)纬霞，密碼}[密鑰|AES]
黑 客>>>>客戶(hù)端：嘿嘿，你上當(dāng)了</code></pre>
所以在實(shí)際的數(shù)據(jù)傳輸中存在一個(gè)問(wèn)題诗芜，當(dāng)前的服務(wù)器真的是真正的服務(wù)器嗎？怎么才能確定這個(gè)服務(wù)器的身份挨下？這個(gè)時(shí)候脐湾，數(shù)字證書(shū)的作用就顯現(xiàn)出來(lái)了。大家都知道愁铺，使用HTTPS需要申請(qǐng)數(shù)字證書(shū)闻鉴，這個(gè)證書(shū)是保證HTTPS安全數(shù)據(jù)傳輸?shù)幕＿@個(gè)證書(shū)就是SSL證書(shū)孟岛，在這個(gè)證書(shū)中包含以下內(nèi)容：
證書(shū)的發(fā)布機(jī)構(gòu)
證書(shū)的有效期
公鑰
證書(shū)所有者（Subject）
簽名使用的算法
指紋以及指紋使用的算法
在了解數(shù)字證書(shū)的內(nèi)容后，下面一輪模擬數(shù)據(jù)傳輸將會(huì)使用到上一篇文章講到的三種加密方式斤贰，也能大致了解到HTTPS的安全機(jī)制次询。
- Round 4
<pre><code>客戶(hù)端>>>>服務(wù)器：你好！
服務(wù)器>>>>客戶(hù)端：你好送巡！這是我的數(shù)字證書(shū)
客戶(hù)端>>>>服務(wù)器：我已收到并驗(yàn)證了數(shù)字證書(shū)的合法性盒卸，驗(yàn)證你是證書(shū)的合法擁有者，這是證書(shū)的公鑰加密的隨機(jī)數(shù){隨機(jī)數(shù)}[公鑰|RSA]
服務(wù)器>>>>客戶(hù)端：{解密過(guò)的隨機(jī)數(shù)}[私鑰|RSA]
客戶(hù)端>>>>服務(wù)器：驗(yàn)證成功糟需，這是數(shù)據(jù)傳輸過(guò)程中需要用到的對(duì)稱(chēng)密鑰谷朝，{對(duì)稱(chēng)密鑰}[公鑰|RSA]
服務(wù)器>>>>客戶(hù)端：{收到密鑰}[密鑰|AES]
客戶(hù)端>>>>服務(wù)器：這是我的銀行卡號(hào)和密碼武花，給我查查余額{卡號(hào)，密碼}[密鑰|AES]
服務(wù)器>>>>客戶(hù)端：{你的銀行卡余額专钉，一個(gè)億}[密鑰}|AES] </code></pre>
在Round4累铅，服務(wù)器發(fā)送給客戶(hù)端的數(shù)字證書(shū)中，包含數(shù)字摘要算法產(chǎn)生的指紋以及所使用的數(shù)字摘要算法娃兽，這部分使用來(lái)驗(yàn)證數(shù)字證書(shū)的完整性以及合法性的。如果指紋（可以認(rèn)為是MD5或者SHA對(duì)證書(shū)加密產(chǎn)生的字符串）能夠與客戶(hù)端對(duì)證書(shū)加密產(chǎn)生的指紋對(duì)應(yīng)（使用證書(shū)中的數(shù)字摘要算法對(duì)證書(shū)加密）第练，就能夠證明證書(shū)沒(méi)有被篡改過(guò)玛荞，其合法性也就得到驗(yàn)證。一下的步驟就與上面介紹的數(shù)字信封類(lèi)似了婴梧。通過(guò)以上的模擬客蹋，能夠知道使用SSL協(xié)議的HTTPS協(xié)議既能保證數(shù)據(jù)傳輸中的安全，也能保證客戶(hù)端與服務(wù)器連接的安全浮还。
總結(jié)
HTTPS雖然安全闽巩，但不能完全保護(hù)數(shù)據(jù)安全，它能夠做的是在數(shù)據(jù)傳輸過(guò)程中保護(hù)數(shù)據(jù)的安全涎跨，服務(wù)器和客戶(hù)端中數(shù)據(jù)安全也是需要注意的。
通過(guò)這兩篇文章的介紹撞牢，大家能夠大體了解到現(xiàn)在主要的加密方式以及它們的使用場(chǎng)景，也稍微接觸到了HTTPS的安全加密機(jī)制所宰，雖然這在開(kāi)發(fā)中的使用機(jī)會(huì)不大畜挥，但能夠了解到這些優(yōu)秀的機(jī)制，以后在有加密需求的時(shí)候也能夠多一些思路蟹但。
