Https比Http安全性？
Https是以安全為目標的Http版本，在Http上使用SSL層，進行加密傳輸（對稱和非對稱加密）萍悴，還具備身份驗證的功能（下面會重點說HTTPS的雙向驗證）岩齿。當然太颤，Https是需要配置CA證書的，一般要從某些機構購買盹沈。
為何Https依然會被截攘湔隆？
我們利用fiddler可以截取到了客戶端與后臺的https接口的明文內容乞封，這是一個可怕的問題做裙。目前的一些抓包工具，fiddler肃晚、charles使用了叫做man-in-the-middle（中間人）機制：
我們看到Fiddler抓取HTTPS協(xié)議主要由以下幾步進行：
- 第一步锚贱，Fiddler截獲客戶端發(fā)送給服務器的HTTPS請求，Fiddler偽裝成客戶端向服務器發(fā)送請求進行握手关串。
- 第二步拧廊，服務器發(fā)回相應，Fiddler獲取到服務器的CA證書晋修， 用根證書公鑰進行解密吧碾， 驗證服務器數據簽名， 獲取到服務器CA證書公鑰墓卦。然后Fiddler偽造自己的CA證書倦春， 冒充服務器證書傳遞給客戶端瀏覽器。
- 第三步趴拧，與普通過程中客戶端的操作相同溅漾，客戶端根據返回的數據進行證書校驗、生成密碼Pre_master著榴、用Fiddler偽造的證書公鑰加密添履，并生成HTTPS通信用的對稱密鑰enc_key。
- 第四步脑又，客戶端將重要信息傳遞給服務器暮胧， 又被Fiddler截獲。Fiddler將截獲的密文用自己偽造證書的私鑰解開问麸， 獲得并計算得到HTTPS通信用的對稱密鑰enc_key往衷。Fiddler將對稱密鑰用服務器證書公鑰加密傳遞給服務器。
- 第五步严卖，與普通過程中服務器端的操作相同席舍，服務器用私鑰解開后建立信任，然后再發(fā)送加密的握手消息給客戶端哮笆。
- 第六步来颤，Fiddler截獲服務器發(fā)送的密文汰扭， 用對稱密鑰解開， 再用自己偽造證書的私鑰加密傳給客戶端福铅。
- 第七步萝毛，客戶端拿到加密信息后，用公鑰解開滑黔，驗證HASH笆包。握手過程正式完成，客戶端與服務器端就這樣建立了”信任“略荡。
在之后的正常加密通信過程中庵佣，Fiddler如何在服務器與客戶端之間充當第三者呢？
服務器—>客戶端：Fiddler接收到服務器發(fā)送的密文撞芍， 用對稱密鑰解開秧了， 獲得服務器發(fā)送的明文跨扮。再次加密序无， 發(fā)送給客戶端。
客戶端—>服務端：客戶端用對稱密鑰加密衡创，被Fiddler截獲后帝嗡，解密獲得明文。再次加密璃氢，發(fā)送給服務器端哟玷。由于Fiddler一直擁有通信用對稱密鑰enc_key， 所以在整個HTTPS通信過程中信息對其透明一也。
從上面可以看到巢寡，Fiddler抓取HTTPS協(xié)議成功的關鍵是根證書（具體是什么，可Google）椰苟，這是一個信任鏈的起點抑月，這也是Fiddler偽造的CA證書能夠獲得客戶端和服務器端信任的關鍵。
從技術上講舆蝴，證書其實包含三部分谦絮，用戶的信息，用戶的公鑰洁仗，還有CA中心對該證書里面的信息的簽名层皱，要驗證一份證書的真?zhèn)危打炞CCA中心對該證書信息的簽名是否有效），需要用CA中心的公鑰驗證赠潦，而CA中心的公鑰存在于對這份證書進行簽名的證書內叫胖，故需要下載該證書，但使用該證書驗證又需先驗證該證書本身的真?zhèn)嗡拢视忠煤灠l(fā)該證書的證書來驗證瓮增，這樣一來就構成一條證書鏈的關系疲陕，這條證書鏈在哪里終結呢？答案就是根證書钉赁，根證書是一份特殊的證書蹄殃，它的簽發(fā)者是它本身，下載根證書就表明您對該根證書以下所簽發(fā)的證書都表示信任你踩，而技術上則是建立起一個驗證證書信息的鏈條诅岩，證書的驗證追溯至根證書即為結束。所以說用戶在使用自己的數字證書之前必須先下載根證書带膜。
這就解釋了問什么截取到了Https的數據吩谦，并且，Https在傳輸過程加密膝藕，所以到了客戶端已經不是Https傳輸加密的范圍了式廷，這個時候其實很多人都是這么解決的，對Https數據先自己進行加密（Ex：AES芭挽、RSA）滑废，再Https傳輸，這樣即使截取到Https數據袜爪，也看不到明文蠕趁。那么有沒有方式可以不讓fiddler&charles這種家伙截取到Https呢？有辛馆，就是Https的雙向驗證俺陋。
Https雙向驗證
服務器端對請求它的客戶端要進行身份驗證，客戶端對自己所請求的服務器也會做身份驗證昙篙。服務端一旦驗證到請求自己的客戶端為不可信任的腊状，服務端就拒絕繼續(xù)通信√桑客戶端如果發(fā)現服務端為不可信任的缴挖，那么也中止通信。具體怎么做呢硕蛹？如下圖所示醇疼。
