HTTPS協議是如何保證安全的?
相信大家對於HTTPS協議都不陌生，但是應該存在以下疑問：
- HTTPS協議到底是如何運作的?
- HTTPS是如何解決HTTP協議的不安全特性的?
- HTTPS網站抓包為什麼要信任證書?
HTTP協議
HTTP協議是一個應用層協議，通常執行在TCP協議之上。它是一個明文協議，客戶端發起請求，服務端給出響應的響應。
由於網路並不是可信任的，HTTP協議的明文特性會存在以下風險：
- 通訊資料有被竊聽和被篡改的風險
- 目標網站有被冒充的風險
一般的網站可能沒什麼影響，但是如果是銀行這種網站呢?
好在國內的銀行在HTTP協議時代針對IE開發了ActiveX外掛來保證安全性，這一點算是值得點讚了。
解決方案
既然HTTP協議是明文協議，如果對資料進行加密之後是否就能保證安全性了呢?
在回答這個問題之前，我們先看看比較常見的兩種加密演演算法。
加密演演算法
常見的有對稱加密演演算法和非對稱加密演演算法。
對稱加密
加密和解密使用同一個金鑰。加解密效率比非對稱加密高。但是金鑰一旦洩露，通訊就不安全了
非對稱加密
存在金鑰對，公鑰加密私鑰解密或者私鑰加密公鑰解密，無法通過公鑰反推私鑰，也無法通過私鑰反推公鑰。
一般情況下，使用非對稱加密來傳輸通訊所用的金鑰，通訊過程中採用對稱加密，可以解決對稱加密的安全問題以及非對稱加密的效能問題。
HTTP加密通訊過程
- 瀏覽器生成隨機串A作為通訊金鑰
- 瀏覽器使用公鑰將隨機串A加密後得到密文B傳送給伺服器，這一步是安全的，因為黑客沒有服務端私鑰無法解密
- 服務端利用私鑰解密出隨機串A得到通訊金鑰
- 服務端和客戶端用隨機串A以及對稱加密演演算法進行通訊
這麼一看似乎沒有問題，畢竟黑客無法破解非對稱加密的的內容，但是瀏覽器是如何得到公鑰的?
有以下兩種辦法：
- 瀏覽器內建(不太可能，網站域名這麼多，瀏覽器內建這麼多公鑰不現實)
- 伺服器給瀏覽器下發(由於是明文下發，存在被竊聽和篡改風險，也就是著名的中間人攻擊)
中間人攻擊
- 瀏覽器請求伺服器獲取公鑰
- 中間人劫持了伺服器的公鑰，儲存在自己手裡
- 中間人生成一對金鑰對，把偽造的公鑰下發給瀏覽器
- 瀏覽器使用偽造的公鑰和中間人通訊
- 中間人和伺服器進行通訊
由於瀏覽器使用了偽造的公鑰進行通訊，所以通訊過程是不可靠的
需要解決的問題
只要保證瀏覽器得到的公鑰是目標網站的公鑰即可保證通訊安全，那麼問題來了，如何在不可靠的網路上安全的傳輸公鑰呢?
這就是HTTPS協議需要解決的問題
HTTPS協議
HTTPS協議涉及到的知識很多，本文只關注金鑰安全交換部分，這也是HTTPS協議的精華。
HTTPS協議引入了CA和數字證書的概念。
數字證書
包含簽發機構、有效期、申請人公鑰、證書所有者、證書籤名演演算法、證書指紋以及指紋演演算法等資訊。
CA
數字證書籤發機構，權威CA是受作業系統信任的，安裝作業系統就會內建。
數字簽名
用Hash演演算法對資料進行計算得到Hash值，利用私鑰對該Hash加密得到簽名。
只有匹配的公鑰才能解密出簽名，來保證簽名是本人私鑰簽發的
證書籤發過程
- 網站生成金鑰對，將私鑰自己儲存，公鑰和網站域名等資訊提交給CA
- CA把證書籤發機構(也就是自己)、證書有效期、網站的公鑰、網站域名等資訊以明文形式寫入到一個文字檔案
- CA選擇一個指紋演演算法(一般為hash演演算法)計算文字檔案的內容得到指紋，用CA的私鑰對指紋和指紋演演算法進行加密得到數字簽名，簽名演演算法包含在證書的明文部分
- CA把明文證書、指紋、指紋演演算法、數字簽名等資訊打包在一起得到證書下發給伺服器
- 此時伺服器擁有了權威CA頒發的數字證書以及自己的私鑰
證書驗證過程
瀏覽器是如何驗證網站的有效性的呢?
- 瀏覽器以HTTPS協議請求伺服器的443埠
- 伺服器下發自己的數字證書給瀏覽器(明文)
- 瀏覽器先校驗CA、有效期、域名是否有效，如果無效，則終止連線(伺服器此時不可信任)
- 如果有效，則從作業系統取出證書頒發機構的公鑰，根據簽名演演算法對數字簽名解密得到證書指紋和指紋演演算法
- 瀏覽器用解密得到的指紋演演算法計算證書的指紋，與解密得到的指紋進行比對，如果一致，證書有效，公鑰也安全拿到了
- 瀏覽器此時已經和真實的伺服器進行通訊了，中間人無法得知通訊內容，因為中間人沒有網站私鑰
問題是如何解決的
-
黑客冒充CA給了一個假證書給瀏覽器
瀏覽器通過CA名稱從作業系統取出CA公鑰時對數字簽名進行解密，發現解密失敗，證明這個CA簽名用的私鑰和作業系統內建的不是一對，就發現了偽造
-
黑客篡改了證書中的網站公鑰
證書中的網站公鑰可以被篡改，但是數字簽名是CA私鑰計算出來的，黑客無法計算數字簽名，瀏覽器用內建的CA公鑰對數字簽名解密時就會發現指紋不匹配了，這也發現了偽造
-
黑客也能正常獲取網站公鑰
的確，黑客自己通過瀏覽器訪問網站時也能得到公鑰，這個公鑰跟正常使用者的公鑰是一致的。
但是每個客戶端和伺服器通訊使用的對稱金鑰都是臨時生成且隨機的，黑客只能知道自己的隨機金鑰，但是不知道其他的隨機金鑰
綜上，瀏覽器通過作業系統內建權威CA公鑰的方式解決了網站公鑰下發問題。
HTTPS中間人攻擊
HTTPS從協議上解決了HTTP時代的中間人攻擊問題，但是HTTPS在使用者主動信任了偽造證書的時候也會發生中間人攻擊(比如早期的12306需要手動信任證書)，HTTPS中間人攻擊流程如下：
- 客戶端用HTTPS連線伺服器的443埠
- 伺服器下發自己的數字證書給客戶端
- 黑客劫持了伺服器的真實證書，並偽造了一個假的證書給瀏覽器
- 瀏覽器可以發現得到的網站證書是假的，但是瀏覽器選擇信任
- 瀏覽器生成隨機對稱金鑰A，用偽造的證書中的公鑰加密發往伺服器
- 黑客同樣可以劫持這個請求，得到瀏覽器的對稱金鑰A，從而能夠竊聽或者篡改通訊資料
- 黑客利用伺服器的真實公鑰將客戶端的對稱金鑰A加密發往伺服器
- 伺服器利用私鑰解密這個對稱金鑰A之後與黑客通訊
- 黑客利用對稱金鑰A解密伺服器的資料，篡改之後利用對稱金鑰A加密發給客戶端
- 客戶端收到的資料已經是不安全的了
以上就是HTTPS中間人攻擊的原理，這也就是HTTPS抓包為什麼要信任證書的原因。
總結
- 作業系統內建權威CA公鑰來保證數字簽名以及數字證書的安全性
- 實施HTTPS中間人攻擊需要手動信任攻擊者的假證書