HTTP（HyperText Transfer Protocol，超文字傳輸協議）被用於在Web瀏覽器和網站伺服器之間傳遞資訊，在TCP/IP中處於應用層。這裡提一下TCP/IP的分層共分為四層：應用層、傳輸層、網路層、資料鏈路層; 分層的目的是：分層能夠解耦，動態替換層內協議
各個層包含的內容：
應用層：向使用者提供應用服務時的通訊活動（ftp，dns，http） 傳輸層：網路連線中兩臺計算機的資料傳輸（tcp、udp） 網路層：處理網路上流動的資料包，通過怎樣的傳輸路徑把資料包傳送給對方（ip） 資料鏈路層：與硬體相關的網路卡、裝置驅動等等
然而HTTP也有以下明顯缺點：
- 通訊使用明文，內容可能被竊聽
- 不驗證通訊方的身份，因此有可能遭遇偽裝
- 無法證明報文的完整性，所以有可能遭到篡改
這樣，HTTPS就登場了。HTTPS中的S表示SSL或者TLS，就是在原HTTP的基礎上加上一層用於資料加密、解密、身份認證的安全層，即
- HTTP + 加密 + 認證 + 完整性保護 = HTTPS
加密相關的預備知識：對稱加密和非對稱加密。
- 對稱加密 ： 加密和解密資料使用同一個金鑰。這種加密方式的特點是速度很快，常見對稱加密的演算法有 AES；
- 非對稱加密： 加密和解密使用不同的金鑰，這兩個金鑰形成有且僅有唯一的配對，叫公鑰和私鑰。資料用公鑰加密後必須用私鑰解密，資料用私鑰加密後必須用公鑰解密。一般來說私鑰自己保留好，把公鑰公開給別人（一般公鑰不會單獨出現，而是會寫進證照中），讓別人拿自己的公鑰加密資料後發給自己，這樣只有自己才能解密。 這種加密方式的特點是速度慢，CPU 開銷大，常見非對稱加密演算法有 RSA。
CA證照的相關知識： CA證照是由CA（Certification Authority）機構釋出的數字證照。其內容包含：電子簽證機關的資訊、公鑰使用者資訊、公鑰、簽名和有效期。這裡的公鑰服務端的公鑰，這裡的簽名是指：用hash雜湊函式計算公開的明文資訊的資訊摘要，然後採用CA的私鑰對資訊摘要進行加密，加密完的密文就是簽名。 即：證照 = 公鑰 + 簽名 +申請者和頒發者的資訊。 客戶端中因為在作業系統中就預置了CA的公鑰，所以支援解密簽名（因為簽名使用CA的私鑰加密的）
有了這些預備知識後，就可以來看看HTTPS是如何怎麼做到安全認證的。
HTTPS單向認證
先來看看單向認證的過程：
（2）服務端去CA機構申請來一份CA證照，在前面提過，證照裡面有服務端公鑰和簽名。將CA證照傳送給客戶端
（3）客戶端讀取CA證照的明文資訊，採用相同的hash雜湊函式計算得到資訊摘要（hash目的：驗證防止內容被修改），然後用作業系統帶的CA的公鑰去解密簽名（因為簽名是用CA的私鑰加密的），對比證照中的資訊摘要。如果一致，則證明證照是可信的，然後取出了服務端公鑰
（4）客戶端生成一個隨機數（金鑰F），用剛才等到的服務端B_公鑰去加密這個隨機數形成密文，傳送給服務端。
（5）服務端用自己的B_私鑰去解密這個密文，得到了金鑰F
（6）服務端和客戶端在後續通訊過程中就使用這個金鑰F進行通訊了。和之前的非對稱加密不同，這裡開始就是一種對稱加密的方式
HTTPS雙向認證
雙向認證和單向認證原理基本差不多，單向認證客戶端需要認證服務端，而在雙向認證中增加了服務端對客戶端的認證
（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
