??作者：一只大喵咪1201
??專欄：《網(wǎng)絡(luò)》
??格言：你只管努力，剩下的交給時(shí)間！

??HTTP的不安全性

前面本喵講解并演示了HTTP協(xié)議，在比較POST和GET方法的時(shí)候，本喵說(shuō)這兩個(gè)方法都不安全，雖然POST的提交的表單內(nèi)容在請(qǐng)求正文中，無(wú)法在地址的url中看到，但是它仍然是不安全的。

本喵服務(wù)器上的html代碼中，提交表單的方式采用的是POST的方法。

使用瀏覽器請(qǐng)求服務(wù)端時(shí)，在得到的響應(yīng)網(wǎng)頁(yè)中填入姓名和密碼，如上圖所示，然后點(diǎn)擊登錄。

此時(shí)在服務(wù)端的請(qǐng)求正文中就看到了在瀏覽器表單中輸入的姓名和密碼。這很正常，因?yàn)檫@是服務(wù)端，能看到客戶端的姓名和密碼是理所當(dāng)然的。

• 但是別人也能看到?。?！

使用一個(gè)工具Fiddler，各位小伙伴可以自行百度下載，該工具是用來(lái)抓HTTP請(qǐng)求和響應(yīng)的包的。

如上圖所示便是使用Fillder抓到的前面瀏覽器的請(qǐng)求包，同樣可以看到客戶端輸入的姓名和密碼。

Fiddler是運(yùn)行在Windows系統(tǒng)上的一個(gè)軟件，瀏覽器是另一個(gè)運(yùn)行在Windwos上的軟件，而服務(wù)端是本喵使用的騰訊云服務(wù)器，和本喵的電腦都不在一個(gè)局域網(wǎng)中。

使用了Fillder后，瀏覽器向服務(wù)端發(fā)送的請(qǐng)求就被Fillder抓取到了一份。

• HTTP協(xié)議傳輸?shù)臄?shù)據(jù)都是明文傳送的。

只要拿到瀏覽器發(fā)送的請(qǐng)求包，就可以看到請(qǐng)求包中的內(nèi)容，所以可以看到Fillder抓取的請(qǐng)求正文中的姓名和密碼。

如上圖所示，Fiddler就是一個(gè)中間人，它位于Client客戶端和Server服務(wù)端的中間，客戶端發(fā)送給服務(wù)端的請(qǐng)求以及服務(wù)端發(fā)送給客戶端的響應(yīng)，它都能抓取到。

HTTP協(xié)議傳輸?shù)膬?nèi)容又是明文傳送，所以無(wú)論是請(qǐng)求還是響應(yīng)，Fiddler都可以看到。

如果這個(gè)中間是一個(gè)黑客，是一個(gè)不法份子，那么他拿到請(qǐng)求和響應(yīng)后就可能對(duì)我們?cè)斐梢欢ǖ牟涣加绊?，尤其是像賬號(hào)密碼這樣的私密內(nèi)容。

??認(rèn)識(shí)HTTPS協(xié)議

HTTP協(xié)議不安全的主要原因就是它傳輸?shù)臄?shù)據(jù)是明文傳輸，為了讓傳輸?shù)臄?shù)據(jù)更安全，就需要將請(qǐng)求和響應(yīng)中的數(shù)據(jù)進(jìn)行加密，尤其是賬號(hào)和密碼等私密數(shù)據(jù)。

• HTTPS協(xié)議就是在HTTP協(xié)議的基礎(chǔ)上引入了一個(gè)加密層。

如上圖所示網(wǎng)絡(luò)通信協(xié)議棧示意圖中，藍(lán)色線條表示HTTP協(xié)議傳輸數(shù)據(jù)，綠色線條表示HTTPS協(xié)議傳輸數(shù)據(jù)。

• HTTP：應(yīng)用層→傳輸層→網(wǎng)絡(luò)層→數(shù)據(jù)鏈路層→數(shù)據(jù)鏈路層(對(duì)端)→網(wǎng)絡(luò)層(對(duì)端)→傳輸層(對(duì)端)→應(yīng)用層(對(duì)端)
• HTTPS：應(yīng)用層→加密層→傳輸層→網(wǎng)絡(luò)層→數(shù)據(jù)鏈路層→數(shù)據(jù)鏈路層(對(duì)端)→網(wǎng)絡(luò)層(對(duì)端)→傳輸層(對(duì)端)→加密層(對(duì)端)→應(yīng)用層(對(duì)端)

HTTPS協(xié)議只是比HTTP協(xié)議多經(jīng)過(guò)一個(gè)加密層，在經(jīng)過(guò)之前仍然是HTTP協(xié)議，經(jīng)過(guò)之后就成了HTTPS協(xié)議。

• 加密層也是位于軟件層，具體的有ssl和tls。
• HTTP經(jīng)過(guò)加密層中的加密算法后就變成了HTTPS協(xié)議，在到達(dá)對(duì)端后，需要經(jīng)過(guò)對(duì)端加密層中的算法解密后變成HTTP協(xié)議，對(duì)端才能獲取到傳輸?shù)膬?nèi)容。

??加密解密

