[[404017]]

本文轉(zhuǎn)載自微信公眾號「郭霖」，作者郭霖。轉(zhuǎn)載本文請聯(lián)系郭霖公眾號。

小伙伴們早上好。

上一篇原創(chuàng)寫了一篇關(guān)于抓包的文章，教大家如何在Android手機上對https協(xié)議的請求進行抓包。

https協(xié)議是一種非常安全的數(shù)據(jù)傳輸協(xié)議，它在網(wǎng)絡(luò)上傳輸?shù)乃袃?nèi)容都是經(jīng)過加密的。這可能也讓一些小伙伴非常不解，如此安全的https協(xié)議為什么也能被抓包?這樣不就說明這個協(xié)議也并不安全嗎?

其實并不是如此。https協(xié)議確實是非常安全的，但同時，用https協(xié)議傳輸?shù)臄?shù)據(jù)也確實是可以被抓包的，它們兩者之間并不沖突。

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

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

另外，想要理解對https協(xié)議抓包的實現(xiàn)原理，你還必須非常熟悉https的工作機制才行，我在 寫一篇最好懂的https講解 這篇文章中對https的工作機制進行了詳細的介紹，還不熟悉https的朋友可以先去閱讀這篇文章。

好了，閱讀到了這里，說明你對https已經(jīng)非常熟悉了，那么你一定知道，https協(xié)議是結(jié)合了非對稱加密和對稱加密一起工作，從而保證數(shù)據(jù)傳輸?shù)陌踩缘摹?/p>

非對稱加密用于確保客戶端可以安全地獲取到服務器的真實公鑰。對稱加密用于確保客戶端和服務器之間的數(shù)據(jù)傳輸不會被任何人監(jiān)聽和解密，因為對稱加密使用的密鑰只有客戶端和服務器這兩者知道，其他任何人在不知道密鑰的情況下都無法對傳輸數(shù)據(jù)進行解密。

那么看似固若金湯的https協(xié)議，抓包工具是如何在這其中找到一個“破綻”，從而實現(xiàn)對https請求進行抓包的呢?

其實嚴格來說，這也算不上是一個破綻，而是用戶的一個主動行為。還記得我們在上篇文章中講到的，如果想要對https請求進行抓包，必須在手機上安裝一個由Fiddler提供的證書嗎?這個證書就是整個工作原理的核心，如果沒有它，那么https就是不可能被抓包的。而安裝證書需要由用戶主動去操作，說明用戶知道自己在干什么，自然也應該承擔相應的風險。這也是為什么我一直在說，https是非常安全的，但https也是可以被抓包的，它們兩者之間并不沖突。

接下來，我們就具體研究一下，為什么只需要額外安裝一個證書，抓包工具就可以實現(xiàn)對https請求進行抓包。

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

借助那些可信賴的CA機構(gòu)，客戶端是可以安全地獲取到服務器的真實公鑰的。

CA機構(gòu)專門用于給各個服務器簽發(fā)數(shù)字證書，從而保證客戶端可以安全地獲得服務器的公鑰。

服務器的管理員可以向CA機構(gòu)進行申請，將自己的公鑰提交給CA機構(gòu)。CA機構(gòu)則會幫忙制作證書，并使用自己的私鑰對其加密，然后將加密后的信息返回給服務器。

這樣，當客戶端想要去獲取某個服務器的公鑰時，服務器會將CA機構(gòu)簽發(fā)的那段加密信息返回。那么客戶端要如何解密這段信息呢?放心，主流CA機構(gòu)的公鑰都是被內(nèi)置到操作系統(tǒng)當中的，所以只要是服務器的數(shù)字證書是由正規(guī)CA機構(gòu)簽發(fā)的，那么就一定可以被解密成功，從而客戶端也就能安全地獲取到服務器的公鑰了。示意圖如下：

而抓包工具在這個過程中可以做什么事情呢?我們還是以Fiddler舉例。Fiddler的工作是介于客戶端和服務器中間的，它會先于客戶端接收到服務器返回的加密數(shù)據(jù)，然后它也可以使用操作系統(tǒng)內(nèi)置的CA公鑰對這段數(shù)據(jù)解密，從而得到服務器的公鑰，并先將這個公鑰保存起來。

接下來，F(xiàn)iddler會將解密出來的數(shù)據(jù)進行調(diào)包，將其中服務器返回的公鑰替換成自己的一個公鑰，然后使用自己的非對稱加密私鑰對數(shù)據(jù)重新加密，并將這段重新加密后的數(shù)據(jù)返回給客戶端。示意圖如下：

