Https 及抓包

Https 相關概念

什麼是SSL/TLS協定？

加密相關的概念

對稱加密

非對稱加密

散列函數Hash（摘要算法）

數字簽名

TLS握手過程

Client Hello

Server Hello

Certificate(Server)

Server Key Exchange

Certificate Request

Server Hello Done

Certificate(Client)

Client Key Exchange

Certification Verity

Change Cipher Spec(Client)

Encrypted Handshake Message(Client)

Change Cipher Spec(Server)

Encrypted Handshake Message(Server)

Application Data

證書

RSA身份驗證的隐患

身份驗證CA和證書

使用Charles 進行Https 抓包

安裝Charles

工具導航欄

通過 Charles 進行移動端抓包

Https 抓包

Charles 功能

Breakpoints 功能

Map Local 功能

Rewrite 功能

Block List

Https 相關概念

HTTPS：超文本傳輸安全協定（英語：Hypertext Transfer Protocol Secure，縮寫：HTTPS，常稱為HTTP over TLS，HTTP over SSL或HTTP Secure）是一種通過計算機網絡進行安全通信的傳輸協定。

Https 超文本傳輸安全協定，是一種通過計算機網絡進行安全通信的傳輸協定。主要目的，是提供對網站伺服器的身份認證，保護交換資料的隐私與完整性。由網景公司（Netscape）在1994年首次提出，随後擴充到網際網路上。

TLS/SSL 是介于TCP和HTTP之間的一層安全協定，不影響原有的TCP協定和HTTP協定，是以使用HTTPS基本上不需要對HTTP頁面進行太多的改造。

可以看到HTTPS比HTTP多了一層TLS/SSL協定，TLS/SSL 就是進行加密操作的。

什麼是SSL/TLS協定？

SSL (Secure Sockets Layer) “安全套接層”協定，TLS (Transport Layer Security) “安全傳輸層”協定，都屬于是加密協定，在其網絡資料傳輸中起到保護隐私和資料的完整性。

SSL和TLS的關系就像win7P和win10的關系，更新後改了個名字而已。下面這張表格列出了它們的曆史：

協定	建立時間	建立者	RFC	注釋
SSL1.0	n/a	Netscape	n/a	由于有很多安全問題，是以網景公司沒有将它公之于衆
SSL2.0	1995	Netscape	n/a	這是第一個被公衆所了解的SSL版本
SSL3.0	1996	Netscape	rfc6101	由于2.0還是被發現有很多安全問題，Netscape于是設計了3.0，并且IETF将它整理成RFC釋出了出來
TLS1.0	1999	IETF	rfc2246	基于SSL 3.0，修改不大，在某些場合也被稱之為SSL 3.1，改名主要是為了和Netscape撇清關系，表示一個新時代的來臨。類似于飯店換老闆了，然後改了個名字，廚師還是原來的
TLS1.1	2006	IETF	rfc4346
TLS1.2	2008	IETF	rfc5246
TLS1.3	TBD	IETF	TBD	還在開發過程中，draft

加密相關的概念

對稱加密

加密和解密都用同一個密鑰，是以叫對稱加密。常見的算法有AES、3DES。

相比而言，加密速度較快，一般加密較長的傳輸内容；
優點：就是快
缺點：伺服器和 N 個用戶端通信，需要維持 N 個密鑰記錄（因為用戶端之間的密鑰不同才安全）
           

非對稱加密

密鑰成對出現，一般稱為公鑰(公開)和私鑰(保密)，公鑰加密的資訊隻能私鑰解開，反之亦然。常見的算法有RSA、DSA、ECC。

速度上較差，一般加密較短的内容（例如：對稱加密的密鑰，内容的摘要）；
優點：安全（用公鑰與私鑰），可以1對多的加密（N 個用戶端共用一個公鑰，私鑰掌握在服務端，所有是安全的）
缺點：速度上較差（相比對稱加密效率低些）
           

散列函數Hash（摘要算法）

該類函數特點是函數單向不可逆、對輸入非常敏感、輸出長度固定，針對資料的任何修改都會改變散列函數的結果，常見的有 MD5、SHA1、SHA256。

用于數字簽名；
用于防止資訊篡改并驗證資料的完整性;
           

數字簽名

