Charles的HTTPS抓包方法及原理分析


原文地址:http://www.jianshu.com/p/870451cb4eb0

背景

作為移動平台的RD,項目開發過程中一項比較重要的甩鍋技能——抓包應該大家都比較熟悉了,畢竟有些bug可能是由服務端下發的數據出錯導致的。雖然抓包工具很好用,但是如果不做一些設置的話,對於HTTPS協議的請求就無能為力了,比如這樣


 

這對於一些注重安全性的應用來說,或許就不是特別好使,我們的項目目前也在逐漸從HTTP轉向HTTPS,因此掌握這些技巧還是比較有用的。抓包工具多種多樣,比較好使的還是Charles和Fiddler,下面就簡單的介紹下HTTPS的相關原理並以Charles為例來介紹下如何抓取HTTPS協議的包。

原理分析

其實使用工具抓HTTPS的包本身並不難,兩三步簡單的操作就可以實現,關鍵如果不理解原理的話,總覺得不舒服斯基,所以把原理分析放在前面。

HTTPS(Hyper Text Transfer Protocol Secure),是一種基於SSL/TLS的HTTP,所有的HTTP數據都是在SSL/TLS協議封裝之上進行傳輸的。HTTPS協議是在HTTP協議的基礎上,添加了SSL/TLS握手以及數據加密傳輸,也屬於應用層協議。所以,研究HTTPS協議原理,最終就是研究SSL/TLS協議。

運行過程

我們都知道HTTPS在保證數據安全傳輸上使用了加密算法,但是具體是如何加密的,或許許多人和我一樣也是雲里霧里。
實際上SSL/TLS協議的基本思路是非對稱加密和對稱加密結合來傳輸數據,一言以弊之,HTTPS是通過一次非對稱加密算法(如RSA算法)進行了協商密鑰的生成與交換,然后在后續通信過程中就使用協商密鑰進行對稱加密通信,之所以要使用這兩種加密方式的原因在於非對稱加密計算量較大,如果一直使用非對稱加密來傳輸數據的話,會影響效率。
運行過程盜用巨人的圖,可以表示如下


 

有了圖就可以一步一步分析了

1.HTTPS請求

這個步驟是整個通信過程中的第一步,首先,客戶端(通常是瀏覽器)先向服務器發出加密通信的請求,在這一步中,客戶端主要向服務器提供以下信息:

  • 支持的協議版本,比如TLS 1.0版
  • 一個客戶端生成的隨機數RandomC,稍后用於生成“協商密鑰”
  • 支持的加密方法,比如RSA公鑰加密。
  • 支持的壓縮方法。

2.服務器響應

服務器收到客戶端請求后,向客戶端發出回應,服務器的回應一般包含以下內容:

  • 確認使用的加密通信協議版本,比如TLS 1.0版本。如果瀏覽器與服務器支持的版本不一致,服務器關閉加密通信。
  • 一個服務器生成的隨機數RandomS,稍后用於生成“協商密鑰”*
  • 從客戶端支持的加密方法中選擇一個作為確認要使用的加密方法,比如RSA公鑰加密。
  • 服務器證書。
    這個服務器證書就是表明服務器身份的東西,其中也包含了非對稱加密中需要使用的公鑰。

3.證書校驗、生成密碼、公鑰加密

客戶端收到服務器回應以后,首先驗證服務器返回的證書。如果證書不是可信機構頒發,或者證書中的域名與實際域名不一致,或者證書已經過期,以瀏覽器為例客戶端會向網頁訪問者顯示一個警告,由其選擇是否還要繼續通信。 如果證書沒有問題,客戶端就會從證書中取出服務器的公鑰。然后生成密碼、公鑰加密。
生成密碼的過程會先產生一個隨機數Pre-master key,該隨機數是整個握手階段出現的第三個隨機數,稍后會經過公鑰加密發送到服務端,有了它以后,客戶端和服務器就同時有了三個隨機數——RandomC,RandomS,Pre-master key,接着雙方就用事先商定的加密方法,各自生成本次會話所用的同一把“協商密鑰”。