但是我們知道，用Fiddler自己的私鑰加密后的數(shù)據(jù)，客戶端肯定解密不出來呀，因為Fiddler的公鑰并沒有內(nèi)置到操作系統(tǒng)當中，這個時候就會出現(xiàn)我們在上篇文章看到的錯誤。

那么接下來要怎么辦你應該很清楚了吧?這也是為什么我們一定要在手機上安裝一個Fiddler提供的證書才行，只是為了讓客戶端能夠解密出Fiddler調(diào)包之后的數(shù)據(jù)。如下圖所示：

這樣客戶端仍然獲得了一個公鑰，并且還以為這個公鑰是服務器返回的，實際上這是一個被Fiddler調(diào)包之后的公鑰。而服務器返回的真實公鑰則被Fiddler保存了起來。

到這里為止，獲取服務器公鑰的流程就結(jié)束了，目前各部分的狀態(tài)如下：

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

由于使用什么對稱加密密鑰是由客戶端這邊來決定的，客戶端可以利用隨機算法在本地生成一個對稱加密密鑰，并用服務器返回的公鑰進行加密，然后發(fā)送給服務器。由于公鑰加密的數(shù)據(jù)只能用私鑰解密，因此沒有任何人能破解出客戶端生成的對稱加密密鑰到底是什么。

然后服務器這邊使用自己的私鑰將客戶端發(fā)來的數(shù)據(jù)進行解密，這樣客戶端和服務器就都知道對稱加密的密鑰是什么了，并且絕對沒有第三個人能知道，這樣雙方之后都使用對稱加密來進行通訊即可，從而保證了數(shù)據(jù)傳輸?shù)陌踩Ｊ疽鈭D如下：

然而現(xiàn)在有了Fiddler，一切就都不一樣了。

客戶端這邊拿到的其實根本就不是服務器的公鑰，而是由Fiddler調(diào)包后的公鑰。所以，客戶端這邊生成一個對稱加密密鑰后，使用的也是Fiddler調(diào)包后的公鑰來進行加密的，這樣這段加密后的數(shù)據(jù)只有用Fiddler自己的私鑰才能解開。

那么很顯然，F(xiàn)iddler當然是有自己的私鑰的，因此它能夠解密出這段數(shù)據(jù)，這樣Fiddler就知道客戶端生成的對稱加密密鑰是什么了。

接下來不要忘記，F(xiàn)iddler還在之前就保存了服務器返回的真實公鑰，那么現(xiàn)在Fiddler可以用真實的服務器公鑰再次加密這段數(shù)據(jù)，然后將加密后的數(shù)據(jù)發(fā)送給服務器。

對于服務器而言，它并不知道客戶端這邊發(fā)生了什么事，也不知道Fiddler的存在。它只知道，用自己的私鑰是可以解密出客戶端發(fā)來的數(shù)據(jù)，并能從中獲得對稱加密的密鑰。示意圖如下：

到這里，對稱加密密鑰的商定過程也就結(jié)束了，目前各部分的狀態(tài)如下：

你會發(fā)現(xiàn)，現(xiàn)在客戶端、服務器、Fiddler，這三者都知道對稱加密的密鑰是什么。

之后客戶端與服務器之間的所有通訊都會使用這個密鑰加密后再進行傳輸，不知道密鑰的人自然是無法解密出傳輸?shù)膬?nèi)容的，但是Fiddler卻知道密鑰是什么，因此它可以完美監(jiān)聽客戶端與服務器之間的通訊內(nèi)容，也就實現(xiàn)了對https協(xié)議抓包的功能。

以上就是https協(xié)議抓包的實現(xiàn)原理，雖然從最后的結(jié)果看上去，F(xiàn)iddler在其中各種調(diào)包替換數(shù)據(jù)，干了很多不安全的操作。但Fiddler之所以有權(quán)限這么干，還是因為我們在一開始的時候手動安裝了Fiddler的證書，否則后面的流程都是走不通的。

因此，https仍然是一個非常可靠且安全的數(shù)據(jù)傳輸協(xié)議。另外也提醒大家，除非你確實有非常明確的需求，否則千萬不要在自己的手機或電腦上安裝來路不明的證書，不然你的數(shù)據(jù)安全性可能就會面臨非常大的威脅。

好了，今天的文章就到這里，希望對大家都能有所幫助。如果你覺得這篇文章讀起來有點吃力，可能是因為你對https協(xié)議、對稱加密、非對稱加密還不是那么了解。我仍然建議一定要先去閱讀 寫一篇最好懂的https講解 這篇文章，然后再來閱讀本文收獲會更大。