• 加密：把明文(要傳輸?shù)男畔?進(jìn)行一系列變換，生成密文。
• 解密：把密文再進(jìn)行一系列變換，還原成明文。
• 密鑰：在加密解密的過(guò)程中，往往需要一個(gè)或多個(gè)中間數(shù)據(jù)輔助這個(gè)過(guò)程，這樣的數(shù)據(jù)就稱為密鑰。

本喵再舉一個(gè)例子來(lái)幫助大家理解：

如上圖所示，客戶端Client要發(fā)送一個(gè)數(shù)據(jù)int a = 100到服務(wù)器Server上，將a=100放入HTTP協(xié)議中后，此時(shí)這個(gè)數(shù)據(jù)是明文的，然后經(jīng)過(guò)加密層加密形成密文int b = a ^ key，此時(shí)就變成了HTTPS協(xié)議。

• int key = 200中的這個(gè)key值就被叫做密鑰。

當(dāng)使用HTTPS協(xié)議將數(shù)據(jù)傳輸?shù)椒?wù)器后，服務(wù)器首先拿到的是加密后的數(shù)據(jù)b，然后經(jīng)過(guò)ssl/tls進(jìn)行解密得到明文a = b ^ key = 100，此時(shí)就又變成了HTTP協(xié)議，服務(wù)端就可以直接拿到數(shù)據(jù)a了。

說(shuō)明：

• 異或(^)支持交換律，如key ^ a ^ key = a ^ key ^ key = a。
• 相同的兩個(gè)數(shù)相異或的結(jié)果為0。
• 任何一個(gè)數(shù)和0相異或都是數(shù)本身。

所以在上面數(shù)據(jù)傳輸過(guò)程中，加密后的數(shù)據(jù)成為b = a ^ key，在解密的時(shí)候，b ^ key = a ^ key ^ key = a就恢復(fù)到了明文。

當(dāng)然真正的密鑰不可能只是一個(gè)key值這么簡(jiǎn)單，它由有一個(gè)或者多個(gè)數(shù)據(jù)經(jīng)過(guò)一定的邏輯運(yùn)算。

??加密的原因

假設(shè)現(xiàn)在要下載一個(gè)“天天動(dòng)聽(tīng)”軟件：

正常情況下，彈出的下載界面如上圖所示，下載的是一個(gè)apk的應(yīng)用包，網(wǎng)址對(duì)應(yīng)的是天天動(dòng)聽(tīng)服務(wù)器的網(wǎng)址，使用的是HTTP協(xié)議。

上圖是不正常的情況，下載的內(nèi)容是名為qqbrowser的包，也就是QQ瀏覽器，網(wǎng)址對(duì)應(yīng)的是QQ瀏覽器的服務(wù)器，使用的也是HTTP協(xié)議。

• 這就是臭名昭著的“運(yùn)營(yíng)商劫持”。

如上圖所示，當(dāng)客戶端發(fā)起下載天天動(dòng)態(tài)的請(qǐng)求時(shí)，請(qǐng)求被傳輸?shù)搅诉\(yùn)營(yíng)商設(shè)備或者公網(wǎng)中，此時(shí)運(yùn)營(yíng)商設(shè)備發(fā)現(xiàn)這是一個(gè)HTTP下載天天動(dòng)態(tài)的請(qǐng)求，它悄悄的將這個(gè)請(qǐng)求變成了下載qq瀏覽器的請(qǐng)求。

原本應(yīng)該傳送到天天動(dòng)態(tài)的下載請(qǐng)求沒(méi)有傳遞到天天動(dòng)聽(tīng)的服務(wù)器，如上圖紅色虛線所示，反而是將下載qq瀏覽器的請(qǐng)求傳遞到了qq瀏覽器的服務(wù)器上，如上圖綠色線條所示。

此時(shí)qq瀏覽器就會(huì)返回一個(gè)下載鏈接，運(yùn)營(yíng)商設(shè)備再將這個(gè)鏈接返回給客戶端。

如果客戶端沒(méi)有注意到下載框中的內(nèi)容就點(diǎn)擊了下載，那么最后下載下來(lái)的軟件就是qq瀏覽器。

• 因?yàn)閔ttp的內(nèi)容是明?傳輸?shù)模?數(shù)據(jù)會(huì)經(jīng)過(guò)路由器、wifi熱點(diǎn)、通信服務(wù)運(yùn)營(yíng)商、代理服務(wù)器等多個(gè)物理節(jié)點(diǎn)。
• 如果信息在傳輸過(guò)程中被劫持，傳輸?shù)膬?nèi)容就完全暴露了，劫持者還可以篡改傳輸?shù)男畔⑶也槐浑p?察覺(jué)，這就是中間?攻擊，所以我們才需要對(duì)信息進(jìn)?加密。

如上圖所示，中間人存在于客戶端和服務(wù)端之間，客戶端和服務(wù)端之間的網(wǎng)絡(luò)請(qǐng)求和響應(yīng)他都能進(jìn)行監(jiān)聽(tīng)和篡改。

想想你下載軟件的時(shí)候，一不小心就下載了一個(gè)全家桶。之所以會(huì)存在中間人，主要是因?yàn)椋?/p>

不?運(yùn)營(yíng)商可以劫持,其他的?客也可以?類似的?段進(jìn)?劫持，來(lái)竊取??隱私信息，或者篡改內(nèi)容。

