HTTP(HyperText Transfer Protocol，超文本傳輸協(xié)議)被用于在Web瀏覽器和網站服務器之間傳遞信息，在TCP/IP中處于應用層。

[[278062]]

這里提一下TCP/IP的分層共分為四層：應用層、傳輸層、網絡層、數(shù)據(jù)鏈路層; 分層的目的是：分層能夠解耦，動態(tài)替換層內協(xié)議

各個層包含的內容：

應用層：向用戶提供應用服務時的通訊活動(ftp，dns，http)

傳輸層：網絡連接中兩臺計算機的數(shù)據(jù)傳輸(tcp、udp)

網絡層：處理網絡上流動的數(shù)據(jù)包，通過怎樣的傳輸路徑把數(shù)據(jù)包傳送給對方(ip)

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

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

• 通信使用明文，內容可能被竊聽
• 不驗證通信方的身份，因此有可能遭遇偽裝
• 無法證明報文的完整性，所以有可能遭到篡改

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

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

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

• 對稱加密 ： 加密和解密數(shù)據(jù)使用同一個密鑰。這種加密方式的特點是速度很快，常見對稱加密的算法有 AES;
• 非對稱加密： 加密和解密使用不同的密鑰，這兩個密鑰形成有且僅有唯一的配對，叫公鑰和私鑰。數(shù)據(jù)用公鑰加密后必須用私鑰解密，數(shù)據(jù)用私鑰加密后必須用公鑰解密。一般來說私鑰自己保留好，把公鑰公開給別人(一般公鑰不會單獨出現(xiàn)，而是會寫進證書中)，讓別人拿自己的公鑰加密數(shù)據(jù)后發(fā)給自己，這樣只有自己才能解密。 這種加密方式的特點是速度慢，CPU 開銷大，常見非對稱加密算法有 RSA。

CA證書的相關知識： CA證書是由CA(Certification Authority)機構發(fā)布的數(shù)字證書。其內容包含：電子簽證機關的信息、公鑰用戶信息、公鑰、簽名和有效期。這里的公鑰服務端的公鑰，這里的簽名是指：用hash散列函數(shù)計算公開的明文信息的信息摘要，然后采用CA的私鑰對信息摘要進行加密，加密完的密文就是簽名。 即：證書 = 公鑰 + 簽名 +申請者和頒發(fā)者的信息。 客戶端中因為在操作系統(tǒng)中就預置了CA的公鑰，所以支持解密簽名(因為簽名使用CA的私鑰加密的)

有了這些預備知識后，就可以來看看HTTPS是如何怎么做到安全認證的。

HTTPS單向認證

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

從上圖可以看出，服務端擁有一對非對稱密鑰：B_公鑰和B_私鑰。詳細過程如下：

(1)客戶端發(fā)起HTTPS請求，將SSL協(xié)議版本的信息發(fā)送給服務端。

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

(3)客戶端讀取CA證書的明文信息，采用相同的hash散列函數(shù)計算得到信息摘要(hash目的：驗證防止內容被修改)，然后用操作系統(tǒng)帶的CA的公鑰去解密簽名(因為簽名是用CA的私鑰加密的)，對比證書中的信息摘要。如果一致，則證明證書是可信的，然后取出了服務端公鑰

(4)客戶端生成一個隨機數(shù)(密鑰F)，用剛才等到的服務端B_公鑰去加密這個隨機數(shù)形成密文，發(fā)送給服務端。

(5)服務端用自己的B_私鑰去解密這個密文，得到了密鑰F

(6)服務端和客戶端在后續(xù)通訊過程中就使用這個密鑰F進行通信了。和之前的非對稱加密不同，這里開始就是一種對稱加密的方式

HTTPS雙向認證

雙向認證和單向認證原理基本差不多，單向認證客戶端需要認證服務端，而在雙向認證中增加了服務端對客戶端的認證

雙向認證詳細過程如下：

