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單向認證
先來看看單向認證的過程：
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單向認證
先來看看單向認證的過程：
從上圖可以看出，服務端擁有一對非對稱密鑰：B_公鑰和B_私鑰。詳細過程如下：
（1）客戶端發起HTTPS請求，將SSL協議版本的信息發送給服務端。
（2）服務端去CA機構申請來一份CA證書，在前面提過，證書裡面有服務端公鑰和簽名。將CA證書發送給客戶端
（3）客戶端讀取CA證書的明文信息，採用相同的hash散列函數計算得到信息摘要（hash目的：驗證防止內容被修改），然後用操作系統帶的CA的公鑰去解密簽名（因為簽名是用CA的私鑰加密的），對比證書中的信息摘要。如果一致，則證明證書是可信的，然後取出了服務端公鑰
（4）客戶端生成一個隨機數（密鑰F），用剛才等到的服務端B_公鑰去加密這個隨機數形成密文，發送給服務端。
（5）服務端用自己的B_私鑰去解密這個密文，得到了密鑰F
（6）服務端和客戶端在後續通訊過程中就使用這個密鑰F進行通信了。和之前的非對稱加密不同，這裡開始就是一種對稱加密的方式
HTTPS雙向認證
雙向認證和單向認證原理基本差不多，單向認證客戶端需要認證服務端，而在雙向認證中增加了服務端對客戶端的認證
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單向認證
先來看看單向認證的過程：
從上圖可以看出，服務端擁有一對非對稱密鑰：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請求
- 接受服務端返回，用自己的證書偽裝成中間人服務端向客戶端發送數據內容。
具體過程如下圖所示：
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單向認證
先來看看單向認證的過程：
從上圖可以看出，服務端擁有一對非對稱密鑰：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，使無論是否是可信證書的情況，校驗結果返回都為正常狀態，從而實現繞過證書檢查的效果
【附】相關架構及資料
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單向認證
先來看看單向認證的過程：
從上圖可以看出，服務端擁有一對非對稱密鑰：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，使無論是否是可信證書的情況，校驗結果返回都為正常狀態，從而實現繞過證書檢查的效果
【附】相關架構及資料
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單向認證
先來看看單向認證的過程：
從上圖可以看出，服務端擁有一對非對稱密鑰：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，使無論是否是可信證書的情況，校驗結果返回都為正常狀態，從而實現繞過證書檢查的效果
【附】相關架構及資料
image.png
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單向認證
先來看看單向認證的過程：
從上圖可以看出，服務端擁有一對非對稱密鑰：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，使無論是否是可信證書的情況，校驗結果返回都為正常狀態，從而實現繞過證書檢查的效果
【附】相關架構及資料
image.png
領取方式：
資料免費領取方式：轉發後關注我後臺私信關鍵詞【資料】獲取！
相關推薦
![[破解]app無法抓包，一旦抓包就斷網如何解決？](http://image.zixundingzhi.com/JMA_Re1Kf1Gy9ZxB_z1REM5aSKg=/200x140/full/8754e76f5d10f24815c725590e79409beec3f1d4 "[破解]app無法抓包，一旦抓包就斷網如何解決？")