數字簽名就是“非對稱加密+摘要算法”，其目的不是為了加密，而是用來防止他人篡改資料。

比如A要給B發送資料，A先用摘hash算法得到資料的摘要（指紋），然後用A的私鑰加密摘要，得到A的簽名，
B收到A的資料與A的簽名，用同樣的算法計算收到資料的摘要（指紋），然後用A公開的公鑰解密簽名得到一個摘要，
比較兩個摘要，相同則資料沒有被篡改，否則說明有問題。
           

TLS握手過程

Https 的安全機制是建立在SSL/TLS 之上的，SSL/TLS 握手是為了在不安全的通信過程裡，安全地協商出一份對稱加密的秘鑰。

加密過程

可以簡單了解為

用戶端A  |   ------- Hello ------------------------->  |    伺服器B
         |                                            |
         | <--- Hello -----                           |
         |          證書，公鑰b，随機數b ----------     |    (私鑰就在B 這邊)
         |                                            |
         | --- 生成對稱密鑰的關鍵參數pre_master_secret  |
         |   （經過公鑰b 加密了），随機數a -------->    |
         |                                            |
         | ----------使用對稱密鑰加密的資料-------->    |
         |                                            |
         | <---------使用對稱密鑰加密的資料---------    |

注意：
pre_master_secret  可以了解為對稱密鑰，因為它是關鍵參數拿到它就可以計算出對稱密鑰了，
它也是用公鑰b 加密後才傳輸的；所有可以看出非對稱加密用于加密對稱密鑰；
而資料的加密用的是對稱密鑰，但必須要安全的送到對面才行，是以用公鑰加密；

RFC裡面給出對稱密鑰的的計算方法：
master_secret = PRF(pre_master_secret, "master secret",
                          ClientHello.random + ServerHello.random)
                          [0..47];

通過 pre_master_secret , 随機數a , 随機數b 就可以算出
           

完成上圖的加密過程就可以進行資料的加密傳輸了（Application Data）。

通過Wireshark 抓包，讓我們從理論到實踐，可以更好地了解Https 。

Client Hello

握手第一步是用戶端發送Client Hello 協定請求，裡面比較重要的是Cipher Suites ，這是用戶端所支援一系列的加密套件，服務端收到後悔從中選一個作為加密算法。

然後，還有SSL/TSL Version  ，以及一個用戶端生成的随機數 Random 。

Server Hello

告知用戶端後續協定要使用的TLS版本（在這一步确定了下來，這個版本主要與用戶端與服務端支援的最高版本有關）；

會從 Client Hello 傳過來的 Support Ciphers 裡确定一份加密套件，

如下圖确定的為TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xc030) 

Certificate(Server)

這一步是服務端将自己的證書發給用戶端，讓用戶端驗證自己的身份。

Server Key Exchange

如果是DH算法，這裡發送伺服器使用的DH參數。RSA算法不需要這一步。

Certificate Request

是服務端要求用戶端上報證書（這是一個可選項，對于安全性要求高的場景會用到，比如我這次抓包就沒有）。

Server Hello Done

作為結束資訊，告知用戶端Server Hello 過程結束。

Certificate(Client)

可選項，對應服務端的Certificate Request 請求，也就是服務端發送了Certificate Request，用戶端才會發送自己的證書資訊。

Client Key Exchange

發送公鑰加密的對稱密鑰關鍵參數，但如果是DH 算法則發送用戶端的公鑰。關于DH 算法就是雙方都産生一對非對稱密鑰，然後将公鑰發送給對方，這裡就是用戶端将自己的公鑰發送給服務端，服務端将自己的公鑰發送給用戶端，都保留自己的私鑰，DH 算法就是根據自己私鑰和對方私鑰算出一個密鑰，而且雙方算出的相同，這樣就可以使用對稱加密算法加密資料了。

Certification Verity

對服務端發的證書進資訊進行确認操作。

Change Cipher Spec(Client)

這一步是用戶端通知服務端後面再發送的消息都會使用前面協商出來的秘鑰加密了，是一條事件消息。

Encrypted Handshake Message(Client)

這一步對應的是 Client Finish 消息，用戶端将前面的握手消息生成摘要再用協商好的秘鑰加密，這是用戶端發出的第一條加密消息。服務端接收後會用秘鑰解密，能解出來說明前面協商出來的秘鑰是一緻的。

