HTTPS與Charles

HTTP

應用層的HTTP作了什麼事？

通常會用到如下的關鍵信息：

請求的地址、請求方式（GET、POST等），Header信息有什麼（Accept類型，User-Agent信息等）， 請求的參數如何封裝，狀態碼錶示什麼含義，cookie如何處理，DNS怎麼請求等等。

以上內容均不在本文的討論環節中，請自行了解。

不足之處

HTTP的不足之處主要在於安全性，有如下幾點：

1. 通訊使用明文，內容會被竊聽。
2. 沒有驗證對方的身份，所以會遭遇假裝。
3. 沒法瞭解response的完整性，因此有可能已經被篡改了。

Charles

Charles是一個很是常見的抓包工具，經過進行代理，使計算機交互的網絡請求經過它進行中轉，記錄和顯示全部發送和接收的數據。 開發常常用它能夠作什麼事？

1. 截獲請求，查看其中詳細消息（被竊聽）
2. 模擬請求發送，好比repeat。（假裝請求）
3. 修改發送的數據或者接受的數據。（篡改內容）

補救措施

若是隻用http，有什麼方式能夠對第三方有必定的防範？

1. 直接對交互內容進行加密。 對請求的內容或者返回的內容進行加密，須要服務端與客戶端同時具有加密與解密功能，在每次發送消息，接受消息的時候都進行加密解密，這樣就算被截取，也沒法被識別，可是報文首部仍是不能被加密。

2. HTTP的基本認證機制 對於某些涉及到敏感信息的請求，會設定一個安全域，一旦進行返回便會返回401 Unanthorized，而且要求用戶輸入帳號與密碼，在客戶端進行base64加密後發送給服務端。在被竊聽以後被加密以後的消息依然會被截取，若是被竊聽方保存，仍然能夠再一次發送給服務端，獲取信任。

3. MD5校驗文件

HTTPS

HTTPS 就是在安全的傳輸層上發送的 HTTP。HTTPS 在將 HTTP 報文發送給 TCP 以前，先將其發送給了一個安全層，對其進行加密。

HTTP 安全層是經過 SSL 及其現代替代協議 TLS 來實現的。咱們遵循常見的用法，用術語 SSL 來表示 SSL 或者 TLS。

發送已加密的 HTTP 報文以前，客戶端和服務器要進行一次 SSL 握手，在這個握手過程當中，它們要完成如下工做:

• 交換協議版本號;
• 選擇一個兩端都瞭解的密碼;
• 對兩端的身份進行認證;
• 生成臨時的會話密鑰，以便加密信道。

在瞭解這個握手過程以前，須要瞭解對稱加密與非對稱加密的概念。

對稱加密

服務端與客戶端用相同的密鑰對消息加密，這樣就算攻擊者劫持到了中間的消息，仍是破解不了。

可是會有兩個問題:

若是要讓對方得到同樣的密鑰，總不能經過http的方式告訴對方，須要經過其餘的路徑。 每個客戶端使用的密鑰必須得不同，如何管理這麼多的密鑰。

非對稱加密

客戶端保存私鑰，服務端接受來自客戶端的公鑰。

雖然公鑰是能夠在網上公開的，可是黑客截取到了用公鑰加密的數據，沒有私鑰仍是不能打開。

能夠解決一大部分問題了，可是仍是有缺點：

可是黑客也能夠模擬客戶端發送數據，由於它也有公鑰。

若是公鑰被偷偷替換了，也沒法證實是不是真的公鑰。

非對稱加密的算法比對稱加密效率要低很多。

證書加密

證書就是爲了解決這個問題誕生的。

證書中包含不少信息，主要有：

• Web 站點的名稱和主機名;
• Web 站點的公開密鑰;
• 簽名頒發機構的名稱;
• 來自簽名頒發機構的簽名。

HTTPS通訊請求詳細步驟：

步驟1：客戶端經過發送ClientHello報文開始SSL通訊。報文中包含客戶端支持的SSL的指定版本、加密組件（CipherSuite）列表（所使用的加密算法及密鑰長度等）。

步驟2：服務器可進行SSL通訊時，會以ServerHello報文做爲應答。和客戶端同樣，在報文中包含SSL版本以及加密組件。服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。

步驟3：以後服務器發送Certificate報文。報文中包含公開密鑰證書。

步驟4：最後服務器發送ServerHelloDone報文通知客戶端，最初階段的SSL握手協商部分結束。

步驟5：SSL第一次握手結束以後，客戶端以ClientKeyExchange報文做爲迴應。報文中包含通訊加密中使用的一種被稱爲Premastersecret的隨機密碼串。該報文已用步驟3中的公開密鑰進行加密。

步驟6：接着客戶端繼續發送ChangeCipherSpec報文。該報文會提示服務器，在此報文以後的通訊會採用Premastersecret密鑰加密。

步驟7：客戶端發送Finished報文。該報文包含鏈接至今所有報文的總體校驗值。此次握手協商是否可以成功，要以服務器是否可以正確解密該報文做爲斷定標準。

步驟8：服務器一樣發送ChangeCipherSpec報文。

步驟9：服務器一樣發送Finished報文。

步驟10：服務器和客戶端的Finished報文交換完畢以後，SSL鏈接就算創建完成。固然，通訊會受到SSL的保護。今後處開始進行應用層協議的通訊，即發送HTTP請求。

步驟11：應用層協議通訊，即發送HTTP響應。

步驟12：最後由客戶端斷開鏈接。斷開鏈接時，發送close_notify報文。上圖作了一些省略，這步以後再發送TCPFIN報文來關閉與TCP的通訊。

缺點

既然HTTPS比HTTP好，爲何不一直用HTTPS？

1. 爲了處理SSL層級的通訊，通訊量會變大。
2. 在處理SSL加密解密同時，會更多的消耗服務器上的資源。
3. 使用的證書須要向認證機構購買，會有一筆不小的開銷。

Charles

回到Charles這個話題，爲何Charles能抓HTTP的請求？

由於Charles在服務端與客戶端作了一層代理。

爲何HTTPS的請求也能截取？

還記得在截取HTTPS請求的時候，須要作什麼麼？

1. 安裝並信任Charles證書。
2. 對SSL進行代理。

具體步驟：

1. 客戶端向服務器發起HTTPS請求

2. Charles攔截客戶端的請求，假裝成客戶端向服務器進行請求

3. 服務器向「客戶端」（其實是Charles）返回服務器的CA證書

4. Charles攔截服務器的響應，獲取服務器證書公鑰，而後本身製做一張證書，將服務器證書替換後發送給客戶端。（這一步，Charles拿到了服務器證書的公鑰）

5. 客戶端接收到「服務器」（其實是Charles）的證書後，生成一個對稱密鑰，用Charles的公鑰加密，發送給「服務器」（Charles）

6. Charles攔截客戶端的響應，用本身的私鑰解密對稱密鑰，而後用服務器證書公鑰加密，發送給服務器。（這一步，Charles拿到了對稱密鑰）

7. 服務器用本身的私鑰解密對稱密鑰，向「客戶端」（Charles）發送響應

8. Charles攔截服務器的響應，替換成本身的證書後發送給客戶端

至此，鏈接創建，Charles拿到了 服務器證書的公鑰 和 客戶端與服務器協商的對稱密鑰，以後就能夠解密或者修改加密的報文了。

這裏最關鍵的一步就是須要客戶端信任Charles證書，這也是爲何不要安裝來歷不明的盜版系統的緣由之一。

參考

• 趣談網絡協議
• HTTP權威指南
• 圖解HTTP