Https及其安全性

Https比Http安全性？

Https是以安全為目標的Http版本，在Http上使用SSL層，進行加密傳輸（對稱和非對稱加密），還具備身份驗證的功能（下面會重點說HTTPS的雙向驗證）。當然，Https是需要配置CA證書的，一般要從某些機構購買。

為何Https依然會被擷取？

我們利用fiddler可以擷取到了客戶端與後臺的https介面的明文內容，這是一個可怕的問題。目前的一些抓包工具，fiddler、charles使用了叫做man-in-the-middle（中間人）機制：

我們看到Fiddler抓取HTTPS協議主要由以下幾步進行：

1. 第一步，Fiddler截獲客戶端傳送給伺服器的HTTPS請求，Fiddler偽裝成客戶端向伺服器傳送請求進行握手。
2. 第二步，伺服器發回相應，Fiddler獲取到伺服器的CA證書， 用根證書公鑰進行解密， 驗證伺服器資料簽名， 獲取到伺服器CA證書公鑰。然後Fiddler偽造自己的CA證書， 冒充伺服器證書傳遞給客戶端瀏覽器。
3. 第三步，與普通過程中客戶端的操作相同，客戶端根據返回的資料進行證書校驗、生成密碼Pre_master、用Fiddler偽造的證書公鑰加密，並生成HTTPS通訊用的對稱金鑰enc_key。
4. 第四步，客戶端將重要資訊傳遞給伺服器， 又被Fiddler截獲。Fiddler將截獲的密文用自己偽造證書的私鑰解開， 獲得並計算得到HTTPS通訊用的對稱金鑰enc_key。Fiddler將對稱金鑰用伺服器證書公鑰加密傳遞給伺服器。
5. 第五步，與普通過程中伺服器端的操作相同，伺服器用私鑰解開後建立信任，然後再傳送加密的握手訊息給客戶端。
6. 第六步，Fiddler截獲伺服器傳送的密文， 用對稱金鑰解開， 再用自己偽造證書的私鑰加密傳給客戶端。
7. 第七步，客戶端拿到加密資訊後，用公鑰解開，驗證HASH。握手過程正式完成，客戶端與伺服器端就這樣建立了”信任“。

在之後的正常加密通訊過程中，Fiddler如何在伺服器與客戶端之間充當第三者呢？

伺服器—>客戶端：Fiddler接收到伺服器傳送的密文， 用對稱金鑰解開， 獲得伺服器傳送的明文。再次加密， 傳送給客戶端。
客戶端—>服務端：客戶端用對稱金鑰加密，被Fiddler截獲後，解密獲得明文。再次加密，傳送給伺服器端。由於Fiddler一直擁有通訊用對稱金鑰enc_key， 所以在整個HTTPS通訊過程中資訊對其透明。

從上面可以看到，Fiddler抓取HTTPS協議成功的關鍵是根證書（具體是什麼，可Google），這是一個信任鏈的起點，這也是Fiddler偽造的CA證書能夠獲得客戶端和伺服器端信任的關鍵。

從技術上講，證書其實包含三部分，使用者的資訊，使用者的公鑰，還有CA中心對該證書裡面的資訊的簽名，要驗證一份證書的真偽（即驗證CA中心對該證書資訊的簽名是否有效），需要用CA中心的公鑰驗證，而CA中心的公鑰存在於對這份證書進行簽名的證書內，故需要下載該證書，但使用該證書驗證又需先驗證該證書本身的真偽，故又要用簽發該證書的證書來驗證，這樣一來就構成一條證書鏈的關係，這條證書鏈在哪裡終結呢？答案就是根證書，根證書是一份特殊的證書，它的簽發者是它本身，下載根證書就表明您對該根證書以下所簽發的證書都表示信任，而技術上則是建立起一個驗證證書資訊的鏈條，證書的驗證追溯至根證書即為結束。所以說使用者在使用自己的數字證書之前必須先下載根證書。

這就解釋了問什麼擷取到了Https的資料，並且，Https在傳輸過程加密，所以到了客戶端已經不是Https傳輸加密的範圍了，這個時候其實很多人都是這麼解決的，對Https資料先自己進行加密（Ex：AES、RSA），再Https傳輸，這樣即使擷取到Https資料，也看不到明文。那麼有沒有方式可以不讓fiddler&charles這種傢伙擷取到Https呢？有，就是Https的雙向驗證。

Https雙向驗證

伺服器端對請求它的客戶端要進行身份驗證，客戶端對自己所請求的伺服器也會做身份驗證。服務端一旦驗證到請求自己的客戶端為不可信任的，服務端就拒絕繼續通訊。客戶端如果發現服務端為不可信任的，那麼也中止通訊。具體怎麼做呢？如下圖所示。