4.加密信息C-S

加密信息是指上面一步生成的內容,主要包括

  • 一個隨機數Pre-master key。用於給服務端生成“協商密鑰”。
  • 編碼改變通知,表示隨后的信息都將用雙方商定的加密方法和密鑰發送。
  • 客戶端握手結束通知,表示客戶端的握手階段已經結束。這一項通常也是前面發送的所有內容的hash值,用來供服務器校驗。

5.私鑰解密、解密握手消息、驗證Hash

服務器收到客戶端公鑰加密的第三個隨機數Pre-master key之后,通過自身私鑰解密該數值並由之前的RandomC和RandomS計算生成本次會話所用的“會話密鑰”。然后,通過約定的Hash算法驗證客戶端發送的數據完整性。

6.加密信息S-C

主要是指

  • 編碼改變通知,表示隨后的信息都將用雙方商定的加密方法和密鑰發送。
  • 服務器握手結束通知,表示服務器的握手階段已經結束。這一項同時也是前面發生的所有內容的hash值,用來供客戶端校驗。

7.解密握手消息、驗證Hash

客戶端解密並計算握手消息的HASH,如果與服務端發來的HASH一致,此時握手過程結束。

8.正常加密通信

握手成功之后,所有的通信數據將由之前協商密鑰及約定好的算法進行加密解密。

Charles抓HTTPS包原理

Charles本身是一個協議代理工具,如果只是普通的HTTP請求,因為數據本身沒經過再次加密,因此作為代理可以知道所有客戶端發送到服務端的請求內容以及服務端返回給客戶端的數據內容,這也就是抓包工具能夠將數據傳輸內容直接展現出來的原因。對於HTTPS請求,4,6,8步驟的數據都已經經過了加密,代理如果什么都不做的話是無法獲取到其中的內容的。為了實現這個過程的數據獲取,Charles需要做的事情是對客戶端偽裝服務端,對服務端偽裝客戶端,具體

  • 截獲真實客戶端的HTTPS請求,偽裝客戶端向真實服務端發送HTTPS請求
  • 接受真實服務器響應,用Charles自己的證書偽裝服務端向真實客戶端發送數據內容

一般情況下HTTPS中是客戶端對服務端做證書校驗,當然也有一些金融機構會有用戶證書作為提供給服務端做用戶認證的工具,保證發出請求的的確是這部分授權用戶。我們僅分析客戶端對服務單做證書校驗的這種。Android有自己的一套HTTPS通信調用方式,以HttpsURLConnection為例


 

上面這段代碼就是一個https請求的樣例,這種方法的特點是證書校驗工作交由系統處理,系統只會允許可信CA簽發的數字證書能夠訪問,私有CA簽發的數字證書(比如12306以及我們上文說的Charles證書)是無法訪問的。
那么如何繞過呢,

  • 第一種方法是修改Https通信代碼,這種只對開發者開發應用的時候好使,我們需要實現X509TrustManager接口去做自己的一套證書校驗,它並不通用,尤其是對於我們抓包而言是不可行的,因為我們沒法去修改別人應用中的代碼。
  • 第二種方法是將私有CA簽發的數字證書安裝到手機中並且作為受信任證書保存,這種方式是我們推薦的方式,唯一的缺點是你的手機上可能會在通知欄一直留着一個特殊標志,告訴你網絡可能被監控。恩,不監控我們怎么抓包呢,哈哈。

Charles抓包步驟

原理都說完了,下面就是貼圖時間,我們要做的最重要的其實只有一件事情,就是

將私有CA簽發的數字證書安裝到手機中並且作為受信任證書保存

一步一步來

  • 首先打開Charles菜單,選擇安裝Charles證書到移動設備

 
  • Charles提示你如何安裝,這里如何用手機連接Charles就不做敘述了,普通的HTTP抓包都需要執行

 

 


作者:silentleaf
鏈接:http://www.jianshu.com/p/870451cb4eb0
來源:簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權,非商業轉載請注明出處。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM