HTTPS協議是如何保證安全的?

相信你們對於HTTPS協議都不陌生，可是應該存在如下疑問：

1. HTTPS協議究竟是如何運做的?
2. HTTPS是如何解決HTTP協議的不安全特性的?
3. HTTPS網站抓包爲何要信任證書?

HTTP協議

HTTP協議是一個應用層協議，一般運行在TCP協議之上。它是一個明文協議，客戶端發起請求，服務端給出響應的響應。

因爲網絡並非可信任的，HTTP協議的明文特性會存在如下風險：

• 通訊數據有被竊聽和被篡改的風險
• 目標網站有被冒充的風險

通常的網站可能沒什麼影響，可是若是是銀行這種網站呢?

好在國內的銀行在HTTP協議時代針對IE開發了ActiveX插件來保證安全性，這一點算是值得點讚了。

解決方案

既然HTTP協議是明文協議，若是對數據進行加密以後是否就能保證安全性了呢?

在回答這個問題以前，咱們先看看比較常見的兩種加密算法。

加密算法

常見的有對稱加密算法和非對稱加密算法。

對稱加密

加密和解密使用同一個密鑰。加解密效率比非對稱加密高。可是密鑰一旦泄露，通訊就不安全了

非對稱加密

存在密鑰對，公鑰加密私鑰解密或者私鑰加密公鑰解密，沒法經過公鑰反推私鑰，也沒法經過私鑰反推公鑰。

通常狀況下，使用非對稱加密來傳輸通訊所用的密鑰，通訊過程當中採用對稱加密，能夠解決對稱加密的安全問題以及非對稱加密的性能問題。

HTTP加密通訊過程

1. 瀏覽器生成隨機串A做爲通訊密鑰
2. 瀏覽器使用公鑰將隨機串A加密後獲得密文B發送給服務器，這一步是安全的，由於黑客沒有服務端私鑰沒法解密
3. 服務端利用私鑰解密出隨機串A獲得通訊密鑰
4. 服務端和客戶端用隨機串A以及對稱加密算法進行通訊

這麼一看彷佛沒有問題，畢竟黑客沒法破解非對稱加密的的內容，可是瀏覽器是如何獲得公鑰的?

有如下兩種辦法：

1. 瀏覽器內置(不太可能，網站域名這麼多，瀏覽器內置這麼多公鑰不現實)
2. 服務器給瀏覽器下發(因爲是明文下發，存在被竊聽和篡改風險，也就是著名的中間人攻擊)

中間人攻擊

1. 瀏覽器請求服務器獲取公鑰
2. 中間人劫持了服務器的公鑰，保存在本身手裏
3. 中間人生成一對密鑰對，把僞造的公鑰下發給瀏覽器
4. 瀏覽器使用僞造的公鑰和中間人通訊
5. 中間人和服務器進行通訊

因爲瀏覽器使用了僞造的公鑰進行通訊，因此通訊過程是不可靠的

須要解決的問題

只要保證瀏覽器獲得的公鑰是目標網站的公鑰便可保證通訊安全，那麼問題來了，如何在不可靠的網絡上安全的傳輸公鑰呢?

這就是HTTPS協議須要解決的問題

HTTPS協議

HTTPS協議涉及到的知識不少，本文只關注密鑰安全交換部分，這也是HTTPS協議的精華。

HTTPS協議引入了CA和數字證書的概念。

數字證書

包含簽發機構、有效期、申請人公鑰、證書全部者、證書籤名算法、證書指紋以及指紋算法等信息。

CA

數字證書籤發機構，權威CA是受操做系統信任的，安裝操做系統就會內置。

數字簽名

用Hash算法對數據進行計算獲得Hash值，利用私鑰對該Hash加密獲得簽名。

只有匹配的公鑰才能解密出簽名，來保證簽名是本人私鑰簽發的

證書籤發過程

