破解TLS加密資料的一種實現（移動端+PC端）

標籤：

  上次分享了破解手機端加密資料的思路，就是使用中間人代理進行破解，網路安全把這種做法叫做man-in-the-middle，今天講一下如何來實現。

  恰巧2016年3月2號，360推送了一則關於代號溺亡的漏洞的訊息，其本質講的就是我們這篇文章所討論的問題，但是我們乾的是正經事。

  既然涉及到中間人，我需要一個代理軟體充當中間人的角色，這裡我們選用軟體fiddler，該軟體是一個輕量級的抓包軟體，但其同時實現了中間代理的的功能。抓包軟體還是使用wireshark。至於為什麼不直接使用fiddler來直接抓包分析，是因為fiddler畢竟是輕量級的（或者哥就是愛用wireshark），很多功能不如wireshark支援的廣泛，比如長串連的功能，而且我們這裡也只是使用其作為代理以及製作認證的功能。當然fiddler也有很多自身的優點和不足，後續我們會一點點看到。

  本次實驗的軟體是全球最大的正版音樂服務平台spotify，使用該軟體進行測試的原因是在測試中我需要確認其中的加密流是否為音頻流。

  在前面的文章中已經對SSL等相關知識以及解密原理已經做了詳細的闡述，忘記的可以回顧一下。

  這篇文章要分兩個方面來講移動端和PC端，整體的思想都是一樣，實現會略有差別。

  先說說移動端，通常的抓包環境1所示：

              

                  圖1

  即手機連上路由裝置，在轉寄裝置上部署Libpcap抓取手機IP的報文。

  而現在我們需要在PC上部署代理程式軟體，即fiddler，因為資料會走Proxy 伺服器PC，因此在PC上安裝wireshark進行抓包，不再使用轉寄機器上的Libpcap抓包環境。

  現在要做以下幾件事情：

  1，設定fiddler，如

  安裝完fiddler之後做2，圖3所示的設定：路徑Tools->FiddlerOptions

                   圖2

                     圖3

                                圖4

  HTTPS選項勾選上CaptureHTTPS，選擇from remote clients only(實際過程中並不能過掉原生報文，汗)；Connection選項選擇allow remote compute to connect。HTTPS那個頁面有關認證可能跟你的不一樣，我在圖4所示的頁面下載了fiddler的一個外掛程式進行認證而產生和私密金鑰的匯出，因為fiddler內建的認證產生器，不支援匯出私密金鑰功能，下載後在windows上安裝即可。

  2，給手機設定代理，長摁住所串連的wifi->顯示進階->然後設定代理，5：

圖5

              

          圖6                           圖7

  Proxy 伺服器主機名稱就是你要連結的Proxy 伺服器IP地址；因為fiddler預設連接埠是8888，因此這裡面Proxy 伺服器的連接埠設定為8888.

  在手機瀏覽器輸入PC IP加上連接埠號碼，進入相關頁面下載認證，圖中藍色的Fiddler RootCertificate，安裝，認證用途為app。如果你的手機沒有設定密碼原則，在安裝認證的時候可能會提示你設定密碼，設定即可。6和圖7所示。

  3，設定wireshark和fiddler進行關聯，在Preferences->Protocols->ssl中建立，8

    

                          圖8

                                圖9

  其中的mypem.txt檔案是fiddler給出的私密金鑰，具體製作的步驟是，當你做好1,2步的設定後，使用手機去訪問該APP的時候，在fiddler的log頁面會自動產生私密金鑰（這就是第一步中安裝外掛程式的作用），將圖9中紅線部分標出的私密金鑰儲存在一個文字檔中即可，但是格式如下，用私密金鑰把中間哪一行替換掉：

-----BEGIN PRIVATE KEY-----

Base64 encoded private key here

