在網上衝浪瀏覽網站時，一定要檢查是不是 HTTPS 的，HTTP有可能被中間人攻擊和攔截，下面就是詳細的 HTTPS 原理，細思極恐。
1. HTTP 協議
在談論 HTTPS 協議之前，先來回顧一下 HTTP 協議的概念。
1.1 HTTP 協議介紹HTTP 協議是一種基於文字的傳輸協議，它位於 OSI 網路模型中的應用層。
HTTP 協議是透過客戶端和伺服器的請求應答來進行通訊，目前協議由之前的 RFC 2616 拆分成立六個單獨的協議說明（RFC 7230、RFC 7231、RFC 7232、RFC 7233、RFC 7234、RFC 7235），通訊報文如下：
請求
POST http://www.baidu.com HTTP/1.1Host: www.baidu.comConnection: keep-aliveContent-Length: 7User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36wd=HTTP響應
HTTP/1.1 200 OKConnection: Keep-AliveContent-Encoding: gzipContent-Type: text/html;charset=utf-8Date: Thu, 14 Feb 2019 07:23:49 GMTTransfer-Encoding: chunked<html>...</html>HTTP 協議使用起來確實非常的方便，但是它存在一個致命的缺點：不安全。
我們知道 HTTP 協議中的報文都是以明文的方式進行傳輸，不做任何加密，這樣會導致什麼問題呢？下面來舉個例子：
小明在 JAVA 貼吧發帖，內容為我愛JAVA：
被中間人進行攻擊，內容修改為我愛PHP
小明被群嘲可以看到在 HTTP 傳輸過程中，中間人能看到並且修改 HTTP 通訊中所有的請求和響應內容，所以使用 HTTP 是非常的不安全的。
1.3 防止中間人攻擊這個時候可能就有人想到了，既然內容是明文那我使用對稱加密的方式將報文加密這樣中間人不就看不到明文了嗎，於是如下改造：
雙方約定加密方式
使用 AES 加密報文
這樣看似中間人獲取不到明文資訊了，但其實在通訊過程中還是會以明文的方式暴露加密方式和秘鑰，如果第一次通訊被攔截到了，那麼秘鑰就會洩露給中間人，中間人仍然可以解密後續的通訊：
那麼對於這種情況，我們肯定就會考慮能不能將秘鑰進行加密不讓中間人看到呢？答案是有的，採用非對稱加密，我們可以透過 RSA 演算法來實現。這個步驟實際操作也是比較簡單的，在裸睡的豬訂閱號後臺回覆HTTPS就可以檢視搭建HTTPS服務影片。
在約定加密方式的時候由伺服器生成一對公私鑰，伺服器將公鑰返回給客戶端，客戶端本地生成一串秘鑰(AES_KEY)用於對稱加密，並透過伺服器傳送的公鑰進行加密得到(AES_KEY_SECRET)，之後返回給服務端，服務端透過私鑰將客戶端傳送的AES_KEY_SECRET進行解密得到AEK_KEY,最後客戶端和伺服器透過AEK_KEY進行報文的加密通訊，改造如下：
可以看到這種情況下中間人是竊取不到用於AES加密的秘鑰，所以對於後續的通訊是肯定無法進行解密了，那麼這樣做就是絕對安全了嗎？
所謂道高一尺魔高一丈，中間人為了對應這種加密方法又想出了一個新的破解方案，既然拿不到AES_KEY，那我就把自己模擬成一個客戶端和伺服器端的結合體，在使用者->中間人的過程中中間人模擬伺服器的行為，這樣可以拿到使用者請求的明文，在中間人->伺服器的過程中中間人模擬客戶端行為，這樣可以拿到伺服器響應的明文，以此來進行中間人攻擊：
這一次通訊再次被中間人截獲，中間人自己也偽造了一對公私鑰，並將公鑰傳送給使用者以此來竊取客戶端生成的AES_KEY，在拿到AES_KEY之後就能輕鬆的進行解密了。
中間人這樣為所欲為，就沒有辦法制裁下嗎，當然有啊，接下來我們看看 HTTPS 是怎麼解決通訊安全問題的。
2. HTTPS 協議2.1 HTTPS 簡介HTTPS 其實是SSL+HTTP的簡稱,當然現在SSL基本已經被TLS取代了，不過接下來我們還是統一以SSL作為簡稱，SSL協議其實不止是應用在HTTP協議上，還在應用在各種應用層協議上，例如：FTP、WebSocket。
其實SSL協議大致就和上一節非對稱加密的性質一樣，握手的過程中主要也是為了交換秘鑰，然後再通訊過程中使用對稱加密進行通訊，大概流程如下：
這裡我只是畫了個示意圖，其實真正的 SSL 握手會比這個複雜的多，但是性質還是差不多，而且我們這裡需要關注的重點在於 HTTPS 是如何防止中間人攻擊的。
透過上圖可以觀察到，伺服器是透過 SSL 證書來傳遞公鑰，客戶端會對 SSL 證書進行驗證，其中證書認證體系就是確保SSL安全的關鍵，接下來我們就來講解下CA 認證體系，看看它是如何防止中間人攻擊的。
2.2 CA 認證體系上一節我們看到客戶端需要對伺服器返回的 SSL 證書進行校驗，那麼客戶端是如何校驗伺服器 SSL 證書的安全性呢。
權威認證機構
在 CA 認證體系中，所有的證書都是由權威機構來頒發，而權威機構的 CA 證書都是已經在作業系統中內建的，我們把這些證書稱之為CA根證書：
簽發證書
我們的應用伺服器如果想要使用 SSL 的話，需要透過權威認證機構來簽發CA證書，我們將伺服器生成的公鑰和站點相關資訊傳送給CA簽發機構，再由CA簽發機構透過伺服器傳送的相關資訊用CA簽發機構進行加簽，由此得到我們應用伺服器的證書，證書會對應的生成證書內容的簽名，並將該簽名使用CA簽發機構的私鑰進行加密得到證書指紋，並且與上級證書生成關係鏈。
這裡我們把百度的證書下載下來看看：
可以看到百度是受信於GlobalSign G2，同樣的GlobalSign G2是受信於GlobalSign R1，當客戶端(瀏覽器)做證書校驗時，會一級一級的向上做檢查，直到最後的根證書，如果沒有問題說明伺服器證書是可以被信任的。
如何驗證伺服器證書
那麼客戶端(瀏覽器)又是如何對伺服器證書做校驗的呢，首先會透過層級關係找到上級證書，透過上級證書裡的公鑰來對伺服器的證書指紋進行解密得到簽名(sign1)，再透過簽名演算法算出伺服器證書的簽名(sign2)，透過對比sign1和sign2，如果相等就說明證書是沒有被篡改也不是偽造的。
這裡有趣的是，證書校驗用的 RSA 是透過私鑰加密證書籤名，公鑰解密來巧妙的驗證證書有效性。
這樣透過證書的認證體系，我們就可以避免了中間人竊取AES_KEY從而發起攔截和修改 HTTP 通訊的報文。