一 前言

　　在說HTTPS之前先說說什麼是HTTP，HTTP就是我們平時瀏覽網頁時候使用的一種協議。HTTP協議傳輸的資料都是未加密的，也就是明文的，因此使用HTTP協議傳輸隱私資訊非常不安全。為了保證這些隱私資料能加密傳輸，於是網景公司設計了SSL（Secure Sockets Layer）協議用於對HTTP協議傳輸的資料進行加密，從而就誕生了HTTPS。SSL目前的版本是3.0，被IETF（Internet Engineering Task Force）定義在RFC 6101中，之後IETF對SSL 3.0進行了升級，於是出現了TLS（Transport Layer Security） 1.0，定義在RFC 2246。實際上我們現在的HTTPS都是用的TLS協議，但是由於SSL出現的時間比較早，並且依舊被現在瀏覽器所支援，因此SSL依然是HTTPS的代名詞，但無論是TLS還是SSL都是上個世紀的事情，SSL最後一個版本是3.0，今後TLS將會繼承SSL優良血統繼續為我們進行加密服務。目前TLS的版本是1.2，定義在RFC 5246中，暫時還沒有被廣泛的使用 ()

概念可參考百科

二  HTTPS 驗證原理

　　Https在真正請求資料前，先會與服務有幾次握手驗證，以證明相互的身份，以下圖為例

2.1  驗證流程

 注：文中所寫的序號與圖不對應但流程是對應的

1 客戶端發起一個https的請求，把自身支援的一系列Cipher Suite（金鑰演算法套件，簡稱Cipher）傳送給服務端

2  服務端，接收到客戶端所有的Cipher後與自身支援的對比，如果不支援則連線斷開，反之則會從中選出一種加密演算法和HASH演算法

   以證書的形式返回給客戶端 證書中還包含了 公鑰 頒證機構 網址 失效日期等等。

3

客戶端收到服務端響應後會做以下幾件事

    3.1 驗證證書的合法性    

　　  頒發證書的機構是否合法與是否過期，證書中包含的網站地址是否與正在訪問的地址一致等

        證書驗證通過後，在瀏覽器的位址列會加上一把小鎖(每家瀏覽器驗證通過後的提示不一樣 不做討論)

   3.2 生成隨機密碼

        如果證書驗證通過，或者使用者接受了不授信的證書，此時瀏覽器會生成一串隨機數，然後用證書中的公鑰加密。 　　　　　　

    3.3 HASH握手資訊

       用最開始約定好的HASH方式，把握手訊息取HASH值，  然後用 隨機數加密 “握手訊息+握手訊息HASH值(簽名)”  並一起傳送給服務端

       在這裡之所以要取握手訊息的HASH值，主要是把握手訊息做一個簽名，用於驗證握手訊息在傳輸過程中沒有被篡改過。

4  服務端拿到客戶端傳來的密文，用自己的私鑰來解密握手訊息取出隨機數密碼，再用隨機數密碼 解密 握手訊息與HASH值，並與傳過來的HASH值做對比確認是否一致。

    然後用隨機密碼加密一段握手訊息(握手訊息+握手訊息的HASH值 )給客戶端

5  客戶端用隨機數解密並計算握手訊息的HASH，如果與服務端發來的HASH一致，此時握手過程結束，之後所有的通訊資料將由之前瀏覽器生成的隨機密碼並利用對稱加密演算法進行加密  

     因為這串金鑰只有客戶端和服務端知道，所以即使中間請求被攔截也是沒法解密資料的，以此保證了通訊的安全

非對稱加密演算法：RSA，DSA/DSS     在客戶端與服務端相互驗證的過程中用的是對稱加密 
對稱加密演算法：AES，RC4，3DES     客戶端與服務端相互驗證通過後，以隨機數作為金鑰時，就是對稱加密
HASH演算法：MD5，SHA1，SHA256  在確認握手訊息沒有被篡改時 

2.2  客戶端如何驗證 證書的合法性？

1. 驗證證書是否在有效期內。

　　在服務端面返回的證書中會包含證書的有效期，可以通過失效日期來驗證 證書是否過期

2. 驗證證書是否被吊銷了。

　　被吊銷後的證書是無效的。驗證吊銷有CRL(證書吊銷列表)和OCSP(線上證書檢查)兩種方法。

證書被吊銷後會被記錄在CRL中，CA會定期釋出CRL。應用程式可以依靠CRL來檢查證書是否被吊銷了。

CRL有兩個缺點，一是有可能會很大，下載很麻煩。針對這種情況有增量CRL這種方案。二是有滯後性，就算證書被吊銷了，應用也只能等到釋出最新的CRL後才能知道。

增量CRL也能解決一部分問題，但沒有徹底解決。OCSP是線上證書狀態檢查協議。應用按照標準傳送一個請求，對某張證書進行查詢，之後伺服器返回證書狀態。

OCSP可以認為是即時的（實際實現中可能會有一定延遲），所以沒有CRL的缺點。

3. 驗證證書是否是上級CA簽發的。

