---

在HTTP協(xié)議中，所有的數(shù)據(jù)都采用明文的形式傳輸，這就會(huì)導(dǎo)致數(shù)據(jù)非常容易泄露，只要拿到HTTP報(bào)文，就可以竊取各種信息。

基于HTTP協(xié)議，使用一定的加密措施，讓HTTP內(nèi)部的數(shù)據(jù)變?yōu)槊芪?#xff0c;就升級(jí)為了HTTPS協(xié)議，其中S表示Secure或者Safe，都是安全的意思。

加密方式

對(duì)稱加密

對(duì)稱加密是一種采用單個(gè)密鑰的加密方式，通信雙方采用的密鑰相同，因此稱為對(duì)稱加密。

常見的對(duì)稱加密算法有：DES、3DES、AES、TDEA

這些算法是公開的，但是密鑰不是公開的，只要通信雙方的密鑰不泄露，就算別人知道使用了哪一個(gè)算法，也無法解密密文。

比如一個(gè)簡(jiǎn)單的對(duì)稱加密算法：加減法。

假設(shè)現(xiàn)在對(duì)數(shù)據(jù)123456進(jìn)行加密，密鑰C = 6。

1. 服務(wù)端使用密鑰C加密：

123456 - 6 = 123450

此時(shí)就得到密文123450，將密文通過HTTP發(fā)送給客戶端。

2. 客戶端使用密鑰C解密：

123450 + 6 = 123456

客戶端就拿到了最終數(shù)據(jù)123456。

假設(shè)某個(gè)黑客截取到了HTTP報(bào)文，破解出數(shù)據(jù)為123450，也知道使用了加減法，這個(gè)黑客可以得到原數(shù)據(jù)嗎？

當(dāng)然不可以，因?yàn)楹诳蜎]有密鑰C，他不知道123450這個(gè)密文要與誰進(jìn)行加法，自然得不到原數(shù)據(jù)。

以上過程只是簡(jiǎn)單了解原理，實(shí)際上不會(huì)用加減法這樣簡(jiǎn)單的計(jì)算來做加密。

如果服務(wù)端與客戶端通信前都約定好，使用指定的加密算法和密鑰C，那么就可以保證這個(gè)通信是安全的。

比如一個(gè)服務(wù)端與它的多個(gè)客戶端都使用C作為密鑰：

但是這樣有一個(gè)問題，如果任意一個(gè)客戶端泄露了這個(gè)密鑰C，那么所有客戶端的信息都會(huì)被泄露。因此實(shí)際上并不會(huì)對(duì)所有的客戶端采用相同的密鑰，而是每個(gè)客戶端都使用不同的密鑰。

如果每個(gè)客戶端都使用不同密鑰，那么就不能再提前約定了，因?yàn)榉?wù)端并不知道未來有哪些客戶端要連接自己，所以在正式通信前，要為每個(gè)客戶端生成一個(gè)密鑰，并告知客戶端。

問題來了，這個(gè)告知客戶端密鑰的消息是不被加密的，黑客就可以截取第一次報(bào)文，查看到這個(gè)密鑰。此后雖然客戶端與服務(wù)端都有密鑰C，但是黑客也有密鑰C，即使后續(xù)進(jìn)行通信時(shí)數(shù)據(jù)會(huì)被加密，但是對(duì)于黑客來說和明文傳輸沒有區(qū)別。

對(duì)稱加密有以下特點(diǎn)：

1. 簡(jiǎn)單
2. 計(jì)算量小，加密速度快，效率高

---

非對(duì)稱加密

非對(duì)稱加密采用兩個(gè)密鑰完成：

1. 公鑰 S：公開的密鑰，任何人都可以知道這個(gè)密鑰
2. 私鑰 S*：私有的密鑰，只有非常少的人知道

公鑰和私鑰是配對(duì)的，它們一個(gè)負(fù)責(zé)加密，一個(gè)負(fù)責(zé)解密，有以下兩種情況：

• 使用公鑰S加密：

擁有公鑰的用戶可以加密，擁有私鑰的人可以解密。而公鑰是完全公開的，也就是說任何人都可以加密一個(gè)數(shù)據(jù)，發(fā)送給持有私鑰的人。而私鑰只有少數(shù)人持有，說明只有少數(shù)人有資格查看加密的數(shù)據(jù)。

