什么是HTTP協(xié)議？

HTTP協(xié)議全稱(chēng)Hyper Text Transfer Protocol，翻譯過(guò)來(lái)就是超文本傳輸協(xié)議，位于TCP/IP四層模型當(dāng)中的應(yīng)用層。

HTTP協(xié)議通過(guò)請(qǐng)求/響應(yīng)的方式，在客戶(hù)端和服務(wù)端之間進(jìn)行通信。

這一切看起來(lái)很美好，但是HTTP協(xié)議有一個(gè)致命的缺點(diǎn)：不夠安全。

HTTP協(xié)議的信息傳輸完全以明文方式，不做任何加密，相當(dāng)于是在網(wǎng)絡(luò)上“裸奔”。這樣會(huì)導(dǎo)致什么問(wèn)題呢？讓我們打一個(gè)比方：

小灰是客戶(hù)端，小灰的同事小紅是服務(wù)端，有一天小灰試圖給小紅發(fā)送請(qǐng)求。

但是，由于傳輸信息是明文，這個(gè)信息有可能被某個(gè)中間人惡意截獲甚至篡改。這種行為叫做中間人攻擊。

如何進(jìn)行加密呢？

小灰和小紅可以事先約定一種對(duì)稱(chēng)加密方式，并且約定一個(gè)隨機(jī)生成的密鑰。后續(xù)的通信中，信息發(fā)送方都使用密鑰對(duì)信息加密，而信息接收方通過(guò)同樣的密鑰對(duì)信息解密。

這樣做是不是就絕對(duì)安全了呢？并不是。

雖然我們?cè)诤罄m(xù)的通信中對(duì)明文進(jìn)行了加密，但是第一次約定加密方式和密鑰的通信仍然是明文，如果第一次通信就已經(jīng)被攔截了，那么密鑰就會(huì)泄露給中間人，中間人仍然可以解密后續(xù)所有的通信內(nèi)容。

這可怎么辦呢？別擔(dān)心，我們可以使用非對(duì)稱(chēng)加密，為密鑰的傳輸做一層額外的保護(hù)。

非對(duì)稱(chēng)加密的一組秘鑰對(duì)中，包含一個(gè)公鑰和一個(gè)私鑰。明文既可以用公鑰加密，用私鑰解密；也可以用私鑰加密，用公鑰解密。

在小灰和小紅建立通信的時(shí)候，小紅首先把自己的公鑰Key1發(fā)給小灰：

收到小紅的公鑰以后，小灰自己生成一個(gè)用于對(duì)稱(chēng)加密的密鑰Key2，并且用剛才接收的公鑰Key1對(duì)Key2進(jìn)行加密（這里有點(diǎn)繞），發(fā)送給小紅：

小紅利用自己非對(duì)稱(chēng)加密的私鑰，解開(kāi)了公鑰Key1的加密，獲得了Key2的內(nèi)容。從此以后，兩人就可以利用Key2進(jìn)行對(duì)稱(chēng)加密的通信了。

在通信過(guò)程中，即使中間人在一開(kāi)始就截獲了公鑰Key1，由于不知道私鑰是什么，也無(wú)從解密。

是什么壞主意呢？中間人雖然不知道小紅的私鑰是什么，但是在截獲了小紅的公鑰Key1之后，卻可以偷天換日，自己另外生成一對(duì)公鑰私鑰，把自己的公鑰Key3發(fā)送給小灰。

小灰不知道公鑰被偷偷換過(guò)，以為Key3就是小紅的公鑰。于是按照先前的流程，用Key3加密了自己生成的對(duì)稱(chēng)加密密鑰Key2，發(fā)送給小紅。

這一次通信再次被中間人截獲，中間人先用自己的私鑰解開(kāi)了Key3的加密，獲得Key2，然后再用當(dāng)初小紅發(fā)來(lái)的Key1重新加密，再發(fā)給小紅。

這樣一來(lái)，兩個(gè)人后續(xù)的通信盡管用Key2做了對(duì)稱(chēng)加密，但是中間人已經(jīng)掌握了Key2，所以可以輕松進(jìn)行解密。

是什么解決方案呢？難道再把公鑰進(jìn)行一次加密嗎？這樣只會(huì)陷入雞生蛋蛋生雞，永無(wú)止境的困局。

這時(shí)候，我們有必要引入第三方，一個(gè)權(quán)威的證書(shū)頒發(fā)機(jī)構(gòu)（CA）來(lái)解決。

到底什么是證書(shū)呢？證書(shū)包含如下信息：

為了便于說(shuō)明，我們這里做了簡(jiǎn)化，只列出了一些關(guān)鍵信息。至于這些證書(shū)信息的用處，我們看看具體的通信流程就能夠弄明白了。

流程如下：

1.作為服務(wù)端的小紅，首先把自己的公鑰發(fā)給證書(shū)頒發(fā)機(jī)構(gòu)，向證書(shū)頒發(fā)機(jī)構(gòu)申請(qǐng)證書(shū)。

2.證書(shū)頒發(fā)機(jī)構(gòu)自己也有一對(duì)公鑰私鑰。機(jī)構(gòu)利用自己的私鑰來(lái)加密Key1，并且通過(guò)服務(wù)端網(wǎng)址等信息生成一個(gè)證書(shū)簽名，證書(shū)簽名同樣經(jīng)過(guò)機(jī)構(gòu)的私鑰加密。證書(shū)制作完成后，機(jī)構(gòu)把證書(shū)發(fā)送給了服務(wù)端小紅。

3.當(dāng)小灰向小紅請(qǐng)求通信的時(shí)候，小紅不再直接返回自己的公鑰，而是把自己申請(qǐng)的證書(shū)返回給小灰。

4.小灰收到證書(shū)以后，要做的第一件事情是驗(yàn)證證書(shū)的真?zhèn)?。需要說(shuō)明的是，各大瀏覽器和操作系統(tǒng)已經(jīng)維護(hù)了所有權(quán)威證書(shū)機(jī)構(gòu)的名稱(chēng)和公鑰。所以小灰只需要知道是哪個(gè)機(jī)構(gòu)頒布的證書(shū)，就可以從本地找到對(duì)應(yīng)的機(jī)構(gòu)公鑰，解密出證書(shū)簽名。

接下來(lái)，小灰按照同樣的簽名規(guī)則，自己也生成一個(gè)證書(shū)簽名，如果兩個(gè)簽名一致，說(shuō)明證書(shū)是有效的。

驗(yàn)證成功后，小灰就可以放心地再次利用機(jī)構(gòu)公鑰，解密出服務(wù)端小紅的公鑰Key1。

5.像之前一樣，小灰生成自己的對(duì)稱(chēng)加密密鑰Key2，并且用服務(wù)端公鑰Key1加密Key2，發(fā)送給小紅。

6.最后，小紅用自己的私鑰解開(kāi)加密，得到對(duì)稱(chēng)加密密鑰Key2。于是兩人開(kāi)始用Key2進(jìn)行對(duì)稱(chēng)加密的通信。

在這樣的流程下，我們不妨想一想，中間人是否還具有使壞的空間呢？

注：最新推出的TLS協(xié)議，是SSL 3.0協(xié)議的升級(jí)版，和SSL協(xié)議的大體原理是相同的。