• 試想?下，如果?客在用戶登陸?付寶的時(shí)候獲取到賬戶余額，甚至獲取到用戶的支付密碼…

• 在互聯(lián)?上，明?傳輸是?較危險(xiǎn)的事情!!!。

??常見(jiàn)的加密方式

對(duì)稱加密：

• 采用單鑰密碼系統(tǒng)的加密方法，同一個(gè)密鑰可以同時(shí)用作信息的加密和解密，也叫做單密鑰加密。
• 特征：加密和解密所用的密鑰是相同的。

對(duì)稱加密其實(shí)就是通過(guò)同?個(gè)"密鑰"，把明?加密成密?，并且也能把密?解密成明?。就像本喵在前面介紹加密解密的時(shí)候，那個(gè)key值就是密鑰。

• 常見(jiàn)的對(duì)稱加密算法：DES、3DES、AES、TDEA、Blowfish、RC2等。
• 特點(diǎn)：算法公開(kāi)、計(jì)算量?、加密速度快、加密效率?。

非對(duì)稱加密：

• 需要兩個(gè)密鑰來(lái)進(jìn)?加密和解密，這兩個(gè)密鑰是公開(kāi)密鑰（public key，簡(jiǎn)稱公鑰）和私有密鑰(private key，簡(jiǎn)稱私鑰)。
• 特征：用私鑰加密，必須用公鑰解密，用公鑰加密，必須用私鑰解密。

公鑰和私鑰必須成對(duì)存在，一個(gè)用來(lái)加密，一個(gè)用來(lái)解密。就像古時(shí)候大臣給皇帝上的密折，大臣將折子放入一個(gè)箱子里并且鎖上，然后將這個(gè)箱子通過(guò)特定途徑給到皇帝，皇帝手里有一把鑰匙可以打開(kāi)這個(gè)箱子，只有大臣和皇帝手里有鑰匙，別人即使拿著箱子也打不開(kāi)。

• 常見(jiàn)非對(duì)稱加密算法：RSA，DSA，ECDSA等。
• 特點(diǎn)：算法強(qiáng)度復(fù)雜、安全性依賴于算法與密鑰但是由于其算法復(fù)雜，?使得加密解密速度沒(méi)有對(duì)稱加密解密的速度快。

?對(duì)稱加密要?到兩個(gè)密鑰，?個(gè)叫做"公鑰"，?個(gè)叫做"私鑰"。公鑰和私鑰是配對(duì)的，最?的缺點(diǎn)就是運(yùn)算速度?常慢，?對(duì)稱加密要慢很多。

• 網(wǎng)絡(luò)通信中，要解決的問(wèn)題主要是：數(shù)據(jù)被監(jiān)聽(tīng)，以及數(shù)據(jù)被篡改。

所以在進(jìn)行正常的加密數(shù)據(jù)通信之前，先解決密鑰如何能被對(duì)方安全收到的問(wèn)題。

??只使用對(duì)稱加密

建議：以下內(nèi)容對(duì)照著圖片閱讀文字，圖片的順序是從上到下的，文字描述也是從上到下描述。

• 只有客戶端有一把對(duì)稱密鑰C。

如果只使用對(duì)稱加密，也就是客戶端和服務(wù)端用一把密鑰來(lái)進(jìn)行加密和解密，第一步要做的事情就是讓通信雙方都知道密鑰是什么。

如上圖所示，當(dāng)客戶端將密鑰發(fā)送給服務(wù)端的時(shí)候，由于此時(shí)發(fā)送的密鑰是明文傳輸，也就是用的HTTP協(xié)議，中間人同樣可以得到這個(gè)密鑰。

此時(shí)即使服務(wù)端拿到密鑰后，雙方使用密鑰進(jìn)行加密通信也沒(méi)有意義，因?yàn)槊荑€中間人手里也有，他可以進(jìn)行解密，甚至篡改后再加密。

• 發(fā)送密鑰只能使用HTTP協(xié)議進(jìn)行明文傳輸，如果給密鑰加密的話，那么第一把密鑰怎么傳過(guò)去的呢？此時(shí)就成了一個(gè)雞生蛋蛋生雞的問(wèn)題了。

所以只使用對(duì)稱加密的方式是無(wú)法保證數(shù)據(jù)傳輸?shù)陌踩摹?/p>

??只使用非對(duì)稱加密

• 只有服務(wù)端一對(duì)密鑰，公鑰S和私鑰S’。

從上往下看，首先客戶端在發(fā)起請(qǐng)求之前向服務(wù)端發(fā)起密鑰協(xié)商。服務(wù)端收到客戶端的密鑰協(xié)商后，將自己的公鑰推送給客戶端(明文傳輸)。此時(shí)中間人也能拿到這個(gè)公鑰，因?yàn)樗敲魑膫魉偷摹?/p>

客戶端拿到公鑰后，將要發(fā)送的請(qǐng)求使用公鑰加密，然后發(fā)送給服務(wù)端，此時(shí)中間人即使拿到這個(gè)加密的請(qǐng)求也無(wú)法進(jìn)行解密，因?yàn)樗麤](méi)有私鑰。

