爲何如此安全的https協議卻仍然能夠被抓包呢？

上一篇原創寫了一篇關於抓包的文章，教你們如何在 Android 手機上對 https 協議的請求進行抓包。

小夥伴們你們好。

上一篇原創寫了一篇關於抓包的文章，教你們如何在 Android 手機上對 https 協議的請求進行抓包。

https 協議是一種很是安全的數據傳輸協議，它在網絡上傳輸的全部內容都是通過加密的。這可能也讓一些小夥伴很是不解，如此安全的 https 協議爲何也能被抓包？這樣不就說明這個協議也並不安全嗎？

其實並非如此。https 協議確實是很是安全的，但同時，用 https 協議傳輸的數據也確實是能夠被抓包的，它們二者之間並不衝突。

那麼今天，咱們就來探究一下，爲何說它們二者之間並不衝突，以及市場上那些主流的抓包工具，究竟是如何實現對 https 協議進行抓包的。

注意，本篇文章主要探討的是對 https 協議抓包的實現原理，若是你想學習的是抓包工具的使用方法，能夠參考上一篇文章 在 Android 手機上對 https 請求進行抓包 。

一

好了，閱讀到了這裏，說明你對 https 已經很是熟悉了，那麼你必定知道，https 協議是結合了非對稱加密和對稱加密一塊兒工做，從而保證數據傳輸的安全性的。

非對稱加密用於確保客戶端能夠安全地獲取到服務器的真實公鑰。對稱加密用於確保客戶端和服務器之間的數據傳輸不會被任何人監聽和解密，由於對稱加密使用的密鑰只有客戶端和服務器這二者知道，其餘任何人在不知道密鑰的狀況下都沒法對傳輸數據進行解密。

那麼看似固若金湯的 https 協議，抓包工具是如何在這其中找到一個 「破綻」，從而實現對 https 請求進行抓包的呢？

其實嚴格來講，這也算不上是一個破綻，而是用戶的一個主動行爲。還記得咱們在上篇文章中講到的，若是想要對 https 請求進行抓包，必須在手機上安裝一個由 Fiddler 提供的證書嗎？這個證書就是整個工做原理的核心，若是沒有它，那麼 https 就是不可能被抓包的。而安裝證書須要由用戶主動去操做，說明用戶知道本身在幹什麼，天然也應該承擔相應的風險。這也是爲何我一直在說，https 是很是安全的，但 https 也是能夠被抓包的，它們二者之間並不衝突。

接下來，咱們就具體研究一下，爲何只須要額外安裝一個證書，抓包工具就能夠實現對 https 請求進行抓包。

咱們將實現原理分紅兩個部分來解析，第一部分是客戶端如何安全地獲取服務器的真實公鑰，第二部分是客戶端如何與服務器商定用於對稱加密的密鑰。

藉助那些可信賴的 CA 機構，客戶端是能夠安全地獲取到服務器的真實公鑰的。

CA 機構專門用於給各個服務器簽發數字證書，從而保證客戶端能夠安全地得到服務器的公鑰。

服務器的管理員能夠向 CA 機構進行申請，將本身的公鑰提交給 CA 機構。CA 機構則會幫忙製做證書，並使用本身的私鑰對其加密，而後將加密後的信息返回給服務器。

這樣，當客戶端想要去獲取某個服務器的公鑰時，服務器會將 CA 機構簽發的那段加密信息返回。那麼客戶端要如何解密這段信息呢？放心，主流 CA 機構的公鑰都是被內置到操做系統當中的，因此只要是服務器的數字證書是由正規 CA 機構簽發的，那麼就必定能夠被解密成功，從而客戶端也就能安全地獲取到服務器的公鑰了。示意圖以下：

而抓包工具在這個過程當中能夠作什麼事情呢？咱們仍是以 Fiddler 舉例。Fiddler 的工做是介於客戶端和服務器中間的，它會先於客戶端接收到服務器返回的加密數據，而後它也可使用操做系統內置的 CA 公鑰對這段數據解密，從而獲得服務器的公鑰，並先將這個公鑰保存起來。

接下來，Fiddler 會將解密出來的數據進行調包，將其中服務器返回的公鑰替換成本身的一個公鑰，而後使用本身的非對稱加密私鑰對數據從新加密，並將這段從新加密後的數據返回給客戶端。示意圖以下：