1. 網站生成密鑰對，將私鑰本身保存，公鑰和網站域名等信息提交給CA
2. CA把證書籤發機構(也就是本身)、證書有效期、網站的公鑰、網站域名等信息以明文形式寫入到一個文本文件
3. CA選擇一個指紋算法(通常爲hash算法)計算文本文件的內容獲得指紋，用CA的私鑰對指紋和指紋算法進行加密獲得數字簽名，簽名算法包含在證書的明文部分
4. CA把明文證書、指紋、指紋算法、數字簽名等信息打包在一塊兒獲得證書下發給服務器
5. 此時服務器擁有了權威CA頒發的數字證書以及本身的私鑰

證書驗證過程

瀏覽器是如何驗證網站的有效性的呢?

1. 瀏覽器以HTTPS協議請求服務器的443端口
2. 服務器下發本身的數字證書給瀏覽器(明文)
3. 瀏覽器先校驗CA、有效期、域名是否有效，若是無效，則終止鏈接(服務器此時不可信任)
4. 若是有效，則從操做系統取出證書頒發機構的公鑰，根據簽名算法對數字簽名解密獲得證書指紋和指紋算法
5. 瀏覽器用解密獲得的指紋算法計算證書的指紋，與解密獲得的指紋進行比對，若是一致，證書有效，公鑰也安全拿到了
6. 瀏覽器此時已經和真實的服務器進行通訊了，中間人沒法得知通訊內容，由於中間人沒有網站私鑰

問題是如何解決的

1. 黑客冒充CA給了一個假證書給瀏覽器

   瀏覽器經過CA名稱從操做系統取出CA公鑰時對數字簽名進行解密，發現解密失敗，證實這個CA簽名用的私鑰和操做系統內置的不是一對，就發現了僞造

2. 黑客篡改了證書中的網站公鑰

   證書中的網站公鑰能夠被篡改，可是數字簽名是CA私鑰計算出來的，黑客沒法計算數字簽名，瀏覽器用內置的CA公鑰對數字簽名解密時就會發現指紋不匹配了，這也發現了僞造

3. 黑客也能正常獲取網站公鑰

   的確，黑客本身經過瀏覽器訪問網站時也能獲得公鑰，這個公鑰跟正經常使用戶的公鑰是一致的。

   可是每一個客戶端和服務器通訊使用的對稱密鑰都是臨時生成且隨機的，黑客只能知道本身的隨機密鑰，可是不知道其餘的隨機密鑰

綜上，瀏覽器經過操做系統內置權威CA公鑰的方式解決了網站公鑰下發問題。

HTTPS中間人攻擊

HTTPS從協議上解決了HTTP時代的中間人攻擊問題，可是HTTPS在用戶主動信任了僞造證書的時候也會發生中間人攻擊(好比早期的12306須要手動信任證書)，HTTPS中間人攻擊流程以下：

1. 客戶端用HTTPS鏈接服務器的443端口
2. 服務器下發本身的數字證書給客戶端
3. 黑客劫持了服務器的真實證書，並僞造了一個假的證書給瀏覽器
4. 瀏覽器能夠發現獲得的網站證書是假的，可是瀏覽器選擇信任
5. 瀏覽器生成隨機對稱密鑰A，用僞造的證書中的公鑰加密發往服務器
6. 黑客一樣能夠劫持這個請求，獲得瀏覽器的對稱密鑰A，從而可以竊聽或者篡改通訊數據
7. 黑客利用服務器的真實公鑰將客戶端的對稱密鑰A加密發往服務器
8. 服務器利用私鑰解密這個對稱密鑰A以後與黑客通訊
9. 黑客利用對稱密鑰A解密服務器的數據，篡改以後利用對稱密鑰A加密發給客戶端
10. 客戶端收到的數據已是不安全的了

以上就是HTTPS中間人攻擊的原理，這也就是HTTPS抓包爲何要信任證書的緣由。

總結

1. 操做系統內置權威CA公鑰來保證數字簽名以及數字證書的安全性
2. 實施HTTPS中間人攻擊須要手動信任攻擊者的假證書