Change Cipher Spec(Server)

這一步是服務端通知用戶端後面再發送的消息都會使用協商出來的加密，也是一條事件消息。

Encrypted Handshake Message(Server)

這一步對應的是 Server Finish 消息，服務端也會将握手過程的消息生成摘要再用秘鑰加密，這是服務端發出的第一條加密消息。用戶端接收後會用秘鑰解密，能解出來說明協商的秘鑰是一緻的。

Application Data

加密的資料，到這裡，雙方已安全地協商出了同一份秘鑰，應用層資料都會用這個秘鑰加密後再進行傳輸。

證書

通過服務端的公鑰加密對稱密鑰安全的把對稱密鑰發送給對方，因為私鑰這有服務端有，而之後就可以用對稱密鑰加密資料進行安全的傳輸了。

RSA身份驗證的隐患

看似安全，但是如果用戶端拿到的公鑰不是服務端的，而是中間人的，中間人将自己的公鑰發送給用戶端，用戶端用該公鑰加密的對稱密鑰，就會被中間人拿到，是以必須要确認對方的身份，

而且也可能出現伺服器不承認是自己發出的資料，即資訊抵賴，

是以就引入了證書機制。

用戶端C和伺服器S進行通信，中間節點M截獲了二者的通信;
節點M自己計算産生一對公鑰pub_M和私鑰pri_M;
C向S請求公鑰時，M把自己的公鑰pub_M發給了C;
C使用公鑰 pub_M加密的資料能夠被M解密，因為M掌握對應的私鑰pri_M，
而 C無法根據公鑰資訊判斷伺服器的身份，進而 C和 * M之間建立了"可信"加密連接配接;
中間節點 M和伺服器S之間再建立合法的連接配接，是以 C和 S之間通信被M完全掌握，
M可以進行資訊的竊聽、篡改等操作。

另外，伺服器也可以對自己的發出的資訊進行否認，不承認相關資訊是自己發出。
           

是以該方案下至少存在兩類問題：中間人攻擊和資訊抵賴。

身份驗證CA和證書

解決上述身份驗證問題的關鍵是確定擷取的公鑰途徑是合法的，能夠驗證伺服器的身份資訊，為此需要引入權威的第三方機構CA(如沃通CA)。CA 負責核實公鑰的擁有者的資訊，并頒發認證"證書"，同時能夠為使用者提供證書驗證服務。

在TLS握手的過程中，浏覽器得到了網站的證書；
打開證書，檢視是哪個CA簽名的這個證書；
在自己信任的CA庫中，找相應CA的證書；
用CA憑證裡面的公鑰解密網站證書上的簽名，取出網站證書的摘要（指紋），然後用同樣的算法（比如sha256）
算出出網站證書的校驗碼，如果校驗碼和簽名中的校驗碼對的上，說明這個證書是合法的，且沒被人篡改過；
讀出裡面的CN，對于網站的證書，裡面一般包含的是域名；
檢查裡面的域名和自己通路網站的域名對不對的上，對的上的話，就說明這個證書确實是頒發給這個網站的；
           

如果浏覽器發現證書有問題，一般是證書裡面的簽名者不是浏覽器認為值得信任的CA，浏覽器就會給出警告頁面，這時候需要謹慎，有可能證書被掉包了。如通路A網站，由于A的證書是自己簽的名，并且浏覽器不認為A是受信的CA，是以就會給警告，但是一旦你把A的根證書安裝到了你的浏覽器中，那麼下次就不會警告了，因為你配置了浏覽器讓它相信A是一個受信的CA。

使用Charles 進行Https 抓包

安裝Charles

打開浏覽器通路 Charles 官網 ，下載下傳相應系統的 Charles 安裝包，然後安裝即可;

Charles 主界面

工具導航欄

Charles 頂部為菜單導航欄，菜單導航欄下面為工具導航欄。工具導航欄中提供了幾種常用工具：

通過 Charles 進行移動端抓包

手機抓包的原理，和 PC 類似，手機通過把網絡委托給 Charles 進行代理與服務端進行對話。具體步驟如下：

1. 使手機和電腦在一個區域網路内，不一定非要是一個 IP 段，隻要是在同一個路由器下即可。

