一 前言
在說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的請求數據
四 總結
如果您覺得本文讓您有所收穫，不妨點下贊，爲我的付出，給一點點回報！
如果您覺得本人也有點意思，不妨點個觀注，大家一起談技術，談人生！
以下爲參考資料