扯一扯HTTPS單向認證、雙向認證、抓包原理、反抓包策略

HTTP（HyperText Transfer Protocol，超文本傳輸協議）被用於在Web瀏覽器和網站服務器之間傳遞信息，在TCP/IP中處於應用層。這裏提一下TCP/IP的分層共分爲四層：應用層、傳輸層、網絡層、數據鏈路層;

分層的目的是：分層可以解耦，動態替換層內協議

各個層包含的內容：

應用層：向用戶提供應用服務時的通信活動（ftp，dns，http）

傳輸層：網絡鏈接中兩臺計算機的數據傳輸（tcp、udp）

網絡層：處理網絡上流動的數據包，經過怎樣的傳輸路徑把數據包傳送給對方（ip）

數據鏈路層：與硬件相關的網卡、設備驅動等等

然而HTTP也有如下明顯缺點：

1. 通訊使用明文，內容可能被竊聽
2. 不驗證通訊方的身份，所以有可能遭遇假裝
3. 沒法證實報文的完整性，因此有可能遭到篡改

這樣，HTTPS就登場了。HTTPS中的S表示SSL或者TLS，就是在原HTTP的基礎上加上一層用於數據加密、解密、身份認證的安全層，即

• HTTP + 加密 + 認證 + 完整性保護 = HTTPS

加密相關的預備知識：對稱加密和非對稱加密。

1. 對稱加密 ： 加密和解密數據使用同一個密鑰。這種加密方式的特色是速度很快，常見對稱加密的算法有 AES；
2. 非對稱加密： 加密和解密使用不一樣的密鑰，這兩個密鑰造成有且僅有惟一的配對，叫公鑰和私鑰。數據用公鑰加密後必須用私鑰解密，數據用私鑰加密後必須用公鑰解密。通常來講私鑰本身保留好，把公鑰公開給別人（通常公鑰不會單獨出現，而是會寫進證書中），讓別人拿本身的公鑰加密數據後發給本身，這樣只有本身才能解密。 這種加密方式的特色是速度慢，CPU 開銷大，常見非對稱加密算法有 RSA。

CA證書的相關知識：

CA證書是由CA（Certification Authority）機構發佈的數字證書。其內容包含：電子簽證機關的信息、公鑰用戶信息、公鑰、簽名和有效期。這裏的公鑰服務端的公鑰，這裏的簽名是指：用hash散列函數計算公開的明文信息的信息摘要，而後採用CA的私鑰對信息摘要進行加密，加密完的密文就是簽名。 即：證書 = 公鑰 + 簽名 +申請者和頒發者的信息。 客戶端中由於在操做系統中就預置了CA的公鑰，因此支持解密簽名（由於簽名使用CA的私鑰加密的）

有了這些預備知識後，就能夠來看看HTTPS是如何怎麼作到安全認證的。

HTTPS單向認證

先來看看單向認證的過程：

從上圖能夠看出，服務端擁有一對非對稱密鑰：B_公鑰和B_私鑰。詳細過程以下： （1）客戶端發起HTTPS請求，將SSL協議版本的信息發送給服務端。

（2）服務端去CA機構申請來一份CA證書，在前面提過，證書裏面有服務端公鑰和簽名。將CA證書發送給客戶端

（3）客戶端讀取CA證書的明文信息，採用相同的hash散列函數計算獲得信息摘要（hash目的：驗證防止內容被修改），而後用操做系統帶的CA的公鑰去解密簽名（由於簽名是用CA的私鑰加密的），對比證書中的信息摘要。若是一致，則證實證書是可信的，而後取出了服務端公鑰

（4）客戶端生成一個隨機數（密鑰F），用剛纔等到的服務端B_公鑰去加密這個隨機數造成密文，發送給服務端。

（5）服務端用本身的B_私鑰去解密這個密文，獲得了密鑰F

（6）服務端和客戶端在後續通信過程當中就使用這個密鑰F進行通訊了。和以前的非對稱加密不一樣，這裏開始就是一種對稱加密的方式

HTTPS雙向認證

雙向認證和單向認證原理基本差很少，單向認證客戶端須要認證服務端，而在雙向認證中增長了服務端對客戶端的認證