服務(wù)端拿到加密了的請(qǐng)求后，使用私鑰進(jìn)行解密，就得到了請(qǐng)求的原文，然后根據(jù)具體的請(qǐng)求構(gòu)建響應(yīng)。

• 先假設(shè)服務(wù)端用公鑰加密響應(yīng)，然后發(fā)送出去，此時(shí)中間人雖然拿到了響應(yīng)，但是由于沒(méi)有私鑰就無(wú)法解密。同樣的客戶端拿到公鑰加密的響應(yīng)后，也沒(méi)有私鑰，也就無(wú)法解密拿到原文，所以通信失敗。
• 再假設(shè)服務(wù)端用私鑰加密響應(yīng)，然后發(fā)送出去，此時(shí)中間人拿到了響應(yīng)，由于再密鑰協(xié)商階段中間人也拿到了公鑰，所以就可以用公鑰解密得到原文，從而進(jìn)行監(jiān)聽(tīng)或者篡改。同樣通信失敗。

• 公鑰和私鑰只有一對(duì)，在上圖所示的過(guò)程中，全世界只有服務(wù)端有私鑰，其他人都沒(méi)有，公鑰是全世界公開(kāi)的，誰(shuí)都知道。

• 上面所示的過(guò)程中，起碼從客戶端到服務(wù)端是安全的(暫時(shí))，中間人即使拿到使用公鑰后加密的數(shù)據(jù)也無(wú)法解密。

所以只是用非對(duì)稱加密是無(wú)法保證通信安全的。

??雙方都使用非對(duì)稱加密

• 服務(wù)端有一對(duì)密鑰，公鑰S和私鑰S‘。
• 客戶端有一對(duì)密鑰，公鑰C和私鑰C’。

客戶端向服務(wù)端推送自己的公鑰C，中間人也可以拿到，服務(wù)端收到公鑰C后，向客戶端推送自己的公鑰S，中間人也能拿到。

客戶端將自己的請(qǐng)求使用公鑰S進(jìn)行加密形成請(qǐng)求密文，然后發(fā)送給服務(wù)端，此時(shí)即使中間人拿到密文也無(wú)法解密，因?yàn)闆](méi)有私鑰S’。

• 服務(wù)端收到請(qǐng)求密文后，使用自己的私鑰S’解密，得到請(qǐng)求原文。

服務(wù)端根據(jù)請(qǐng)求構(gòu)建出響應(yīng)，使用客戶端的公鑰C進(jìn)行加密形成響應(yīng)密文，然后發(fā)送給客戶端，此時(shí)中間人拿到密文同樣無(wú)法解密。

• 客戶端收到響應(yīng)密文后，使用自己是私鑰C’解密，得到響應(yīng)原文。

在上面客戶端和服務(wù)端通信過(guò)程中，中間人能拿到明文的兩把公鑰C和S，但是沒(méi)有私鑰C’和S’，當(dāng)客戶端和服務(wù)端使用對(duì)方的公鑰進(jìn)行加密通信時(shí)，中間人沒(méi)有任何辦法，只能看著密文從眼皮下溜走。

可以看到，雙方都使用對(duì)稱加密是可以保證數(shù)據(jù)傳輸?shù)陌踩?，但是依舊存在一個(gè)問(wèn)題：效率太低。

非對(duì)稱加密的效率相比于對(duì)稱加密要低很多，而雙方都使用對(duì)稱加密，就會(huì)導(dǎo)致網(wǎng)絡(luò)通信的速度奇慢，效率極低。

??非對(duì)稱加密 + 對(duì)稱加密

• 服務(wù)端有一對(duì)密鑰，公鑰S和私鑰S’。
• 客戶端有一把對(duì)稱密鑰C。

客戶端向服務(wù)端發(fā)起公鑰S請(qǐng)求，服務(wù)端收到請(qǐng)求后將自己的公鑰S返回給客戶端，中間人同樣能拿到公鑰S。

客戶端再將自己的對(duì)稱密鑰C使用公鑰S加密形成密文發(fā)送給給服務(wù)端，中間人也可以拿到密文，但是沒(méi)有私鑰S’無(wú)法解密得到對(duì)稱密鑰C。

服務(wù)端收到密文后用私鑰S’解密得到對(duì)稱密鑰C，然后用對(duì)稱密鑰C加密響應(yīng)形成響應(yīng)密文發(fā)送給客戶端，中間人仍然可以拿到密文，但是沒(méi)有對(duì)稱密鑰C，無(wú)法解密。

客戶端收到密文后，用對(duì)稱密鑰C解密，得到響應(yīng)原文，表明服務(wù)器已經(jīng)得到對(duì)稱密鑰C。

• 此后，客戶端和服務(wù)端就可以使用對(duì)稱密鑰C進(jìn)行加密和解密，即使中間人拿到密文也毫無(wú)辦法。

對(duì)稱密鑰 + 非對(duì)稱密鑰的方式，既滿足了通信的安全，又滿足了高效的要求。

但是此時(shí)這種方式真的安全了嗎？如果中間人從一開(kāi)始就發(fā)起攻擊呢？

• 服務(wù)端有一對(duì)密鑰，公鑰S，私鑰S’。
• 客戶端對(duì)稱密鑰C。
• 中間人有一對(duì)密鑰，公鑰M，私鑰M’。