(1)客戶端發(fā)起HTTPS請求，將SSL協(xié)議版本的信息發(fā)送給服務端。

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

(3)客戶端讀取CA證書的明文信息，采用相同的hash散列函數(shù)計算得到信息摘要(hash目的：驗證防止內容被修改)，然后用操作系統(tǒng)帶的CA的公鑰去解密簽名(因為簽名是用CA的私鑰加密的)，對比證書中的信息摘要。如果一致，則證明證書是可信的，然后取出了服務端公鑰

(4)客戶端發(fā)送自己的客戶端證書給服務端，證書里面有客戶端的公鑰：C_公鑰

(5)客戶端發(fā)送支持的對稱加密方案給服務端，供其選擇

(6)服務端選擇完加密方案后，用剛才得到的C_公鑰去加密選好的加密方案

(7)客戶端用自己的C_私鑰去解密選好的加密方案，客戶端生成一個隨機數(shù)(密鑰F)，用剛才等到的服務端B_公鑰去加密這個隨機數(shù)形成密文，發(fā)送給服務端。

(8)服務端和客戶端在后續(xù)通訊過程中就使用這個密鑰F進行通信了。和之前的非對稱加密不同，這里開始就是一種對稱加密的方式

HTTPS基本思路總結

HTTPS在保證數(shù)據(jù)安全傳輸上使用對稱加密和非對稱加密相結合的方式來進行的，簡單來說就是通過一次非對稱加密算法進行了最終通信密鑰的生成、確認和交換，然后在后續(xù)的通信過程中使用最終通信密鑰進行對稱加密通信。之所以不是全程非對稱加密，是因為非對稱加密的計算量大，影響通信效率。

抓包原理

HTTPS即使安全，也是能夠被抓包的，常見的抓包工具有：Charles、fildder等。

常用的HTTPS抓包方式是作為中間人，對客戶端偽裝成服務端，對服務端偽裝成客戶端。簡單來說：

截獲客戶端的HTTPS請求，偽裝成中間人客戶端去向服務端發(fā)送HTTPS請求

接受服務端返回，用自己的證書偽裝成中間人服務端向客戶端發(fā)送數(shù)據(jù)內容。

具體過程如下圖所示：

反抓包策略

為了防止中間人攻擊，可以使用SSL-Pinning的技術來反抓包。 可以發(fā)現(xiàn)中間人攻擊的要點的偽造了一個假的服務端證書給了客戶端，客戶端誤以為真。解決思路就是，客戶端也預置一份服務端的證書，比較一下就知道真假了。

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

• 證書鎖定 需要在客戶端代碼內置僅接受指定域名的證書，而不接受操作系統(tǒng)或瀏覽器內置的CA根證書對應的任何證書，通過這種授權方式，保障了APP與服務端通信的唯一性和安全性，因此客戶端與服務端(例如API網關)之間的通信是可以保證絕對安全。但是CA簽發(fā)證書都存在有效期問題，缺點是在 ** 證書續(xù)期后需要將證書重新內置到APP中**。
• 公鑰鎖定 提取證書中的公鑰并內置到客戶端中，通過與服務器對比公鑰值來驗證連接的正確性。制作證書密鑰時，公鑰在證書的續(xù)期前后都可以保持不變(即密鑰對不變)，所以可以避免證書有效期問題，一般推薦這種做法。

突破SSL-Pinning抓包

在逆向界，一山更比一山高。 思路是這樣的：內置證書或者公鑰的時候，常常會有對比驗證的函數(shù)，直接控制這個函數(shù)的返回結果讓驗證通過不就好了嗎。 于是就有了一個突破SLL-Pinning的經典操作：采用Xposed+justTrustme模塊。 這個方案使用的是JustTrustMe這個Xposed模塊，它所做的事情就是將各種已知的的HTTP請求庫中用于校驗證書的API都進行Hook，使無論是否是可信證書的情況，校驗結果返回都為正常狀態(tài)，從而實現(xiàn)繞過證書檢查的效果