基礎複習之-https請求

早上看了一篇文HTTPS就安全了嗎？會被抓包嗎？看完這篇你有對答如流，本文是基於此文的總結。

先默讀這張圖5分鐘：

瀏覽器證書驗證過程

關於這個問題知乎有個自稱專業認識的回答瀏覽器如何驗證HTTPS證書的合法性？，咱也不是專業認識，就作個簡單的總結：

1. 權威機構的證書纔會被瀏覽器承認，這是業界規範。權威機構頒發的證書結合瀏覽器接收到的服務端發送來的公鑰便可驗證服務端https證書的合法性。
2. 瀏覽器會被強制安裝權威機構的根證書。固然，更復雜的是還存在證書鏈，如根域名證書的子域名證書。
3. 瀏覽器會從本地CRL(證書吊銷列表)或者訪問OCSP(在線證書檢查)實時獲取證書的有效期或者吊銷狀態。
4. 瀏覽器針對不合法的證書做出提示。

隨機數生成

隨機數由客戶端生成，用來做爲對稱加密的祕鑰。

隨機數的傳輸，採用的是非對稱加密算法。

客戶端：服務端公鑰+隨機數+加密算法 = 加密後的隨機數

服務端：加密後的隨機數+服務端私鑰+ 解密算法 = 隨機數

傳輸過程，只有服務端公鑰是公開的，隨機數只有客戶端知道，服務端也只能經過私鑰得到隨機數。中間劫持者即便知道加解密算法，也沒法解密出隨機數。便可以保證以後的傳輸內容是沒法被解密出明文的。

加密傳輸

採用隨機數加密傳輸內容是爲了提升通訊效率。

非對稱加解密算法複雜，執行耗時長，不利於雙方通訊。因此，https的核心是如何生成一個只有通訊雙方知道的祕鑰。原來這一堆證書其實都是爲這個隨機數存在的。

那麼問題來了，https創建在http的基礎上，斷開後再次鏈接隨機數是否會從新生成呢？

屢次嘗試發現，針對https資源請求，每次從新創建tcp鏈接時，Initial connection和SSL老是同時存在的，以下圖：

因此，tcp握手鍊接和SSL過程是一連串的動做，每次tcp鏈接創建過程會從新生成隨機數。

下圖是完整的https握手過程：

fiddler如何對https鏈接抓包

https的做用是避免傳輸過程被未知的第三方劫持以及篡改數據。瀏覽器只認權威的證書，造假的證書是不會被瀏覽器信任的，因此理想狀況下能夠避免中間人篡改傳輸內容：

可是，若是中間人是客戶端使用者已知的且手動信任的第三方呢？fiddler就是這樣的存在。當你想對https請求代理的時候，它會生成一個證書，名爲DO_NOT_TRUST_FifflerRoot，讓你下載安裝它，並標記爲可信任。

瀏覽器告訴你：「這個傢伙給了我一個野雞證書，不靠譜，我勸你當心點」

你： 「哦哦，你說的是fiddler啊，它我很熟的，你放心好了」

而後瀏覽器就不吭聲了，內心mmp： 「你愛咋咋地，反正我已經提醒過你了」。

fiddler基於被客戶端使用者信任的能力，能夠攔截並自定義任何請求任何返回內容。如線上代碼調試，fiddler能夠在代碼返回以前在特定位置插入調試代碼，或者直接返回包含調試代碼的本地代碼。

fiddler做爲一個超級工具，你還知道它的其它妙用嗎？

參考資料

• https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/

本文使用 mdnice 排版