1. HTTP 協議
在談論 HTTPS 協議以前，先來回顧一下 HTTP 協議的概念。html
1.1 HTTP 協議介紹
HTTP 協議是一種基於文本的傳輸協議，它位於 OSI 網絡模型中的應用層。web
HTTP 協議是經過客戶端和服務器的請求應答來進行通信，目前協議由以前的 RFC 2616 拆分紅立六個單獨的協議說明（RFC 7230、RFC 723一、RFC 723二、RFC 723三、RFC 723四、RFC 7235），通信報文以下：算法
-
請求
POST http://www.baidu.com HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Content-Length: 7
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
wd=HTTP
-
響應
HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Date: Thu, 14 Feb 2019 07:23:49 GMT
Transfer-Encoding: chunked
<html>...</html>
1.2 HTTP 中間人攻擊
HTTP 協議使用起來確實很是的方便，可是它存在一個致命的缺點：不安全。瀏覽器
咱們知道 HTTP 協議中的報文都是以明文的方式進行傳輸，不作任何加密，這樣會致使什麼問題呢？下面來舉個例子：安全
-
小明在 JAVA 貼吧發帖，內容爲 我愛JAVA：
-
被中間人進行攻擊，內容修改成 我愛PHP
-
小明被羣嘲(手動狗頭)
能夠看到在 HTTP 傳輸過程當中，中間人能看到而且修改 HTTP 通信中全部的請求和響應內容，因此使用 HTTP 是很是的不安全的。服務器
1.3 防止中間人攻擊
這個時候可能就有人想到了，既然內容是明文那我使用對稱加密的方式將報文加密這樣中間人不就看不到明文了嗎，因而以下改造：微信
-
雙方約定加密方式
-
使用 AES 加密報文
這樣看似中間人獲取不到明文信息了，但其實在通信過程當中仍是會以明文的方式暴露加密方式和祕鑰，若是第一次通訊被攔截到了，那麼祕鑰就會泄露給中間人，中間人仍然能夠解密後續的通訊：網絡
那麼對於這種狀況，咱們確定就會考慮能不能將祕鑰進行加密不讓中間人看到呢？答案是有的，採用非對稱加密，咱們能夠經過 RSA 算法來實現。app
在約定加密方式的時候由服務器生成一對公私鑰，服務器將公鑰返回給客戶端，客戶端本地生成一串祕鑰(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 通信的報文。
總結
首先先經過對 HTTP 中間人攻擊的來了解到 HTTP 爲何是不安全的，而後再從安全攻防的技術演變一直到 HTTPS 的原理歸納，但願能讓你們對 HTTPS 有個更深入的瞭解。
本文分享自微信公衆號 - Java旅途（Javatrip）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。