[[404017]]

本文轉載自微信公眾號「郭霖」，作者郭霖。轉載本文請聯系郭霖公眾號。

小伙伴們早上好。

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

https協議是一種非常安全的數據傳輸協議，它在網絡上傳輸的所有內容都是經過加密的。這可能也讓一些小伙伴非常不解，如此安全的https協議為什么也能被抓包?這樣不就說明這個協議也并不安全嗎?

其實并不是如此。https協議確實是非常安全的，但同時，用https協議傳輸的數據也確實是可以被抓包的，它們兩者之間并不沖突。

那么今天，我們就來探究一下，為什么說它們兩者之間并不沖突，以及市場上那些主流的抓包工具，到底是如何實現對https協議進行抓包的。

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

另外，想要理解對https協議抓包的實現原理，你還必須非常熟悉https的工作機制才行，我在 寫一篇最好懂的https講解 這篇文章中對https的工作機制進行了詳細的介紹，還不熟悉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講解 這篇文章，然后再來閱讀本文收獲會更大。