什麼是HTTPS協議

一

HTTPS協議一直是web開發，不管先後端都不可或缺的重要知識點，然而因爲歷史緣由，這個協議和知識點枯燥而繁多，若是看書和文字十分難懂苦澀。但又不得不掌握，怎麼辦呢？

正好，從朋友小灰那裏獲得一片 利用漫畫形式講解https協議的有趣圖文，你們看下加深理解。

什麼是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協議的大致原理是相同的。

轉載自公衆號：程序員小灰