HTTP（HyperText Transfer Protocol，超文本傳輸協(xié)議）被用于在Web瀏覽器和網(wǎng)站服務(wù)器之間傳遞信息，在TCP/IP中處于應(yīng)用層。這里提一下TCP/IP的分層共分為四層：應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層; 分層的目的是：分層能夠解耦，動態(tài)替換層內(nèi)協(xié)議
各個層包含的內(nèi)容：
應(yīng)用層：向用戶提供應(yīng)用服務(wù)時的通訊活動（ftp，DNS，http）
傳輸層：網(wǎng)絡(luò)連接中兩臺計算機(jī)的數(shù)據(jù)傳輸（tcp、udp）
網(wǎng)絡(luò)層：處理網(wǎng)絡(luò)上流動的數(shù)據(jù)包，通過怎樣的傳輸路徑把數(shù)據(jù)包傳送給對方（ip）
數(shù)據(jù)鏈路層：與硬件相關(guān)的網(wǎng)卡、設(shè)備驅(qū)動等等
然而HTTP也有以下明顯缺點：
- 通信使用明文，內(nèi)容可能被竊聽
- 不驗證通信方的身份，因此有可能遭遇偽裝
- 無法證明報文的完整性，所以有可能遭到篡改
這樣，HTTPS就登場了。HTTPS中的S表示SSL或者TLS，就是在原HTTP的基礎(chǔ)上加上一層用于數(shù)據(jù)加密、解密、身份認(rèn)證的安全層，即
- HTTP + 加密 + 認(rèn)證 + 完整性保護(hù) = HTTPS
加密相關(guān)的預(yù)備知識：對稱加密和非對稱加密。
- 對稱加密 ： 加密和解密數(shù)據(jù)使用同一個密鑰。這種加密方式的特點是速度很快，常見對稱加密的算法有 AES；
- 非對稱加密： 加密和解密使用不同的密鑰，這兩個密鑰形成有且僅有唯一的配對，叫公鑰和私鑰。數(shù)據(jù)用公鑰加密后必須用私鑰解密，數(shù)據(jù)用私鑰加密后必須用公鑰解密。一般來說私鑰自己保留好，把公鑰公開給別人（一般公鑰不會單獨出現(xiàn)，而是會寫進(jìn)證書中），讓別人拿自己的公鑰加密數(shù)據(jù)后發(fā)給自己，這樣只有自己才能解密。 這種加密方式的特點是速度慢，CPU 開銷大，常見非對稱加密算法有 RSA。
CA證書的相關(guān)知識： CA證書是由CA（Certification Authority）機(jī)構(gòu)發(fā)布的數(shù)字證書。其內(nèi)容包含：電子簽證機(jī)關(guān)的信息、公鑰用戶信息、公鑰、簽名和有效期。這里的公鑰服務(wù)端的公鑰，這里的簽名是指：用hash散列函數(shù)計算公開的明文信息的信息摘要，然后采用CA的私鑰對信息摘要進(jìn)行加密，加密完的密文就是簽名。 即：證書 = 公鑰 + 簽名 +申請者和頒發(fā)者的信息。 客戶端中因為在操作系統(tǒng)中就預(yù)置了CA的公鑰，所以支持解密簽名（因為簽名使用CA的私鑰加密的）
有了這些預(yù)備知識后，就可以來看看HTTPS是如何怎么做到安全認(rèn)證的。
HTTPS單向認(rèn)證
先來看看單向認(rèn)證的過程：
從上圖可以看出，服務(wù)端擁有一對非對稱密鑰：B_公鑰和B_私鑰。詳細(xì)過程如下：
（1）客戶端發(fā)起HTTPS請求，將SSL協(xié)議版本的信息發(fā)送給服務(wù)端。
（2）服務(wù)端去CA機(jī)構(gòu)申請來一份CA證書，在前面提過，證書里面有服務(wù)端公鑰和簽名。將CA證書發(fā)送給客戶端
（3）客戶端讀取CA證書的明文信息，采用相同的hash散列函數(shù)計算得到信息摘要（hash目的：驗證防止內(nèi)容被修改），然后用操作系統(tǒng)帶的CA的公鑰去解密簽名（因為簽名是用CA的私鑰加密的），對比證書中的信息摘要。如果一致，則證明證書是可信的，然后取出了服務(wù)端公鑰
（4）客戶端生成一個隨機(jī)數(shù)（密鑰F），用剛才等到的服務(wù)端B_公鑰去加密這個隨機(jī)數(shù)形成密文，發(fā)送給服務(wù)端。
（5）服務(wù)端用自己的B_私鑰去解密這個密文，得到了密鑰F
（6）服務(wù)端和客戶端在后續(xù)通訊過程中就使用這個密鑰F進(jìn)行通信了。和之前的非對稱加密不同，這里開始就是一種對稱加密的方式
HTTPS雙向認(rèn)證
雙向認(rèn)證和單向認(rèn)證原理基本差不多，單向認(rèn)證客戶端需要認(rèn)證服務(wù)端，而在雙向認(rèn)證中增加了服務(wù)端對客戶端的認(rèn)證
雙向認(rèn)證詳細(xì)過程如下：
（1）客戶端發(fā)起HTTPS請求，將SSL協(xié)議版本的信息發(fā)送給服務(wù)端。
（2）服務(wù)端去CA機(jī)構(gòu)申請來一份CA證書，在前面提過，證書里面有服務(wù)端公鑰和簽名。將CA證書發(fā)送給客戶端
（3）客戶端讀取CA證書的明文信息，采用相同的hash散列函數(shù)計算得到信息摘要（hash目的：驗證防止內(nèi)容被修改），然后用操作系統(tǒng)帶的CA的公鑰去解密簽名（因為簽名是用CA的私鑰加密的），對比證書中的信息摘要。如果一致，則證明證書是可信的，然后取出了服務(wù)端公鑰
（4）客戶端發(fā)送自己的客戶端證書給服務(wù)端，證書里面有客戶端的公鑰：C_公鑰
（5）客戶端發(fā)送支持的對稱加密方案給服務(wù)端，供其選擇
（6）服務(wù)端選擇完加密方案后，用剛才得到的C_公鑰去加密選好的加密方案
（7）客戶端用自己的C_私鑰去解密選好的加密方案，客戶端生成一個隨機(jī)數(shù)（密鑰F），用剛才等到的服務(wù)端B_公鑰去加密這個隨機(jī)數(shù)形成密文，發(fā)送給服務(wù)端。
（8）服務(wù)端和客戶端在后續(xù)通訊過程中就使用這個密鑰F進(jìn)行通信了。和之前的非對稱加密不同，這里開始就是一種對稱加密的方式
HTTPS基本思路總結(jié)
HTTPS在保證數(shù)據(jù)安全傳輸上使用對稱加密和非對稱加密相結(jié)合的方式來進(jìn)行的，簡單來說就是通過一次非對稱加密算法進(jìn)行了最終通信密鑰的生成、確認(rèn)和交換，然后在后續(xù)的通信過程中使用最終通信密鑰進(jìn)行對稱加密通信。之所以不是全程非對稱加密，是因為非對稱加密的計算量大，影響通信效率。
抓包原理
HTTPS即使安全，也是能夠被抓包的，常見的抓包工具有：Charles、fildder等。
常用的HTTPS抓包方式是作為中間人，對客戶端偽裝成服務(wù)端，對服務(wù)端偽裝成客戶端。簡單來說：
- 截獲客戶端的HTTPS請求，偽裝成中間人客戶端去向服務(wù)端發(fā)送HTTPS請求
- 接受服務(wù)端返回，用自己的證書偽裝成中間人服務(wù)端向客戶端發(fā)送數(shù)據(jù)內(nèi)容。
具體過程如下圖所示：
反抓包策略
為了防止中間人攻擊，可以使用SSL-Pinning的技術(shù)來反抓包。 可以發(fā)現(xiàn)中間人攻擊的要點的偽造了一個假的服務(wù)端證書給了客戶端，客戶端誤以為真。解決思路就是，客戶端也預(yù)置一份服務(wù)端的證書，比較一下就知道真假了。
SSL-pinning有兩種方式： 證書鎖定（Certificate Pinning） 和公鑰鎖定（ Public Key Pinning）。
- 證書鎖定 需要在客戶端代碼內(nèi)置僅接受指定域名的證書，而不接受操作系統(tǒng)或瀏覽器內(nèi)置的CA根證書對應(yīng)的任何證書，通過這種授權(quán)方式，保障了App與服務(wù)端通信的唯一性和安全性，因此客戶端與服務(wù)端（例如API網(wǎng)關(guān)）之間的通信是可以保證絕對安全。但是CA簽發(fā)證書都存在有效期問題，缺點是在 ** 證書續(xù)期后需要將證書重新內(nèi)置到APP中**。
- 公鑰鎖定 提取證書中的公鑰并內(nèi)置到客戶端中，通過與服務(wù)器對比公鑰值來驗證連接的正確性。制作證書密鑰時，公鑰在證書的續(xù)期前后都可以保持不變（即密鑰對不變），所以可以避免證書有效期問題，一般推薦這種做法。
突破SSL-Pinning抓包
在逆向界，一山更比一山高。 思路是這樣的：內(nèi)置證書或者公鑰的時候，常常會有對比驗證的函數(shù)，直接控制這個函數(shù)的返回結(jié)果讓驗證通過不就好了嗎。 于是就有了一個突破SLL-Pinning的經(jīng)典操作：采用Xposed+justTrustme模塊。 這個方案使用的是JustTrustMe這個Xposed模塊，它所做的事情就是將各種已知的的HTTP請求庫中用于校驗證書的API都進(jìn)行Hook，使無論是否是可信證書的情況，校驗結(jié)果返回都為正常狀態(tài)，從而實現(xiàn)繞過證書檢查的效果