客戶端請(qǐng)求公鑰S，服務(wù)端收到以后返回公鑰S，中間人可以拿到公鑰S。

• 中間人將服務(wù)端的公鑰S保存下來(lái)，將自己的公鑰M返回給客戶端。

客戶端收到公鑰M以后，并不知道已經(jīng)被中間人掉包了，認(rèn)為還是服務(wù)端的公鑰，所以會(huì)使用公鑰M加密自己的對(duì)稱密鑰C形成密文，然后再發(fā)送給客戶端，中間人可以拿到密文。

• 中間人拿到密文后，使用自己的私鑰M’解密得到對(duì)稱密鑰C，然后用截取下來(lái)的服務(wù)端公鑰S加密對(duì)稱密鑰C形成密文，再將密文發(fā)送給服務(wù)端。

服務(wù)端拿到密文后，用自己的私鑰S’解密得到對(duì)稱密鑰C，然后再用對(duì)稱密鑰C加密響應(yīng)形成密文發(fā)送給客戶端。

客戶端收到響應(yīng)密文后，認(rèn)為服務(wù)端已經(jīng)知道了對(duì)稱密鑰C，所以雙方之后都使用對(duì)稱密鑰C進(jìn)行通信。

• 但是通信雙方并不知道，中間人也拿到了對(duì)稱密鑰C，中間人可以進(jìn)行數(shù)據(jù)監(jiān)聽(tīng)和數(shù)據(jù)篡改。

這樣一看，采用非對(duì)稱加密 + 對(duì)稱加密的方式也并不安全，不安全的原因是客戶端無(wú)法識(shí)別公鑰的合法性。

• 雙方都采用非對(duì)稱加密的方式進(jìn)行通信也會(huì)存在中間人提前攻擊的問(wèn)題。

也就是說(shuō)，如果客戶端在收到服務(wù)端發(fā)來(lái)的公鑰后，能夠驗(yàn)證這個(gè)公鑰是服務(wù)端的公鑰S，而不是中間人的公鑰M，如果是中間人的公鑰M就停止通信，如果是服務(wù)端的公鑰S就繼續(xù)通信。這樣一來(lái)就能夠保證通信的安全了。

該如何保證公鑰的合法性呢？

??引入證書

??數(shù)據(jù)摘要(數(shù)據(jù)指紋)

• 數(shù)字指紋(數(shù)據(jù)摘要)：其基本原理是利?單向散列函數(shù)(Hash函數(shù))對(duì)信息進(jìn)?運(yùn)算，?成?串固定?度的數(shù)字摘要。
• 數(shù)字指紋并不是?種加密機(jī)制，但可以?來(lái)判斷數(shù)據(jù)有沒(méi)有被竄改。

如上圖所示，有一個(gè)非常大的文本文件，該文件中的內(nèi)容經(jīng)過(guò)一個(gè)Hash算法后，形成一個(gè)長(zhǎng)度固定的字符串，該字符串就被叫做數(shù)據(jù)摘要，也叫數(shù)據(jù)指紋。

• 有點(diǎn)像壓縮文件的意思，但是生成的是一個(gè)數(shù)字摘要。

• 數(shù)字摘要可以做到，文件中只要有微小的改動(dòng)，即使只是改變了一個(gè)標(biāo)點(diǎn)符號(hào)，對(duì)應(yīng)的數(shù)據(jù)摘要都會(huì)發(fā)生很大的變換。
• 文件內(nèi)容和數(shù)字摘要是一一對(duì)應(yīng)的。

• 摘要常?算法：有MD5、SHA1、SHA256、SHA512等，算法把?限的映射成有限，因此可能會(huì)有碰撞（兩個(gè)不同的信息，算出的摘要相同，但是概率?常低）。
• 摘要特征：和加密算法的區(qū)別是，摘要嚴(yán)格意義不是加密，因?yàn)闆](méi)有解密，只不過(guò)從摘要很難反推原信息，通常?來(lái)進(jìn)?數(shù)據(jù)對(duì)?。

可以理解為，形成數(shù)據(jù)摘要使用的Hash方法是不可逆的。

用處：

那么數(shù)據(jù)摘要有什么作用呢？拿百度網(wǎng)盤的“秒傳來(lái)舉例”：

如上圖所示，用戶A有一部電影《戰(zhàn)狼2》，把它上傳保存在了百度網(wǎng)盤上，這個(gè)過(guò)程會(huì)耗費(fèi)較長(zhǎng)時(shí)間。

• 在上傳之前，會(huì)先形成數(shù)據(jù)摘要，按照數(shù)據(jù)摘要在百度網(wǎng)盤的服務(wù)器中查找，如果沒(méi)有相同的數(shù)據(jù)摘要，說(shuō)明服務(wù)器中不存在，然后將用戶資源保存在磁盤中。

此時(shí)用戶B也有一部《戰(zhàn)狼2》電影，也要上傳到百度網(wǎng)盤中，這次上傳就不用耗費(fèi)很多時(shí)間。

• 在上傳之前，《戰(zhàn)狼2》同樣會(huì)形成一個(gè)數(shù)據(jù)摘要，然后按照數(shù)據(jù)摘要在百度網(wǎng)盤的服務(wù)器中查找，發(fā)現(xiàn)有相同的數(shù)據(jù)簽名，說(shuō)明磁盤中有《戰(zhàn)狼2》這部電影了。
• 此時(shí)就不會(huì)再上傳，而是將用戶A的《戰(zhàn)狼2》保存位置返回給用戶B，所以這次的上傳速度就很快。