2. 打開 Charles 的代理功能：通過主菜單打開 Proxy | Proxy Settings 彈窗，填入代理端口(端口預設為 

8888

，不用修改)，勾選 

Enable transparent HTTP proxying

。

3. 通過 Charles 的主菜單 Help | Local IP Address 或者通過指令行工具輸入 

ipconfig

檢視本機的 IP 位址。

4. 設定代理：打開手機端的 WIFI 代理設定，輸入電腦 IP 和 Charles 的代理端口。

5.設定好之後，我們打開手機上的任意需要網絡請求的程式，就可以看到 Charles 彈出手機請求連接配接的确認菜單（隻有首次彈出），點選 Allow 即可完成設定。

完成上述步驟就可以抓取手機的包了，Http 抓包這樣就可以了，

Https 抓包

Charles 預設不支援Https 抓包，如下：

要想抓取Https 需要稍微配置一下

1. 在SSL Proxying Settings 這裡設定，如下就添加了指定Charles 可以抓取Https 的網址

在SSL Proxying Settings 設定，如進行api.weibo.cn:443 的設定，就可以抓取api.weibo.cn 的Https 包，

（是以進行*:443 的設定就可以抓取所有的Https 包了）

2. 安裝證書，手機上安裝Charles 的證書

手機在浏覽器輸入chls.pro/ssl 安裝證書

iPhone 打開設定 -> 通用 -> 關于本機 -> 證書信任設定 -> 開啟開關

經過上面的設定就可以抓取Https 的包了。

值得注意的是Android7.0 及更高版本就抓不了Https 的包了。

Charles 功能

Breakpoints 功能

Breakpoints 針對目前的網絡請求設定斷點，

可以修改請求的參數，這樣就不用修改代碼了，直接通過Charles 就可完成請求的相關修改；可以對相應進行修改；這樣就很友善的完成某些網絡功能的測試啦。

我們以修改響應為例來簡單描述一下Breakpoints 功能的使用。

選中要設定的接口，右鍵點選Breakpoints ，這樣在下次請求該接口的時候Charles 會幫我們斷在該處。

可以進行請求的修改，點選右下角的Execute 可以繼續執行請求。

可以看到多出Edit Response ，修改響應，如圖修改了“一起看”為“一起康”，這樣顯示效果就這樣啦

Map Local 功能

我們需要填寫重定向的原位址資訊和本地目标檔案。我們可以先将某個接口的響應内容儲存下來（選擇對應的網絡請求，右擊點選 Save Response ）成為 data.json 檔案。然後我們編輯裡面的 status 、message、data 等資訊為我們想要的目标映射檔案。

這樣再次觸發該請求的時候就走我們修改過的data.json 檔案，進而友善測試某些字段的值（因為我們可以随便改）。

例如儲存到了桌面，命名為data.json

在Tool 菜單下選擇Map Local...

勾選Enable Map Local 代表使用該功能，點選Add 添加映射資訊。

填寫資訊Map From 為我們想要映射的原網絡接口，Map To 為目标檔案

傳回的資訊如圖，由原來的“一起看”變為“意七康”。

Rewrite 功能

Rewrite 适合對某個網絡請求進行正則替換，以達到修改結果的目的。使用如下。

點選去設定Rewrite ，

點選上面Location 的Add 添加我們要處理的接口

點選下面的Add 填我們的修改規則

如圖，這裡要修改的body ，将傳回内容的“一起看”，替換為“看看吧”，這樣傳回的資訊如下

手機App 上的效果如圖

Block List

Charles 黑名單

阻止對比對host的請求；可以直接把請求丢掉，也可以直接傳回403狀态碼；

當Charles收到與黑名單相比對的請求時，Charles 會阻止該請求。

白名單

當Charles 收到與白名單不比對的請求時，Charles會阻止該請求。

就是開啟百名到後Charles 隻允許白名單的host 進行請求。同樣可以選擇Charles是否會簡單地關閉浏覽器的連接配接，或者向浏覽器傳回錯誤頁面（具有403 響應）。

如果黑名單，白名單都開啟呢？就是黑名單上與白名單上出現交集的部分host 會Charles怎樣處理呢？

會按照黑名單的規定來。

例如開啟黑名單，并設定403 響應

效果如下