舉個(gè)例子，在校長(zhǎng)辦公室門口有一個(gè)信箱，所有學(xué)生都可以投放信件，提出建議。而提出的建議被放到信箱內(nèi)部，其他人打不開信箱，就無法查看學(xué)生的建議，這樣投放信件到信箱的過程，就是使用公鑰加密數(shù)據(jù)的過程，任何一個(gè)人都可以加密數(shù)據(jù)。

如果想要查看信箱內(nèi)部的信件，那么就必須有信箱的鑰匙，而鑰匙只有校長(zhǎng)有，這個(gè)信箱鑰匙就是私鑰。只有校長(zhǎng)可以看信件，也就是只有私鑰持有者有資格查看數(shù)據(jù)。

• 使用私鑰S*加密

使用私鑰加密與之前是相反的過程，只有私鑰的持有者有資格加密數(shù)據(jù)，但是任何人都可以查看加密后的數(shù)據(jù)。

也舉個(gè)例子，這就像學(xué)校發(fā)布的告示文件，這種文件往往需要學(xué)校蓋章，表示這個(gè)文件是本校發(fā)布的，具有權(quán)威性。那么這個(gè)公章就是私鑰，只有持有公章的人有資格代表學(xué)校發(fā)布告示，而任何人都可以閱讀這個(gè)告示。

在網(wǎng)絡(luò)通信中，由于雙方都需要收發(fā)數(shù)據(jù)，如果采用非對(duì)稱加密，那么就要采用兩對(duì)公鑰和私鑰。

假設(shè)服務(wù)端生成S S*這對(duì)密鑰，客戶端生成C C*這對(duì)密鑰，采用私鑰進(jìn)行加密，公鑰進(jìn)行解密。

如果黑客截取到了密文，就算它持有兩個(gè)公鑰S和C，但是解密報(bào)文需要私鑰S*和C*，這個(gè)只有客戶端和服務(wù)端分別持有，那么黑客就無法破解數(shù)據(jù)。

每一個(gè)客戶端與服務(wù)器都要維護(hù)兩對(duì)密鑰，那么這兩對(duì)密鑰就需要臨時(shí)生成，在最開始需要進(jìn)行公鑰的交換。

最開始客戶端與服務(wù)端互相不知道公鑰，那么就需要互相告知自己的公鑰，交換公鑰的過程是不加密的，黑客就可以拿到公鑰S和C，但是就算黑客拿到了兩個(gè)公鑰，它也破解不了報(bào)文。因?yàn)閳?bào)文是拿公鑰加密的，要拿私鑰解密，而客戶端與服務(wù)端之間各自生成私鑰，根本沒有把私鑰發(fā)送到網(wǎng)絡(luò)上，黑客就無法破解報(bào)文！

這樣看起來很完美了，但是它無法抵擋中間人攻擊，這個(gè)稍后講解。

非堆對(duì)稱加密比較復(fù)雜，而且加密速度慢。

---

混合加密

總結(jié)以上兩個(gè)加密方式：

• 對(duì)稱加密：效率高，如果黑客在交換密鑰時(shí)入侵，加密會(huì)失效
• 非對(duì)稱加密：效率低，如果黑客在交換密鑰時(shí)入侵，加密依然有效

那么能不能結(jié)合一下兩者，集合它們的優(yōu)點(diǎn)？

在對(duì)稱加密中，主要是害怕第一次交換密鑰會(huì)泄露，因此第一次交換密鑰需要進(jìn)行一次額外的加密。問題就變成了：在對(duì)稱加密交換密鑰時(shí)，需要對(duì)密鑰加密。

對(duì)這個(gè)對(duì)稱密鑰加密，不能采用對(duì)稱加密的方式，必須采用非對(duì)稱加密，因?yàn)榉菍?duì)稱加密不怕交換密鑰時(shí)的黑客入侵。

流程如下：

1. 服務(wù)端生成非對(duì)稱密鑰S與S*
2. 服務(wù)端告知客戶端公鑰為S
3. 客戶端生成對(duì)稱密鑰C
4. 客戶端告知服務(wù)端對(duì)稱密鑰為C，并使用公鑰S加密
5. 服務(wù)端使用S*解密報(bào)文，得到對(duì)稱密鑰為C
6. 后續(xù)所有通信采用對(duì)稱密鑰C

這個(gè)連接過程中，只有第一個(gè)報(bào)文告知S公鑰是沒有加密的，而非對(duì)稱加密不怕公鑰泄露。隨后客戶端利用這一層非對(duì)稱加密，來加密密鑰C，這樣就可以保證C的安全性。

隨后所有的通信都采用C，就可以提高加密的效率，又不怕C被泄露，這就是結(jié)合前兩者的混合加密。

不過這種加密方式也害怕中間人攻擊。

---

中間人攻擊

中間人攻擊簡(jiǎn)稱MITM，先前兩種加密方式看似都很完美，但是都逃不過中間人攻擊。

在進(jìn)行密鑰交換之前，必然要建立TCP連接，而在建立連接的過程中，有可能會(huì)有第三者入侵。

假設(shè)當(dāng)前TCP連接建立完成，但是發(fā)生了中間人入侵。

中間人入侵后，此時(shí)server以為middle是客戶端，client以為middle是服務(wù)端。

以混合加密為例，展示中間人是如何繞開加密的：

首先server生成非對(duì)稱密鑰S和S*，并發(fā)送公鑰S給中間人（server以為中間人是客戶端）：

你可能以為，公鑰根本就不怕被公開，此時(shí)middle就算拿到了公鑰S也沒有任何作用。這確實(shí)沒錯(cuò)，但是這也是中間人攻擊最巧妙的一步：自己再生成一對(duì)非對(duì)稱密鑰M和M*。

客戶端接收到公鑰M后，以為這是服務(wù)端發(fā)送來的消息，以為服務(wù)端的公鑰是M。

客戶端生成對(duì)稱密鑰C，通過公鑰M加密發(fā)送給中間人：

此時(shí)中間人通過私鑰M*解密報(bào)文，得到對(duì)稱密鑰為C，于是再偽裝自己是客戶端，把C利用公鑰S加密發(fā)回給服務(wù)端。

隨后客戶端與服務(wù)端采用C進(jìn)行加密通信：

客戶端與服務(wù)端都以為自己完成了完美的加密過程，但是其實(shí)中間人早已經(jīng)拿到了對(duì)稱密鑰C，后續(xù)的所有報(bào)文中間人都可以輕松破解。

導(dǎo)致中間人攻擊的源頭，就是第一次交換公鑰S，客戶端無法得知自己收到的公鑰是來自于服務(wù)端還是中間人。

---

證書

由于客戶端無法確定與自己通信的是否是服務(wù)端還是中間人，此時(shí)一個(gè)CA機(jī)構(gòu)站了出來，它維護(hù)了一個(gè)公鑰A和一個(gè)私鑰A*，把公鑰告知給所有的瀏覽器。當(dāng)服務(wù)器發(fā)送數(shù)據(jù)前，可以找CA機(jī)構(gòu)進(jìn)行認(rèn)證，生成一個(gè)證書，客戶端拿到數(shù)據(jù)后，通過檢驗(yàn)證書來得知與自己通信的是否是目標(biāo)服務(wù)器。

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

數(shù)據(jù)簽名是一種基于非對(duì)稱加密的校驗(yàn)方式，其可以檢測(cè)出數(shù)據(jù)是否被篡改。

• 生成報(bào)文：

當(dāng)發(fā)送數(shù)據(jù)時(shí)，先把數(shù)據(jù)data使用哈希算法生成一個(gè)哈希值，在把哈希值通過私鑰A*進(jìn)行加密，這樣就得到了簽名。

最后發(fā)送報(bào)文時(shí)，把data和簽名一起發(fā)送出去。

• 驗(yàn)證報(bào)文：

接收方從收到的報(bào)文中，解析出data和簽名兩個(gè)部分。

1. 對(duì)data使用相同的哈希函數(shù)，得到一個(gè)哈希值
2. 使用公鑰A對(duì)簽名解密，得到另一個(gè)哈希值
3. 對(duì)比兩個(gè)哈希值

依據(jù)哈希算法的特性，如果兩個(gè)數(shù)據(jù)的哈希值不同，那么這兩個(gè)數(shù)據(jù)一定不同。因此只要數(shù)據(jù)被篡改，那么此處兩個(gè)哈希值就不同。

那么在加密過程中，到底哪一步需要通過數(shù)據(jù)簽名進(jìn)行確認(rèn)？就是第一步：服務(wù)端給客戶端發(fā)送公鑰時(shí)，將自己的公鑰，域名等信息一起打包作為數(shù)據(jù)data，并進(jìn)行簽名發(fā)送給客戶端。

此時(shí)如果發(fā)生中間人攻擊，中間人如果替換了公鑰，那么就會(huì)造成data與原先不一致，進(jìn)而導(dǎo)致哈希值不同，客戶端就知道有中間人的存在了。

---

CA認(rèn)證

將域名，公鑰等信息進(jìn)行打包得到data，在加上這個(gè)data的簽名，就是一個(gè)證書，也就是說證書 = 服務(wù)端信息 + 簽名。

證書由CA機(jī)構(gòu)進(jìn)行頒發(fā)，用于保證證書的權(quán)威性。先前說過，CA機(jī)構(gòu)會(huì)自己維護(hù)一個(gè)私鑰A*，不透露給任何人，并且所有瀏覽器都會(huì)內(nèi)置對(duì)應(yīng)的公鑰A。

服務(wù)器配置HTTPS協(xié)議前，要想CA機(jī)構(gòu)申請(qǐng)證書，服務(wù)器先生成非對(duì)稱密鑰S和S*，并把這些信息打包發(fā)送給CA機(jī)構(gòu)。CA機(jī)構(gòu)會(huì)對(duì)這些信息進(jìn)行確認(rèn)，如果驗(yàn)證通過，就利用哈希函數(shù)和私鑰A*對(duì)這個(gè)數(shù)據(jù)生成簽名，并把簽名和服務(wù)端信息打包成證書，發(fā)送給服務(wù)端。

后續(xù)服務(wù)端再與客戶端通信，只需要把證書發(fā)給客戶端。由于瀏覽器內(nèi)置了公鑰A，客戶端就可以檢測(cè)簽名是否正確，域名是否是目標(biāo)域名，從而確認(rèn)該公鑰確實(shí)來自于服務(wù)器，隨后執(zhí)行混合加密過程，生成對(duì)稱密鑰C，完成真正的加密通信。

基于這種CA認(rèn)證的方式，中間人就無法對(duì)證書進(jìn)行修改或者掉包。

• 中間人修改證書

如果中間人修改了證書中的公鑰S，將其變?yōu)樽约旱墓€M，此時(shí)簽名就無法匹配修改后的數(shù)據(jù)，客戶端就得知證書被修改了。

• 中間人掉包證書

如果中間人想要掉包證書，那么就要保證自己證書中的簽名可以被A解密，那么中間人就需要持有A*，但是A*被CA機(jī)構(gòu)嚴(yán)格維護(hù)，中間人得不到。

中間人也可以向CA機(jī)構(gòu)申請(qǐng)證書完成掉包，但是申請(qǐng)證書需要同時(shí)提交域名和公鑰。

1. 中間人使用服務(wù)端的域名，配上自己的公鑰M申請(qǐng)證書，CA機(jī)構(gòu)會(huì)進(jìn)行審核，發(fā)現(xiàn)匹配不上，不會(huì)給中間人頒發(fā)證書
2. 中間人拿自己的域名，配上自己的公鑰M申請(qǐng)證書，雖然可以得到證書，但是客戶端拿到掉包的證書后，發(fā)現(xiàn)域名不是自己目標(biāo)服務(wù)器的域名，就可以知道證書被掉包了

---

HTTPS

先前的內(nèi)容，只是HTTPS的基本原理，也就是使用混合加密 + 證書的模式，實(shí)際上HTTPS的流程還要稍微復(fù)雜一點(diǎn)，不過基于前面的內(nèi)容也很好理解了。

SSL/TSL

HTTPS的加密部分，是由SSL/TSL協(xié)議完成的，具體關(guān)系在下一個(gè)小標(biāo)題會(huì)講解。

先前的混合加密 + 證書的模式中，對(duì)稱密鑰C完全由客戶端生成，服務(wù)端完全沒有參與這個(gè)過程，而在真正的SSL/TSL協(xié)議中，這個(gè)對(duì)稱密鑰是由雙方進(jìn)行協(xié)商得出的。

• HTTPS通信流程：

首先，客戶端要與服務(wù)端建立TCP連接，隨后正式開始HTTPS協(xié)議。