-----END PRIVATE KEY-----

  至此，完成設定，重啟fiddler，開啟wireshark，為減少雜包的幹擾，我們只抓8888連接埠的報文，10所示：

                           圖10

  使用wireshark抓取解密報文11所示

                                  圖11

  我們可以看到綠色的http報文即為解密後的報文，在TLS握手之後。如果沒有解密，這個包是加密的，顏色是灰色的TLS報文。這是直觀上的感受。判斷捕獲的資料有沒有解密，可以看TLS握手中的client key exchange報文，圖12中紅線表示的部分為解密後的資料，圖13中紅線表示的部分為沒有解密的資料。

                                圖12

                                 圖13

  圖14解釋了為什麼抓取8888連接埠的原因。因為只有手機和fiddler之間的通訊(代理前)是經過解密的，因此要抓取這兩者之間通訊的報文，而fiddler使用8888連接埠和手機進行通訊，因此使用8888連接埠。而fiddler和Server之間通訊是沒有解密的，fiddler連接埠也是隨機的，因此沒有必要擷取這部分資料。其實同一份資料經過網卡兩遍，一遍加密了，一遍沒有加密，這也是抓取8888連接埠，過濾無用資料的原因。

                                 圖14

 

  這種方式破解加密資料並不是一直有效，原因之一，

  先瞭解SessionId的用處，即流關聯。可參考相關文章。如果你所抓的第一個SSL加密包有相應的SessionID的話，表明這條流重用了前一個流協商的參數，而fiddler不知道這些從參數，那麼相關資料就沒法解密，圖15是沒有重用的情況，Session ID 為0，如果重用，會有一長串的字元。當然不能解密的原因還有很多，希望大家多多共用。

 

圖15

  移動端的就是這麼多，PC端和移動端思路是一致的。但是實現方面略有差別，我這裡面簡單說一下。如果將PC軟體和fiddler部署在一台PC機上面，14所示，應用軟體和fiddler的通訊，是進程間的通訊，使用的是迴環地址127.0.0.1，是不經過網卡的，也就是說wireshark是無法擷取相應的解密資料包的。那麼解決思路如下：

  1，將wireshark的預設winpcap刪除，安裝Npcap進行抓包，原因就是windowsTCP/IP協議棧沒有實現網路迴環介面，詳情參考https://wiki.wireshark.org/CaptureSetup/Loopback，不做過多解釋。

  2，使用兩台PC機器，這裡面和手機端抓包就對應上了，其中一台PC最為fiddler代理，另外一台PC相當於手機，具體參考手機的1,2,3步設定，PC代理設定應該都會。

  整體的架構16：

                                                                       

                            圖16

  以上內容就是對移動端和PC端解密SSL流量的實際實現做了說明，其實是非常粗略和簡單的。為什麼這麼說，是因為在實際的抓包過程中，我發現使用fiddler代理之後只抓到加密的圖片報文，相應音頻wireshark沒有捕獲到，經過排查，確立的原因是這部分流量不走HTTP代理，也就是說HTTP代理不支援這部分流量的轉寄，因此8888連接埠也就捕獲不到。所以如果想要類似於這種流量的加密資料，那麼可以將fiddler替換成sock代理，當然，相應的代理機器需要安裝認證製作軟體了。如果誰有興趣，可以分享一下。

  其實上述的內容給了我們一個啟示，就是走代理並不安全，即使你的資料是加密的，常見的情境的我們很多人喜歡翻牆。你可能覺得，解密資料需要給你下認證，其實下認證可以神不知鬼不覺，當然也不盡然，下認證的策略基本可以利用到安全中的社會學攻擊，本質可以理解為人性的弱點吧，我發現自己搖身一變成為了哲學家。大家看看這篇文章http://my.oschina.net/CasparLi/blog/488298?fromerr=NqwEdtDw，看完之後別太憤青。大家開始的時候都是流氓，有的人有了錢變得紳士了，有的人還是老樣子，面對流氓有辦法嗎。

  以上內容如有錯誤之處還請指出。

 

破解TLS加密資料的一種實現（移動端+PC端）