• 百度網(wǎng)盤并不是說(shuō)你可用的空間有40GB就給你預(yù)留40GB等你來(lái)用，而是在你用的時(shí)候再給你分配空間。
• 如果遇到你上傳的資源已經(jīng)存在了，就不會(huì)再上傳了，而是將已存在資源的路徑給你，方便下次訪問(wèn)，這樣做是為了節(jié)省內(nèi)存，提高效率。

數(shù)據(jù)摘要的意義主要在于判讀，因?yàn)閮蓚€(gè)大文本是不方便進(jìn)行比較的，而兩個(gè)固定長(zhǎng)度的數(shù)據(jù)摘要比較起來(lái)很方便。

??數(shù)據(jù)簽名

• 數(shù)據(jù)簽名：將數(shù)據(jù)摘要用簽名者的私鑰加密，形成的密文就是數(shù)據(jù)簽名。
• 注意，?前暫時(shí)和https沒(méi)有關(guān)系，不要和https中的公鑰私鑰搞混了。

如上圖所示形成數(shù)據(jù)簽名的過(guò)程，數(shù)據(jù)先經(jīng)過(guò)Hash函數(shù)生成數(shù)據(jù)摘要，然后用簽名者的私鑰對(duì)數(shù)據(jù)摘要加密，形成的密文就是數(shù)據(jù)簽名。

要想獲得該數(shù)據(jù)的數(shù)據(jù)摘要，只能使用簽名者的公鑰對(duì)數(shù)據(jù)簽名解密，才能得到數(shù)據(jù)摘要。

• 這里的簽名者擁有一對(duì)非對(duì)稱密鑰，一個(gè)私鑰用來(lái)形成數(shù)據(jù)簽名，一個(gè)公鑰是公開(kāi)的。

為什么數(shù)字簽名不直接對(duì)證書原文加密，?是要先hash形成摘要呢？

• 這是為了縮小數(shù)字簽名密?的?度，加快數(shù)字簽名的驗(yàn)證，以及數(shù)字簽名的運(yùn)算速度。

??CA認(rèn)證

• CA機(jī)構(gòu)：它是采用PKI（Public Key Infrastructure）公開(kāi)密鑰基礎(chǔ)架構(gòu)技術(shù)，專門提供網(wǎng)絡(luò)身份認(rèn)證服務(wù)，CA可以是民間團(tuán)體，也可以是政府機(jī)構(gòu)。
• 作用：專門負(fù)責(zé)簽發(fā)和管理數(shù)字證書，且具有權(quán)威性和公正性的第三方信任機(jī)構(gòu)。
• 它的作用就像我們現(xiàn)實(shí)生活中頒發(fā)證件的公司，如護(hù)照辦理機(jī)構(gòu)。國(guó)內(nèi)的CA認(rèn)證中心主要分為區(qū)域性CA認(rèn)證中心和行業(yè)性CA認(rèn)證中心。

服務(wù)端在使?HTTPS前，需要向CA機(jī)構(gòu)申領(lǐng)?份數(shù)字證書，數(shù)字證書?含有證書申請(qǐng)者信息、公鑰信息等。

服務(wù)器把證書傳輸給瀏覽器，瀏覽器從證書?獲取公鑰就?了，證書就如?份證，證明服務(wù)端公鑰的合法性。

• 形成數(shù)據(jù)簽名時(shí)候的簽名者就是CA機(jī)構(gòu)，他手里有一對(duì)非對(duì)稱密鑰，私鑰只有他自己知道，公鑰全世界公開(kāi)。

證書申請(qǐng)：

如上圖所示，服務(wù)器在申請(qǐng)證書的時(shí)候，先將信息填好，如上圖所示的步驟1，包括公鑰與私鑰對(duì)，域名/申請(qǐng)者/公鑰等信息，不包含服務(wù)端私鑰S。

填好信息以后向CA機(jī)構(gòu)提交，等待CA機(jī)構(gòu)審核，如上圖所示步驟2。

審核通過(guò)以后CA機(jī)構(gòu)向服務(wù)端簽發(fā)證書，如上圖所示步驟3，證書中包含數(shù)據(jù)簽名和申請(qǐng)信息等內(nèi)容，其中申請(qǐng)信息這些內(nèi)容都是明文信息，誰(shuí)都可以看到，中間人也能拿到。

證書可以理解成為一個(gè)結(jié)構(gòu)化的字符串，包含以下信息：

• 證書發(fā)布機(jī)構(gòu)
• 證書有效期
• 服務(wù)端公鑰
• 證書所有者
• …
• 數(shù)據(jù)簽名

申請(qǐng)證書的時(shí)候，需要在特定平臺(tái)?成，會(huì)同時(shí)?成?對(duì)?密鑰對(duì)?，即服務(wù)端公鑰和私鑰。

其中公鑰會(huì)隨著CSR?件，?起發(fā)給CA進(jìn)?權(quán)威認(rèn)證，私鑰服務(wù)端??保留，?來(lái)后續(xù)進(jìn)?通信。

