HTTPS 以及 Charles 抓包

一直對認證方面雲裏霧裏，感覺看過多少篇文章理解也不是很透徹，偶然工作中遇到了認證問題，再去查再去看，好像一下子明白了很多，果然學習知識是要循序漸進。這裏總結一下HTTPS以及用Charles抓HTTPS包要如何配置。

這裏先po出我覺得比較好並且引用的兩篇文章鏈接

關於HTTPS原理以及iOS Challenge

關於HTTPS原理以及Charles配置

我引用了這兩篇文章裏面的一些內容，按照自己的理解串了一遍，做一個總結。

HTTPS

一、HTTP

HTTP是一種常用的網絡傳輸協議，它是基於TCP的一種應用層協議:

HTTP安全性問題：

傳輸數據時是明文的，任何人通過一個簡單的抓包工具，就可以截獲到所有傳輸數據
傳輸數據時無法保證數據的完整，在截獲到明文數據後，很容易就可以將其篡改，這也是一些網頁總是被植入惡意廣告的原因
傳輸數據時無法保證真實性，這也是最恐怖的一點。誤入了域名欺騙的釣魚網站，極容易對用戶帶來財產損失

二、HTTPS

要理解HTTPS協議，首先需要明白什麼是SSL/TLS。SSL全稱“Secure Sockets Layer”，意思爲安全套接層。其實由網景公司爲了解決HTTP傳輸協議在安全方面的缺陷而設計的。後來被標準化，更名爲TLS，全稱“Transport Layer Security”，意思爲傳輸層安全協議。

HTTPS就是將HTTP協議與TLS協議組合起來，在不改變HTTP協議原設計的基礎上，爲其添加安全性校驗並對傳輸的數據進行加密。

三、證書與加密

HTTPS主要是爲了解決3個問題：數據加密、數據完整、數據真實。

數據完整與真實性靠一種關鍵技術：數字證書。

數據加密在發送數據前依賴SSL層對數據進行加密

數字證書

通過一個小例子可以很容易的理解證書的作用，這個例子的來源是<編程隨想>的作者，我這裏暫且借用一下：A公司的a到B公司辦事，爲了證明a確實是A公司的職員而不是商業間諜，A公司會爲a提供一個帶有公章的證明，當B公司看到這個證明時，就可以信任辦事員a。對比網絡傳輸，這個證明就是證書，證書可以保證這個網站的真實性。我們繼續往後分析，當B公司與越來越多的公司進行商業合作時，就又有新的問題出現了，比如C公司的c來B公司辦事，就需要拿C公司帶公章的證明，D公司的d來B公司辦事就需要拿D公司帶公章的證明...這樣一來，B公司要存放好多公司的公章和證明的模板，才能夠完成校驗。這樣未免也太麻煩了，對應到網絡傳輸中，客戶端就是B公司，各個網站都有自己的證書文件，這樣客戶端需要安裝信任大量的證書，爲了解決這樣的問題，就有了第三方CA機構。第三方CA機構是由大家公認信任的機構，例如R公司爲第三方信任機構，其業務是爲其他公司提供公章證明，這樣一來，B公司只要保有這個R公司的公章證明副本，其他A，C，D公司的辦事員也只需要從R公司申請到一個公章證明就可以到B公司來交流業務了。

CA的全稱是“Certificate Authority”，意爲證書授權中心。大部分CA機構頒發的證書都是需要付費的，CA機構頒發的證書一般都是根證書，根證書也比較容易理解，首先證書是有鏈式信任關係的，例如Y證書是由CA機構頒發的根證書，由這個Y證書還可以創建出許多子證書，子證書可以繼續創建子證書，只要根證書是受信任的，其下所有的子證書都是受信任的，如下圖：

我們可以打開開源中國博客的主頁：https://www.oschina.net/blog。在Chrome瀏覽器地址欄左邊可以查看證書信息，如下：

點擊證書信息，可以看到完整的證書鏈，如下圖：

從圖中可以看到，根證書是由CA機構VerSign公司頒發的。此處還可以看到當前證書是否有效以及過期時間，如果證書無效則說明此網頁信息有可能被篡改過，用戶在訪問時就要小心了。

除了CA機構可以簽發證書外，個人其實也是可以創建證書的，當然個人創建的證書也是不被信任的，我們姑且把這類證書叫做自簽名證書，如果用自簽名證書搭建了HTTPS的服務，則客戶端需要安裝對應的證書信任，纔可以進行此服務的訪問。

加密

HTTPS在保證數據安全傳輸上使用了加密算法，基本思路是非對稱加密和對稱加密結合來傳輸數據，一言以弊之，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中是客戶端對服務端做證書校驗，當然也有一些金融機構會有用戶證書作爲提供給服務端做用戶認證的工具，保證發出請求的的確是這部分授權用戶。我們僅分析客戶端對服務單做證書校驗的這種。這種方法的特點是證書校驗工作交由系統處理，系統只會允許可信CA簽發的數字證書能夠訪問，私有CA簽發的數字證書（比如12306以及我們上文說的Charles證書）是無法訪問的。因此將Charles私有CA簽發的數字證書安裝到手機中並且作爲受信任證書保存可以解決這個問題。