歡迎光臨
每天分享高質量文章

漫畫:什麼是 HTTPS 協議?

來自:程式員小灰(微信號:chengxuyuanxiaohui)

什麼是HTTP協議?

HTTP協議全稱Hyper Text Transfer Protocol,翻譯過來就是超文本傳輸協議,位於TCP/IP四層模型當中的應用層。

HTTP協議通過請求/響應的方式,在客戶端和服務端之間進行通信。

這一切看起來很美好,但是HTTP協議有一個致命的缺點:不夠安全

HTTP協議的信息傳輸完全以明文方式,不做任何加密,相當於是在網絡上“裸奔”。這樣會導致什麼問題呢?讓我們打一個比方:

小灰是客戶端,小灰的同事小紅是服務端,有一天小灰試圖給小紅髮送請求。

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

如何進行加密呢?

小灰和小紅可以事先約定一種對稱加密方式,並且約定一個隨機生成的密鑰。後續的通信中,信息發送方都使用密鑰對信息加密,而信息接收方通過同樣的密鑰對信息解密。

這樣做是不是就絕對安全了呢?並不是。

雖然我們在後續的通信中對明文進行了加密,但是第一次約定加密方式和密鑰的通信仍然是明文,如果第一次通信就已經被攔截了,那麼密鑰就會泄露給中間人,中間人仍然可以解密後續所有的通信內容。

這可怎麼辦呢?別擔心,我們可以使用非對稱加密,為密鑰的傳輸做一層額外的保護。

非對稱加密的一組秘鑰對中,包含一個公鑰和一個私鑰。明文既可以用公鑰加密,用私鑰解密;也可以用私鑰加密,用公鑰解密。

在小灰和小紅建立通信的時候,小紅首先把自己的公鑰Key1發給小灰:

收到小紅的公鑰以後,小灰自己生成一個用於對稱加密的密鑰Key2,並且用剛纔接收的公鑰Key1對Key2進行加密(這裡有點繞),發送給小紅:

小紅利用自己非對稱加密的私鑰,解開了公鑰Key1的加密,獲得了Key2的內容。從此以後,兩人就可以利用Key2進行對稱加密的通信了。

在通信過程中,即使中間人在一開始就截獲了公鑰Key1,由於不知道私鑰是什麼,也無從解密。

是什麼壞主意呢?中間人雖然不知道小紅的私鑰是什麼,但是在截獲了小紅的公鑰Key1之後,卻可以偷天換日,自己另外生成一對公鑰私鑰,把自己的公鑰Key3發送給小灰。

小灰不知道公鑰被偷偷換過,以為Key3就是小紅的公鑰。於是按照先前的流程,用Key3加密了自己生成的對稱加密密鑰Key2,發送給小紅。

這一次通信再次被中間人截獲,中間人先用自己的私鑰解開了Key3的加密,獲得Key2,然後再用當初小紅髮來的Key1重新加密,再發給小紅。

這樣一來,兩個人後續的通信儘管用Key2做了對稱加密,但是中間人已經掌握了Key2,所以可以輕鬆進行解密。

是什麼解決方案呢?難道再把公鑰進行一次加密嗎?這樣只會陷入雞生蛋蛋生雞,永無止境的困局。

這時候,我們有必要引入第三方,一個權威的證書頒發機構(CA)來解決。

到底什麼是證書呢?證書包含如下信息:

為了便於說明,我們這裡做了簡化,只列出了一些關鍵信息。至於這些證書信息的用處,我們看看具體的通信流程就能夠弄明白了。

流程如下:

1、作為服務端的小紅,首先把自己的公鑰發給證書頒發機構,向證書頒發機構申請證書。

2、證書頒發機構自己也有一對公鑰私鑰。機構利用自己的私鑰來加密Key1,並且通過服務端網址等信息生成一個證書簽名,證書簽名同樣經過機構的私鑰加密。證書製作完成後,機構把證書發送給了服務端小紅。

3、當小灰向小紅請求通信的時候,小紅不再直接傳回自己的公鑰,而是把自己申請的證書傳回給小灰。

4、小灰收到證書以後,要做的第一件事情是驗證證書的真偽。需要說明的是,各大瀏覽器和操作系統已經維護了所有權威證書機構的名稱和公鑰。所以小灰只需要知道是哪個機構頒佈的證書,就可以從本地找到對應的機構公鑰,解密出證書簽名。

接下來,小灰按照同樣的簽名規則,自己也生成一個證書簽名,如果兩個簽名一致,說明證書是有效的。

驗證成功後,小灰就可以放心地再次利用機構公鑰,解密出服務端小紅的公鑰Key1。

5、像之前一樣,小灰生成自己的對稱加密密鑰Key2,並且用服務端公鑰Key1加密Key2,發送給小紅。

6、最後,小紅用自己的私鑰解開加密,得到對稱加密密鑰Key2。於是兩人開始用Key2進行對稱加密的通信。

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

註:最新推出的TLS協議,是SSL 3.0協議的升級版,和SSL協議的大體原理是相同的。

    赞(0)

    分享創造快樂