秒懂HTTPS介面（原理篇）
文章目錄
前言
講HTTPS之前，我們先來回顧一下HTTP協議。HTTP是一種超文字傳輸協議，它是無狀態的、簡單快速的、基於 TCP 的可靠傳輸協議。
既然 HTTP 協議這麼好，那為什麼又冒出來了一個 HTTPS 呢？HTTP本身不具備加密的功能，所以也就無法做到對通訊整體內容進行加密，
也就是說HTTP是明文傳輸的，這就造成了很大的安全隱患。在網路傳輸過程中，只要資料包被人劫持，那你就相當於赤身全裸的暴露在他人面前，毫無半點隱私可言。想象一下，如果你連了一個不可信的WIFI，正好有使用了某個支付軟體進行了支付操作，那麼你的密碼可能就到別人手裡去了，後果可想而知。
網路環境的就是這樣，給你帶來便利的同時，也到處充滿了挑戰與風險。對於小白使用者，你不能期望他有多高的網路安全意識，產品應該通過技術手段，讓自己變得更安全，從源頭來控制風險。這就誕生了HTTPS協議。
HTTPS簡介
因為HTTP是明文傳輸，所以造成了安全隱患。如何讓資料傳輸以加密的方式進行，就消除了該隱患。而SSL/TSL提供認證和加密處理及摘要功能。
為了統一解決上述的問題，需要在HTTP上加密處理和認證等機制。我們把添加了加密和認證機制的HTTP稱為HTTPS。
HTTPS並非是應用層的一種新協議，只是通訊介面部分用SSL/TLS協議代替而已。
所謂的HTTPS，簡單理解就是身披SSL/TLS協議殼的HTTP
從網路的七層模型來看，原先的四層 TCP 到七層 HTTP 之間是明文傳輸，在這之間加一個負責資料加解密的傳輸層（SSL/TLS），保證在網路傳輸的過程中資料是加密的，而HTTP接收到的依然是明文資料，不會有任何影響。
SSL是Netscape開發的專門使用者保護Web通訊的，目前版本為3.0。最新版本的TLS 1.0是IETF(工程任務組)制定的一種新的協議，它建立在SSL 3.0協議規範之上，是SSL 3.0的後續版本。兩者差別極小，可以理解為SSL 3.1，它是寫入了RFC的。
HTTPS實現原理
大致原理
通過上面的介紹，對HTTPS有了大致的瞭解。可本質問題還沒說，HTTPS是如何實現資料的加密傳輸？
首先，先來了解下加密演算法的方式，常用的有兩種：對稱加密與非對稱加密。
- 對稱加密：即通訊雙方通過相同的金鑰進行資訊的加解密。加解密速度快，但是安全性較差，如果其中一方洩露了金鑰，那加密過程就會被人破解。
- 非對稱加密：相比對稱加密，它一般有公鑰和私鑰。公鑰負責資訊加密，私鑰負責資訊解密。兩把金鑰分別由傳送雙發各自保管，加解密過程需兩把金鑰共同完成。安全性更高，但同時計算量也比對稱加密要大很多。
技術細節
對於網路通訊過程，在安全的前提下，還是需要保證響應速度。如何每次都進行非對稱計算，通訊過程勢必會受影響。所以，人們希望的安全傳輸，最終肯定是以對稱加密的方式進行。如圖：
首先 Session Key是如何得到的，並且在 Session Key之前的傳輸都是明文的。Session Key通過網路傳輸肯定不安全，所以它一定各自加密生成的。因此在這之前，雙方還要互通，確認加密的演算法，並且各自新增隨機數，提高安全性。如圖：
這樣雙方確認了使用的 SSL/TLS 版本，以及生成 Session Key的加密演算法。並且雙方擁有了2個隨機數（客戶端、服務端各自生成一個）。可是如果按照目前的隨機引數，加上加密演算法生成Session Key呢，還是存在風險，加密演算法是有限固定的，而且隨機數都是明文傳輸的，有被截獲的可能。
讓加密演算法變得不可預測，可能性不大。那麼能否再傳輸一個加密的隨機數，這個隨機數就算被截獲，也無法破譯。這就用到了非對稱加密演算法，我們在步驟二中，把公鑰傳輸給客戶端。這樣客戶端的第三個隨機數用公鑰加密，只有擁有私鑰的服務端才能破譯第三個引數，這樣生成的 Session 就是安全的了。如圖：
看似完成了，現在生成的 Session Key 是不可預測的（就算被截獲也無所謂），我們可以放心的進行私密通訊了。真的是這樣嗎？我們似乎對服務端給的公鑰十分信任，如果你目前通訊的本身就不可信，或者被中間人劫持，由它傳送偽造的公鑰給你，那後果可想而知，這就是傳說中的“中間人攻擊”。
所以，我們得包裝一下公鑰，讓它變得安全。這就引出了數字證書的概念，數字證書由受信任的證書機構頒發，證書包含證書檔案與證書私鑰檔案。私鑰檔案由服務端自己儲存，證書檔案傳送給請求的客戶端，檔案包含了域名資訊、公鑰以及相應的校驗碼。客戶可以根據得到的證書檔案，校驗證書是否可信。如圖：
通俗的表示整個流程如圖：
證書示例：
Extended Validation（EV）：該級別的證書具有最高的安全性，也是最值得信任的。它除了給出更詳細的公司/組織資訊外，還在瀏覽器的位址列上直接給出了公司名稱。
示例：https://www.github.com
小故事
如果上面的技術細節沒怎麼看太懂？來，我們來講個故事。
我們在網路的行為（例如看瀏覽、上傳圖片、聊天），簡單來說都是向伺服器傳送訊息、接收伺服器的訊息，這個過程很像信鴿傳書。
為了更加形象，我們把通訊過程中的主要角色伺服器、客戶端、黑客的稱呼也替換一下，小服、小客、小黑。
如小客想給小服傳送資訊，那麼她就把信綁在信鴿腿上，放出信鴿，小服接到信鴿，拿到信紙讀訊息，這個過程就完成了，很不錯，簡單方便。
但是，壞人小黑出現了，他把正在愉快飛翔的信鴿抓了下來，並把信給換了，這就麻煩了，小服得到了假訊息。
這就是 HTTP 的溝通方式，方便但極不安全，不能傳遞重要資訊。
但是小服和小客很聰明，想到了一個好辦法，他們設定了一套編碼規則：把字母偏移3個位置，例如，D → A、E → B、F → C，這樣，原本的訊息“secret message” 就變成了 “pbzobq jbppxdb”。
小黑截獲到訊息後就會一臉懵逼，看不懂改不了，但是小服知道解碼規則，可以輕鬆轉化成原文。
這個方式就是“對稱式加密”。
對稱式加密很安全，只要保護好key，別讓其他人知道即可，但也有個問題，如果小服和小客在通訊之前不認識，他們就沒辦法設定加密規則。
為了解決這個問題，通訊方式又一次升級了，比如小客向給小服傳送資訊，他們的通訊流程如下：
- 小客讓信鴿飛到小服那兒，但啥也沒帶，沒有資訊。
- 小服讓信鴿帶著一個箱子和一把開著的鎖飛回到小客，小服自己留著鎖的鑰匙。小服讓信鴿帶著一個箱子和一把開著的鎖飛回到小客，小服自己留著鎖的鑰匙。
- 小客把信放到箱子裡，並用鎖把箱子鎖上，讓信鴿把箱子帶給小服。小客把信放到箱子裡，並用鎖把箱子鎖上，讓信鴿把箱子帶給小服。
- 小服收到箱子，用鑰匙開鎖，拿到信
- 這樣小黑就沒招兒了，小服和小客可以愉快的通訊了。這樣小黑就沒招兒了，小服和小客可以愉快的通訊了。
這個方式就是“非對稱加密”，這個箱子就是公鑰，開鎖的鑰匙就是私鑰。
細想一下，有個問題，小客怎麼確認箱子來自小服而不是小黑呢？為此，小服決定給箱子籤個名，小客收到後先檢查一下簽名就可以確認了。
但這樣還不夠穩妥，小服決定讓最權威的小明來簽名，小明是幹啥的？他非常有名望，是個絕對值得信賴的傢伙，他的簽名大家都認，小明就是大名鼎鼎的 CA（Certification Authority）。
小服與小明建立了合作，小明收到小服的請求就會為她簽名，而小黑是得不到小明給小客的簽名的，這樣小服就可以放心了。
這就是HTTPS的通訊通俗原理了，是不是很好理解。
我們可以看到 HTTPS 比 HTTP的流程重了很多，有個箱子，還有簽名，還增加了往返過程，效能肯定有所影響，這一切都是為了安全，所以我們要根據自己的需求場景來選擇什麼時候使用 HTTPS，什麼時候使用 HTTP。
相關係列：
秒懂HTTPS介面（實現篇）
秒懂HTTPS介面（介面測試篇）
秒懂HTTPS介面（JMeter壓測篇）
參考文獻：
[1]上野宣,於均良譯.圖解HTTP.北京:人民郵電出版社,2014.
[2]https://github.com/jasonGeng88/blog/blob/master/201705/https.md