知識星球來自：程式員小灰（微訊號：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協議的大體原理是相同的。