可是咱們知道，用 Fiddler 本身的私鑰加密後的數據，客戶端確定解密不出來呀，由於 Fiddler 的公鑰並無內置到操做系統當中，這個時候就會出現咱們在上篇文章看到的錯誤。

二

那麼接下來要怎麼辦你應該很清楚了吧？這也是爲何咱們必定要在手機上安裝一個 Fiddler 提供的證書才行，只是爲了讓客戶端可以解密出 Fiddler 調包以後的數據。以下圖所示：

這樣客戶端仍然得到了一個公鑰，而且還覺得這個公鑰是服務器返回的，實際上這是一個被 Fiddler 調包以後的公鑰。而服務器返回的真實公鑰則被 Fiddler 保存了起來。

到這裏爲止，獲取服務器公鑰的流程就結束了，目前各部分的狀態以下：

接下來是客戶端與服務器商定對稱加密密鑰的過程。

因爲使用什麼對稱加密密鑰是由客戶端這邊來決定的，客戶端能夠利用隨機算法在本地生成一個對稱加密密鑰，並用服務器返回的公鑰進行加密，而後發送給服務器。因爲公鑰加密的數據只能用私鑰解密，所以沒有任何人能破解出客戶端生成的對稱加密密鑰究竟是什麼。

而後服務器這邊使用本身的私鑰將客戶端發來的數據進行解密，這樣客戶端和服務器就都知道對稱加密的密鑰是什麼了，而且絕對沒有第三我的能知道，這樣雙方以後都使用對稱加密來進行通信便可，從而保證了數據傳輸的安全。示意圖以下：

然而如今有了 Fiddler，一切就都不同了。

客戶端這邊拿到的其實根本就不是服務器的公鑰，而是由 Fiddler 調包後的公鑰。因此，客戶端這邊生成一個對稱加密密鑰後，使用的也是 Fiddler 調包後的公鑰來進行加密的，這樣這段加密後的數據只有用 Fiddler 本身的私鑰才能解開。

那麼很顯然，Fiddler 固然是有本身的私鑰的，所以它可以解密出這段數據，這樣 Fiddler 就知道客戶端生成的對稱加密密鑰是什麼了。

接下來不要忘記，Fiddler 還在以前就保存了服務器返回的真實公鑰，那麼如今 Fiddler 能夠用真實的服務器公鑰再次加密這段數據，而後將加密後的數據發送給服務器。

對於服務器而言，它並不知道客戶端這邊發生了什麼事，也不知道 Fiddler 的存在。它只知道，用本身的私鑰是能夠解密出客戶端發來的數據，並能從中得到對稱加密的密鑰。示意圖以下：

到這裏，對稱加密密鑰的商定過程也就結束了，目前各部分的狀態以下：

你會發現，如今客戶端、服務器、Fiddler，這三者都知道對稱加密的密鑰是什麼。

以後客戶端與服務器之間的全部通信都會使用這個密鑰加密後再進行傳輸，不知道密鑰的人天然是沒法解密出傳輸的內容的，可是 Fiddler 卻知道密鑰是什麼，所以它能夠完美監聽客戶端與服務器之間的通信內容，也就實現了對 https 協議抓包的功能。

三

以上就是 https 協議抓包的實現原理，雖然從最後的結果看上去，Fiddler 在其中各類調包替換數據，幹了不少不安全的操做。但 Fiddler 之因此有權限這麼幹，仍是由於咱們在一開始的時候手動安裝了 Fiddler 的證書，不然後面的流程都是走不通的。

所以，https 仍然是一個很是可靠且安全的數據傳輸協議。另外也提醒你們，除非你確實有很是明確的需求，不然千萬不要在本身的手機或電腦上安裝來路不明的證書，否則你的數據安全性可能就會面臨很是大的威脅。

好了，今天的文章就到這裏，但願對你們都能有所幫助。若是你以爲這篇文章讀起來有點吃力，多是由於你對 https 協議、對稱加密、非對稱加密還不是那麼瞭解。我仍然建議必定要先去閱讀 寫一篇最好懂的 https 講解 這篇文章，而後再來閱讀本文收穫會更大。

另外，若是想要學習 Kotlin 和最新的 Android 知識，能夠參考個人新書 《第一行代碼 第 3 版》。

關注個人技術公衆號「郭霖」，每一個工做日都有優質技術文章推送。