windows中保留了所有受信任的根證書，瀏覽器可以檢視信任的根證書，自然可以驗證web伺服器的證書， 是不是由這些受信任根證書頒發的或者受信任根證書的二級證書機構頒發的（根證書機構可能會受權給底下的中級證書機構，然後由中級證書機構頒發中級證書） 在驗證證書的時候，瀏覽器會呼叫系統的證書管理器介面對證書路徑中的所有證書一級一級的進行驗證，只有路徑中所有的證書都是受信的，整個驗證的結果才是受信

三  手機如何抓取HTTPS的請求資料

　　　　當站點由HTTP轉成HTTPS後是更安全了，但是有時候要看線上的請求資料解決問題時卻麻煩了，因為是HTTPS的請求，你就算攔截到了那也是加密的資料，沒有任何意義。 　　那有方法解決嗎？ 答案是肯定的！ 接下來就來個例項教程，教大家如何檢視HTTPS的請求資料 　　首先需要安裝Fiddler 用於攔截請求，和頒發https證書 3.1  Fiddler根證書匯出   按圖中操作把匯出，再將匯出的的根證書"FiddlerRoot.cer" 的後輟名 改為"crt"  "FiddlerRoot.crt" 因為手機沒法直接安裝 cer格式的證書      3.2  證書安裝 　 在本機把證書移到本機IIS中的某個網站的物理目錄中，然後在手機瀏覽器中訪問該證書的目錄 如："192.168.0.102：8001/FiddlerRoot.crt"  如圖      　　此時手機會提示按裝根證書，其實安裝一個不受信的根證書是非常危險的，如果你安裝了某些釣魚網站或者有危害的根證書，那隻要是該根證書下的所有證書都會驗證通過， 那隨便一個釣魚網的網站只要安裝了該根證書下的證書，都不會有任何警告提示。 很可能讓使用者有財產損失。所以在安裝根證書時，手機系統會要求你輸入鎖屏密碼，以確保是本人操作。 安裝過程如下 　　Fiddler的根證書名字都提示了是不受信的根證書      安裝完成      3.3  通過Fiddler抓取手機的HTTPS請求        Fiddler預設偵聽的埠是8888,把手機WiFI的Http 代理設為本機Fiddler的地址如下圖    這樣手機上所有的請求都會先通過Fiddler，Fiddler再轉發到目標伺服器 注意： 在家中的路由器中有線與無線通常不在一個網段，會導致Fiddler無法抓到手機的包，需要手動設定路由，可自行百度          代理也設好之後便可以開始抓到Https的請求內容瞭如圖 Https的預設埠號是 “443”可以看出紅框中的是未裝根證書前的請求，加了一把小鎖，而且請求記錄都是灰色的 而安裝證書後請求則一切正常，請求內容也都可以正常看到。      3.4  為什麼安裝了Fiddler根證書可以看到Https請求內容 　　要解釋這個問題，就需要了解最開始的Https的驗證原理了，回顧一下，先是客戶端把自己支援的加密方式提交到服務端，然後服務端 會返回一個證書 到這一步問題來了，手機未什麼要安裝Fiddler的證書呢？ 　　第一 因為Fiddler在客戶端(手機)發出Https請求時，充當了伺服器的角色，需要返回一個證書給客戶端， 但是Fiddler的證書並不是CA機構頒發的，客戶端一驗證就知道是假的連線肯定就斷了，那怎麼辦呢？ 那就想辦法讓客戶端信任這個服務端，於是就在客戶端安裝一個Fiddler的根證書。 所以只要是通過Fiddler的Https請求，驗證根證書時自然會通過，因為Fiddler的根證書你已經受信了！      第二 現在只是客戶端(手機)和Fiddler這個偽服務端的Https驗證通過了，還沒有到真正的服務端去取資料的，此時Fiddler會以客戶端的身份與真正的服務端再進行一次HTTPS的驗證，最後拿到資料後 又以服務端的身份與客戶端(手機)通訊。也就是說在一次請求中資料被兩次加解密，一次是手機到Fiddler，一次是Fiddler到真正的服務端。 整個過程  手機----》Fiddler----》 伺服器  Fiddler 即充當了服務端又充當了客戶端，才使得資料能夠正常的互動，這個過程中最重要的一環就是手機端安裝的 根證書！

四  總結

　寫了這麼多，其實也只是把Https的基本流程寫清楚了一部分，這其中每一個步驟深入下去都是一門學科，而對於我們而言，能清楚其大致運作流程，做到心中有資料就算可以了， Https在目前的網路資料安全傳輸佔據著重要地位，目前可能也沒有更優的方案來代替Https。另外一定要注意 不要隨便安裝不確定的的根證書，以免帶來不必要的損失。 寫這篇文章時，已經進入我的春節假期，而我也已經踏上了 回家的火車，大家有疑問可以在評論中回覆，如有錯誤之處還望大家能指出，以免誤導他人 提前祝大家新年快樂！  

如果您覺得本文讓您有所收穫，不妨點下贊，為我的付出，給一點點回報！

如果您覺得本人也有點意思，不妨點個觀注，大家一起談技術，談人生！

 以下為參考資料