填好信息后，點(diǎn)擊生成CRS文件后，會(huì)有這樣一個(gè)頁(yè)面，分別是下載生成的私鑰和CRS文件，其中私鑰服務(wù)端自己保留，CRS文件用來(lái)提交CA審核認(rèn)證。

證書如何保證服務(wù)端公鑰不被掉包？

如上圖所示，服務(wù)端在向CA機(jī)構(gòu)提交證書申請(qǐng)以后，CA機(jī)構(gòu)會(huì)生成一份證書，并且將證書的內(nèi)容通過(guò)Hash函數(shù)形成數(shù)據(jù)摘要。

• 哈希函數(shù)是公開(kāi)的，全世界都知道。

然后CA機(jī)構(gòu)用自己的私鑰給數(shù)據(jù)摘要加密，形成數(shù)字簽名，最后再將數(shù)字簽名附在證書上簽發(fā)給服務(wù)端。

當(dāng)客戶端向服務(wù)端發(fā)起密鑰請(qǐng)求后，服務(wù)端就會(huì)將附有數(shù)字簽名的證書返回給客戶端，此時(shí)中間人也能拿到這個(gè)證書。

• 證書中包含公鑰信息，而且是公開(kāi)的。

如上圖所示，當(dāng)客戶端拿到服務(wù)端返回的帶有數(shù)字簽名的證書后，會(huì)進(jìn)一步進(jìn)行驗(yàn)證。

• 將證書和數(shù)字簽名分開(kāi)，并且將證書內(nèi)容使用公開(kāi)的Hash方法形成數(shù)據(jù)摘要1。
• 再使用CA機(jī)構(gòu)公開(kāi)的公鑰，將數(shù)字簽名進(jìn)行解密，得到數(shù)據(jù)摘要2。

然后進(jìn)行判斷，如果數(shù)據(jù)摘要1 = 數(shù)據(jù)摘要2，那么說(shuō)明證書是合法的，是由服務(wù)端發(fā)送來(lái)的，證書中的公鑰S也是合法的，就可以將對(duì)稱密鑰C通過(guò)公鑰S加密后發(fā)送給服務(wù)端，然后進(jìn)行通信了。

如果此時(shí)中間人截取了服務(wù)端給客戶端返回的帶有數(shù)據(jù)簽名證書，并且對(duì)其中的服務(wù)端公鑰S進(jìn)行了替換，然后又轉(zhuǎn)發(fā)給了客戶端。

當(dāng)客戶端收到被篡改的帶了數(shù)字簽名的證書后，進(jìn)行驗(yàn)證，通過(guò)公開(kāi)的Hash方法形成的數(shù)據(jù)摘要1和用CA機(jī)構(gòu)公鑰解密數(shù)字簽名后得到數(shù)據(jù)摘要2并不相等，就說(shuō)明證書被篡改了，接下來(lái)的通信也就不再進(jìn)行。

• 由于CA機(jī)構(gòu)的私鑰其他人沒(méi)有，所以CA機(jī)構(gòu)頒發(fā)證書中的數(shù)字簽名一經(jīng)簽發(fā)就是獨(dú)一無(wú)二且永不改變的。

所以中間人修改了證書中的內(nèi)容后，無(wú)法使用CA機(jī)構(gòu)的私鑰形成新的數(shù)據(jù)簽名。

即使中間人用自己的私鑰形成了新的數(shù)據(jù)簽名，但是客戶端在驗(yàn)證的時(shí)候是使用的CA機(jī)構(gòu)的公鑰，無(wú)法解密這個(gè)數(shù)據(jù)簽名，也會(huì)驗(yàn)證失敗。

• 每個(gè)瀏覽器中都內(nèi)置了CA機(jī)構(gòu)的公鑰，解密證書中的數(shù)據(jù)簽名時(shí)只能使用這個(gè)公鑰。

如此一來(lái)，客戶端就能驗(yàn)證服務(wù)端公鑰的合法性了，即使服務(wù)端的公鑰是明文傳送的，中間人也沒(méi)有辦法對(duì)其進(jìn)行修改，從而保證了后續(xù)網(wǎng)絡(luò)通信的安全性。

??非對(duì)稱加密 + 對(duì)稱加密 + 證書認(rèn)證

根據(jù)本喵前面的鋪墊講解，想來(lái)大家自己也能知道HTTPS采用的通信方式是什么了，采用的是非對(duì)稱密鑰 + 對(duì)稱密鑰 + 證書認(rèn)證的方式。

• 非對(duì)稱加密是為了保證對(duì)稱密鑰的安全性。
• 對(duì)稱密鑰是為了保證通信的高效安全。
• 證書認(rèn)證是為了保證非對(duì)稱密鑰的合法性。

如上圖所示，客戶端先向服務(wù)端發(fā)起密鑰請(qǐng)求，服務(wù)端收到請(qǐng)求后返回帶有數(shù)字簽名的證書，中間人也能拿到。

客戶端收到證書后使用CA機(jī)構(gòu)的公鑰來(lái)驗(yàn)證證書的合法性，驗(yàn)證通過(guò)后是使用證書中的公鑰S將自己的對(duì)稱密鑰C加密形成密文，然后發(fā)送給服務(wù)端。

