前言：我這里記錄了關於CA證書->https單向認證->抓包工具在https抓包原理->https雙向認證->SSL pining原理和繞過以及一些細節的思考（不知道對或錯）
CA證書
先來了解下關於CA證書
證書是用來證明公鑰擁有者身份的憑證。
CA證書的由來
CA證書一般由證書認證機構（CA）簽發，過程：
1、申請者自己通過非對稱加密算法（RSA） 生成對應的公鑰和私鑰，然后把需要的申請信息（國家，域名等）連同公鑰（就是RSA生成的公鑰）發送給 證書認證機構（CA）
2、證書認證機構（CA）確認無誤后通過消息摘要算法（MD5，SHA) 加密申請的CA證書中的信息，加密完的就叫信息摘要，然后把信息摘要用CA的私鑰（申請的RSA私鑰） 進行加密，加密完的數據就是簽名。
對於如上申請的證書中包含如下的內容：
1）RSA公鑰
2）證書擁有者身份信息
3）數字證書認證機構（發行者）信息
4）發行者對這份文件的數字簽名及使用的算法
5）證書的有效期
總結：CA證書包含以下信息：申請者公鑰、信息摘要（申請者的組織信息和個人信息、簽發機構 CA 的信息、有效時間、證書序列號等信息的明文），同時包含一個簽名sign（對信息摘要用RSA私鑰加密的一段sign值）。
https單向認證
網上的一張圖，我自己覺得好理解就拿過來放上去了
1、客戶端向服務端發送SSL協議版本號、加密算法種類、隨機數等信息。
2、服務端給客戶端返回SSL協議版本號、加密算法種類、隨機數等信息，同時也返回服務器端的證書（包含了公鑰和數字簽名）。
3、客戶端使用服務端返回的信息驗證服務器的合法性，包括：
* 證書是否過期（這個可能就是平常訪問瀏覽器有紅色的提示的原因）
* 發行服務器證書的CA是否可靠（這個可能就是平常訪問瀏覽器有紅色的提示的原因）
* 返回的公鑰是否能正確解開返回證書中的數字簽名
* 服務器證書上的域名是否和服務器的實際域名相匹配
* 驗證通過后，將繼續進行通信，否則，終止通信
4、客戶端向服務端發送自己所能支持的對稱加密方案，供服務器端進行選擇。
5、服務器端在客戶端提供的加密方案中選擇加密程度最高的加密方式。
6、服務器將選擇好的加密方案通過明文方式返回給客戶端。
7、客戶端接收到服務端返回的加密方式后，使用該加密方式生成產生隨機碼，這個隨機碼則用作通信過程中對稱加密的密鑰，使用服務端返回的公鑰進行加密，將加密后的隨機碼發送至服務端。
8、服務器收到客戶端返回的加密信息后，使用CA的私鑰進行解密，獲取對稱加密密鑰。 在接下來的會話中，服務器和客戶端將會使用該對稱加密密鑰進行對稱加密，保證通信過程中信息的安全。
個人理解：單向認證在認證方面，只有客戶端對服務端的證書進行了驗證，驗證了這個SSL證書是否是可信的，而服務端並沒有對客戶端的相關信息進行驗證，這就導致了下面抓包工具在https中進行抓包！
抓包工具在https抓包原理
1、客戶端向服務器發起HTTPS請求。
2、Charles攔截客戶端的請求，偽裝成客戶端向服務器進行請求。
3、服務器向“客戶端”（實際上是Charles）返回服務器的CA證書。
4、Charles攔截服務器的響應，獲取服務器證書公鑰，然后自己制作一張證書，將服務器證書替換后發送給客戶端。（這一步，Charles拿到了服務器證書的公鑰）。
5、客戶端接收到“服務器”（實際上是Charles）的證書后，生成一個對稱密鑰，用Charles的公鑰加密，發送給“服務器”（Charles）。
6、Charles攔截客戶端的響應，用自己Charles的私鑰解密對稱密鑰，然后用服務器證書公鑰加密，發送給服務器。（這一步，Charles拿到了對稱密鑰）。
7、服務器用自己的私鑰解密對稱密鑰，向“客戶端”（Charles）發送響應。
8、Charles攔截服務器的響應，替換成自己的證書后發送給客戶端。
至此，連接建立，Charles拿到了服務器證書的公鑰 和 客戶端與服務器協商的對稱密鑰，之后就可以解密或者修改加密的報文了。
HTTPS抓包的原理還是挺簡單的，簡單來說，就是Charles作為"中間人代理"，拿到了 服務器證書公鑰和HTTPS連接的對稱密鑰，前提是客戶端選擇信任並安裝Charles的CA證書，否則客戶端就會"報警"並中止連接。這樣看來，HTTPS還是很安全的。
這里就拿Charles如何實現https的抓包機制，重點在紅色的標記字體中，紅色的標記字體就體現在我們平常所講的搭建抓包的時候需要在手機中導入抓包工具提供的CA證書，原因也就是這個！
可以看出這個流程，是符合https單向認證的流程驗證，其實這個也就是https單向認證，唯一的不同就是多了一個中間人！
接下來我們繼續來看下雙向認證
https雙向認證
1、客戶端向服務端發送SSL協議版本號、加密算法種類、隨機數等信息。
2、服務端給客戶端返回SSL協議版本號、加密算法種類、隨機數等信息，同時也返回服務器端的證書，即公鑰證書（包含了公鑰和數字簽名）
3、客戶端使用服務端返回的信息驗證服務器的合法性，驗證通過后，將繼續進行通信，否則，終止通信，其中包括：
* 證書是否過期
* 發行服務器證書的CA是否可靠
* 返回的公鑰是否能正確解開返回證書中的數字簽名
* 服務器證書上的域名是否和服務器的實際域名相匹配
4、服務端要求客戶端發送客戶端的證書（這個證書指的就是內置存儲在當前APP中通信需要用的證書），客戶端會將自己內置的證書發送至服務端（在APP中一般都是類似client.p12的文件等等的）
5、服務端驗證客戶端的證書，通過驗證后，會獲得客戶端的公鑰
6、客戶端向服務端發送自己所能支持的對稱加密方案，供服務器端進行選擇
7、服務器端在客戶端提供的加密方案中選擇加密程度最高的加密方式
8、服務端將加密方案通過使用之前客戶端提供給服務端的公鑰進行加密，返回給客戶端
9、客戶端收到服務端返回的加密方案密文后，使用自己內置證書的私鑰進行解密，獲取具體加密方式，而后，產生該加密方式的隨機碼，用作加密過程中的密鑰，使用之前從服務端證書中獲取到的公鑰進行加密后，發送給服務端
10、服務端收到客戶端發送的消息后，使用自己的私鑰進行解密，獲取對稱加密的密鑰，在接下來的會話中，服務器和客戶端將會使用該密碼進行對稱加密，保證通信過程中信息的安全。
ps：雙向認證的客戶端證書一般都可以是如openssl生成的自簽名證書，包括 client.crt 和 client.key，這兩部分內容可以集成在 p12 證書中, p12 證書可以設置打開密碼。
個人理解：
1、單向認證 SSL 協議不需要客戶擁有CA證書。雙向認證要求服務器和用戶雙方都有證書，客戶端需要服務端證書的公鑰，服務端需要客戶端證書的公鑰，雙方拿到了之后會通過對通信的加密方式進行加密這種方法來進行互相認證，最后客戶端再隨機生成隨機碼進行對稱加密的驗證
問題：為什么通信的時候都是使用的對稱加密？
答案：是因為非對稱加密的計算量大，影響通信效率。
為什么之所以不是全程非對稱加密，是因為非對稱加密的計算量大，影響通信效率。
2、單向和雙向認證在通信中都是基於對稱加密來實現
關於SSL pining
雖然 HTTPS 采用了公鑰和證書的加密和驗證方式，但依然存在 MIM(中間人攻擊)的可能性，因為證書頒發機構可能被黑客入侵，而 HTTPS 只驗證了證書的合法性，並沒有驗證當前服務器是否是我們要訪問的服務器。
SSL pining還是https單向認證的范疇之內，SSL pining唯一的作用就是為了解決被中間人攻擊。
為了保證我們當前訪問的服務器就是我們需要訪問的服務器，需要通過 SSL Pinning 的方式來實現，其包括 Certificate Pinning 和 Public Key Pinning 兩種。
證書鎖定
證書鎖定需要把服務器的證書提前下載並內置到客戶端中，當請求發起時，通過比對證書內容來確定連接的合法性，但由於證書存在過期時間，因此當服務器端證書更換時，需同時更換客戶端證書。
既然是要鎖定證書，那么我們客戶端上應該事先存在一個證書，我們才能鎖定這個證書來驗證我們真正的服務端，而不是代理工具偽造的服務端。
如果是鎖定證書，那通常情況下會將證書放置在app/asset目錄下。
具體操作：將APP代碼內置僅接受指定域名的證書，而不接受操作系統或者瀏覽器內置的CA根證書對應的任何證書。
通過這種授權方式，保障了APP與服務端通信的唯一性和安全性，因此移動端APP與服務端（例如API網關）之間的通信可以保證絕對的安全。
公鑰鎖定
公鑰鎖定則需提取證書中的公鑰內置到客戶端中，通過比對公鑰值來驗證連接的合法性，由於證書更換依然可以保證公鑰一致，所以公鑰鎖定不存在客戶端頻繁更換證書的問題。
繞過思路
SSL pining單向認證驗證的是客戶端這邊，這樣的話我們就可以進行控制
內置證書或者公鑰的時候，常常會有對比驗證的函數，它會如何驗證？當我們抓包的時候，這里拿charles具體，charles作為中間人抓包，它返回給客戶端的是它自己的證書，由於SSL pining，此時客戶端會進行驗證，發現你返回的證書和我代碼中的驗證流程不一樣，那么就直接拒絕了，最后導致抓包失敗！
那么該如何解決？
那么我們直接控制這個函數的返回結果讓驗證通過不就好了嗎。
於是就有了一個突破SLL-Pinning的經典操作：采用Xposed+justTrustme模塊。
這個方案使用的是JustTrustMe這個Xposed模塊，它所做的事情就是將各種已知的的HTTP請求庫中用於校驗證書的API都進行Hook，使無論是否是可信證書的情況，校驗結果返回都為正常狀態，從而實現繞過證書檢查的效果。
先來回顧下上面的雙向驗證一共有幾步，一共有十步（自己可以去數下....）！
如果正常通過charles工具抓包的時候雙向驗證會如何處理？
在第三步就會被結束，原因就是返回給客戶端的是charles的CA證書，不符合
然后再來講下如果你把ssl pining繞過的技術使用在了雙向驗證的時候，會出現什么？
在第四步就會結束，雖然你繞過了客戶端的驗證，但是你逃不出服務端的驗證，你返回給服務端的是charles的證書，不符合
如果是正常的雙向驗證的話，只需要導入存儲在APP端的CA證書即可
但是基於ssl pinning的雙向驗證的話，需要導入存儲在APP端的CA證書，而且還需要繞過客戶端的強校驗