1. 客戶端發(fā)送一個(gè)Client Random隨機(jī)數(shù)，這個(gè)隨機(jī)數(shù)與后文的密鑰相關(guān)，并發(fā)送一些其它的客戶端本身的信息
2. 服務(wù)端返回一個(gè)Server Random隨機(jī)數(shù)，也與后文的密鑰相關(guān)
3. 服務(wù)端發(fā)送自己的證書
4. 服務(wù)端發(fā)送一個(gè)密鑰交換算法，以及這個(gè)算法的一些相關(guān)參數(shù)
5. 發(fā)送Hello Done報(bào)文，表示結(jié)束

這個(gè)密鑰交換算法有很多種，此處為ECDHE算法。

• 正式開始加密：

客戶端首先驗(yàn)證證書的可靠性，在這個(gè)證書中包含服務(wù)端的公鑰S。隨后給服務(wù)端也發(fā)送一個(gè)ECDHE的參數(shù)，并且這個(gè)報(bào)文由S公鑰進(jìn)行加密。

此處不對(duì)ECDHE算法深入了解，只需要知道客戶端與服務(wù)端會(huì)交換這個(gè)算法的部分參數(shù)。

當(dāng)客戶端與服務(wù)端拿到了ECDHE算法的參數(shù)，以及兩個(gè)隨機(jī)數(shù)Client Random和Server Random，就開始正式生成密鑰。

1. 雙方分別基于ECDHE算法，生成預(yù)主密鑰Pre-Master，由于先前已經(jīng)交換過參數(shù)，它們計(jì)算出的值是相同的
2. 雙方分別基于Client Random和Server Random，對(duì)預(yù)主密鑰Pre-Master進(jìn)行再次計(jì)算，得到主密鑰master secret

這個(gè)主密鑰master secret又會(huì)進(jìn)一步生成會(huì)話密鑰session secret。

隨后客戶端發(fā)送Change Clipher Spec報(bào)文，表示接下來的報(bào)文將使用會(huì)話密鑰session secret加密。隨后立刻發(fā)送Fished報(bào)文，這個(gè)報(bào)文也會(huì)被session secret加密，在這個(gè)報(bào)文內(nèi)部，包含了客戶端之前各種信息形成的哈希值。

服務(wù)端ACK確認(rèn)該報(bào)文后，正式開始通信，當(dāng)服務(wù)端第一次發(fā)送數(shù)據(jù)之前，也會(huì)發(fā)送發(fā)送Change Clipher Spec報(bào)文，表示接下來的報(bào)文將使用會(huì)話密鑰session secret加密，再發(fā)送一個(gè)Fished報(bào)文，也包含了服務(wù)端之前各種信息生成的哈希值。

當(dāng)雙方的Finded報(bào)文都發(fā)送完畢后，就可以互相知道對(duì)方的哈希值，從而對(duì)比出之前是否有數(shù)據(jù)不統(tǒng)一，如果這兩個(gè)哈希值一樣，那么生成的session secret就是一樣的。

最后正式開始HTTPS通信。

• 總結(jié)

在以上過程中，麻煩的是雙方要互相交換很多數(shù)據(jù)，最終的sesson secret密鑰，是一個(gè)對(duì)稱密鑰，但是這個(gè)密鑰是由雙方一起決定的，不再是客戶端獨(dú)自生成。

如果忽略復(fù)雜的密鑰生成過程，可以直接簡(jiǎn)化為最初的混合加密 + 證書的模型，最后還是維護(hù)了一個(gè)對(duì)稱密鑰實(shí)現(xiàn)數(shù)據(jù)加密。只不過這個(gè)經(jīng)過這個(gè)生成密鑰的過程，最終的對(duì)稱密鑰安全性更高。

此處得到對(duì)稱密鑰的方式有很多種，本博客只是講解了其中一種ECDHE，也沒有細(xì)講該算法內(nèi)部的具體內(nèi)容。

---

HTTPS

HTTP、HTTPS、SSL、TLS協(xié)議關(guān)系如下：

其實(shí)HTTPS協(xié)議就是在HTTP協(xié)議基礎(chǔ)上增加了一個(gè)加密層，而加密是由SSL或TLS實(shí)現(xiàn)的，其中SSL是TLS的前身。

所以上一個(gè)小標(biāo)題叫做SSL/TLS，這表示加密部分是由這兩個(gè)協(xié)議實(shí)現(xiàn)的，并且兩者是or的關(guān)系。

---