服務(wù)端收到密文后使用自己的私鑰S’進(jìn)行解密得到對(duì)應(yīng)密鑰C，然后將收到密鑰的響應(yīng)通過(guò)對(duì)稱密鑰C加密形成密文，在發(fā)送給客戶端。

客戶端收到服務(wù)端的響應(yīng)以后，使用自己的對(duì)稱密鑰C加密請(qǐng)求形成請(qǐng)求密文，然后在發(fā)送給服務(wù)端。

服務(wù)端收到請(qǐng)求密文后使用對(duì)稱密鑰C解密得到請(qǐng)求原文，再構(gòu)建響應(yīng)并且使用對(duì)稱密鑰C加密響應(yīng)形成相應(yīng)密文，然后再發(fā)送給客戶端。

• 如此來(lái)就進(jìn)行了安全的網(wǎng)絡(luò)通信，中間人毫無(wú)篡改和監(jiān)聽(tīng)的機(jī)會(huì)。

證書在我們平時(shí)上網(wǎng)的時(shí)候一定見(jiàn)過(guò)，在使用的瀏覽器中，點(diǎn)擊右上方的三個(gè)點(diǎn)，選擇"設(shè)置"，搜索"證書管理"，即可看到以下界?。(如果沒(méi)有，在隱私設(shè)置和安全性->安全??找找)

可以看到瀏覽器中存在著多個(gè)證書，這么多證書都是在訪問(wèn)不同的服務(wù)器時(shí)，服務(wù)器發(fā)送過(guò)來(lái)后保存在瀏覽器中的，方便之后直接通信。

點(diǎn)擊某個(gè)證書后，會(huì)彈出來(lái)證書的詳細(xì)內(nèi)容，如上圖所示，包括序列號(hào)有效時(shí)期公鑰等等內(nèi)容。

• 綠色框中的16進(jìn)制數(shù)就是對(duì)應(yīng)服務(wù)端的公鑰S。

有時(shí)候我們?cè)谠L問(wèn)某些網(wǎng)站的時(shí)候，會(huì)出現(xiàn)上圖所示的提示框，提示我們證書不安全，說(shuō)明此時(shí)瀏覽器在認(rèn)證證書的時(shí)候沒(méi)有通過(guò)，可能是被篡改，也可能是證書有效時(shí)間過(guò)了等等原因。

如果繼續(xù)瀏覽，瀏覽器就會(huì)繼續(xù)進(jìn)行訪問(wèn)通信，但是會(huì)有數(shù)據(jù)被篡改以及監(jiān)聽(tīng)的風(fēng)險(xiǎn)。

如果點(diǎn)擊關(guān)閉則結(jié)束這次訪問(wèn)，也就不再和服務(wù)端進(jìn)行網(wǎng)絡(luò)通信了。

如上圖就是客戶端和服務(wù)端使用HTTPS進(jìn)行網(wǎng)絡(luò)通信的完整流程。

上面本喵是按照中間人篡改證書內(nèi)容來(lái)分析，得出結(jié)論是中間人不能修改，修改了客戶端就無(wú)法通過(guò)認(rèn)證，進(jìn)而就不會(huì)繼續(xù)通信。

那么中間人能不能掉包整個(gè)證書呢？答案是不能的：

• 因?yàn)橹虚g?沒(méi)有CA私鑰，所以?法制作假的證書，假證書中的數(shù)據(jù)簽名瀏覽器是無(wú)法用CA公鑰解密的。

除非中間人向CA機(jī)構(gòu)申請(qǐng)一個(gè)真證書，然后用自己申請(qǐng)的證書進(jìn)行掉包，這樣確實(shí)能做到整體掉包。

• 但是，證書明文中包含了域名等服務(wù)端認(rèn)證信息，如果整體掉包，客戶端依舊能識(shí)別出來(lái)域名等信息和要訪問(wèn)的信息不一致。
• 并且CA認(rèn)證的是實(shí)名制的，沒(méi)有哪個(gè)中間人會(huì)那么傻。

記住一點(diǎn)：中間?沒(méi)有CA私鑰，所以對(duì)任何證書都?法進(jìn)?合法修改，包括??的。

??總結(jié)

最后一個(gè)話題，難道使用這樣的方式中間人就真的沒(méi)有辦法破解了嗎？不是的。

• 世界上沒(méi)有破解不了的加密，只是代價(jià)太高了。

只要付出足夠大的代價(jià)，比如使用有足夠高算力的計(jì)算機(jī)，再花費(fèi)巨大的人力物力時(shí)間成本，任何加密方式都可以破解，包括服務(wù)端的私鑰S’，客戶端的對(duì)稱密鑰C，甚至是CA機(jī)構(gòu)私鑰M’都可以破解。

但是這么做就不值得了，中間人付出的代價(jià)比他破解后得到的利益還多的多，所以注定這樣的事情就沒(méi)人會(huì)去干。

這篇文章中，本喵并沒(méi)有演示HTTPS協(xié)議的通信代碼，主要是因?yàn)楸具魃暾?qǐng)不到CA機(jī)構(gòu)的證書。。。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-626556.html

到了這里，關(guān)于【網(wǎng)絡(luò)】應(yīng)用層——HTTPS協(xié)議的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！