雙向認證詳細過程以下： （1）客戶端發起HTTPS請求，將SSL協議版本的信息發送給服務端。

（2）服務端去CA機構申請來一份CA證書，在前面提過，證書裏面有服務端公鑰和簽名。將CA證書發送給客戶端

（3）客戶端讀取CA證書的明文信息，採用相同的hash散列函數計算獲得信息摘要（hash目的：驗證防止內容被修改），而後用操做系統帶的CA的公鑰去解密簽名（由於簽名是用CA的私鑰加密的），對比證書中的信息摘要。若是一致，則證實證書是可信的，而後取出了服務端公鑰

（4）客戶端發送本身的客戶端證書給服務端，證書裏面有客戶端的公鑰：C_公鑰

（5）客戶端發送支持的對稱加密方案給服務端，供其選擇

（6）服務端選擇完加密方案後，用剛纔獲得的C_公鑰去加密選好的加密方案

（7）客戶端用本身的C_私鑰去解密選好的加密方案，客戶端生成一個隨機數（密鑰F），用剛纔等到的服務端B_公鑰去加密這個隨機數造成密文，發送給服務端。

（8）服務端和客戶端在後續通信過程當中就使用這個密鑰F進行通訊了。和以前的非對稱加密不一樣，這裏開始就是一種對稱加密的方式

HTTPS基本思路總結

HTTPS在保證數據安全傳輸上使用對稱加密和非對稱加密相結合的方式來進行的，簡單來講就是經過一次非對稱加密算法進行了最終通訊密鑰的生成、確認和交換，而後在後續的通訊過程當中使用最終通訊密鑰進行對稱加密通訊。之因此不是全程非對稱加密，是由於非對稱加密的計算量大，影響通訊效率。

抓包原理

HTTPS即便安全，也是可以被抓包的，常見的抓包工具備：Charles、fildder等。

經常使用的HTTPS抓包方式是做爲中間人，對客戶端假裝成服務端，對服務端假裝成客戶端。簡單來講：

• 截獲客戶端的HTTPS請求，假裝成中間人客戶端去向服務端發送HTTPS請求
• 接受服務端返回，用本身的證書假裝成中間人服務端向客戶端發送數據內容。

具體過程以下圖所示：

反抓包策略

爲了防止中間人攻擊，可使用SSL-Pinning的技術來反抓包。 能夠發現中間人攻擊的要點的僞造了一個假的服務端證書給了客戶端，客戶端誤覺得真。解決思路就是，客戶端也預置一份服務端的證書，比較一下就知道真假了。

SSL-pinning有兩種方式： 證書鎖定（Certificate Pinning） 和公鑰鎖定（ Public Key Pinning）。

• 證書鎖定 須要在客戶端代碼內置僅接受指定域名的證書，而不接受操做系統或瀏覽器內置的CA根證書對應的任何證書，經過這種受權方式，保障了APP與服務端通訊的惟一性和安全性，所以客戶端與服務端（例如API網關）之間的通訊是能夠保證絕對安全。可是CA簽發證書都存在有效期問題，缺點是在 證書續期後須要將證書從新內置到APP中。
• 公鑰鎖定 提取證書中的公鑰並內置到客戶端中，經過與服務器對比公鑰值來驗證鏈接的正確性。製做證書密鑰時，公鑰在證書的續期先後均可以保持不變（即密鑰對不變），因此能夠避免證書有效期問題，通常推薦這種作法。

突破SSL-Pinning抓包

在逆向界，一山更比一山高。 思路是這樣的：內置證書或者公鑰的時候，經常會有對比驗證的函數，直接控制這個函數的返回結果讓驗證經過不就行了嗎。 因而就有了一個突破SLL-Pinning的經典操做：採用Xposed+justTrustme模塊。 這個方案使用的是JustTrustMe這個Xposed模塊，它所作的事情就是將各類已知的的HTTP請求庫中用於校驗證書的API都進行Hook，使不管是不是可信證書的狀況，校驗結果返回都爲正常狀態，從而實現繞過證書檢查的效果。 更多突破SSL-Pinning的方法請參考： 當你寫爬蟲抓不到APP請求包的時候該怎麼辦？【中級篇】

公衆號：偉偉學Python