HTTPS介紹

超文本傳輸安全協(xié)議（英語：Hypertext Transfer Protocol Secure冰木，縮寫：HTTPS扶镀，常稱為HTTP over TLS罕偎，HTTP over SSL或HTTP Secure）是一種網(wǎng)絡(luò)安全傳輸協(xié)議躏将。在計算機網(wǎng)絡(luò)上，HTTPS經(jīng)由超文本傳輸協(xié)議進行通信呻引，但利用SSL/TLS來加密數(shù)據(jù)包礼仗。HTTPS開發(fā)的主要目的，是提供對網(wǎng)絡(luò)服務(wù)器的身份認(rèn)證，保護交換數(shù)據(jù)的隱私與完整性元践。這個協(xié)議由網(wǎng)景公司（Netscape）在1994年首次提出韭脊，隨后擴展到互聯(lián)網(wǎng)上。

HTTPS連接經(jīng)常用于萬維網(wǎng)上的交易支付和企業(yè)信息系統(tǒng)中敏感信息的傳輸单旁。

http協(xié)議直接放置在TCP協(xié)議之上沪羔，而HTTPS提出在http和TCP中間加上一層加密層。從發(fā)送端看象浑，這一層負(fù)責(zé)把http的內(nèi)容加密后送到下層的TCP蔫饰，從接收方看，這一層負(fù)責(zé)將TCP送來的數(shù)據(jù)解密還原成http的內(nèi)容愉豺。所以嚴(yán)格地講篓吁，HTTPS并不是一個單獨的協(xié)議，而是對工作在一加密連接（TLS或SSL）上的常規(guī)HTTP協(xié)議的稱呼蚪拦。

下面是一個簡單的HTTPS協(xié)議棧的圖：

HTTPS流程步驟

上面已經(jīng)說過HTTPS主要是加了一層SSL/TLS加密杖剪，那么具體是如何進行加密，解密外盯，驗證的摘盆，且看下圖：

1. 客戶端發(fā)起HTTPS請求
這個沒什么好說的，就是用戶在瀏覽器里輸入一個https網(wǎng)址饱苟，然后連接到server的443端口。

2. 服務(wù)端的配置
采用HTTPS協(xié)議的服務(wù)器必須要有一套數(shù)字證書狼渊，可以自己制作箱熬，也可以向組織申請。區(qū)別就是自己頒發(fā)的證書需要客戶端驗證通過狈邑，才可以繼續(xù)訪問城须，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇，有1年的免費服務(wù))米苹。這套證書其實就是一對公鑰和私鑰糕伐。如果對公鑰和私鑰不太理解，可以想象成一把鑰匙和一個鎖頭蘸嘶，只是全世界只有你一個人有這把鑰匙良瞧，你可以把鎖頭給別人，別人可以用這個鎖把重要的東西鎖起來训唱，然后發(fā)給你褥蚯，因為只有你一個人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來的東西况增。

3. 傳送證書
這個證書其實就是公鑰赞庶，只是包含了很多信息，如證書的頒發(fā)機構(gòu)，過期時間等等歧强。

4. 客戶端解析證書
這部分工作是有客戶端的TLS來完成的澜薄，首先會驗證公鑰是否有效，比如頒發(fā)機構(gòu)摊册，過期時間等等表悬，如果發(fā)現(xiàn)異常，則會彈出一個警告框丧靡，提示證書存在問題蟆沫。如果證書沒有問題，那么就生成一個隨即值温治。然后用證書對該隨機值進行加密饭庞。就好像上面說的，把隨機值用鎖頭鎖起來熬荆，這樣除非有鑰匙舟山，不然看不到被鎖住的內(nèi)容。

5. 傳送加密信息
這部分傳送的是用證書加密后的隨機值卤恳，目的就是讓服務(wù)端得到這個隨機值累盗，以后客戶端和服務(wù)端的通信就可以通過這個隨機值來進行加密解密了。

6. 服務(wù)端解密信息
服務(wù)端用私鑰解密后突琳，得到了客戶端傳過來的隨機值(私鑰)若债，然后把內(nèi)容通過該值進行對稱加密。所謂對稱加密就是拆融，將信息和私鑰通過某種算法混合在一起蠢琳，這樣除非知道私鑰，不然無法獲取內(nèi)容镜豹，而正好客戶端和服務(wù)端都知道這個私鑰傲须，所以只要加密算法夠彪悍，私鑰夠復(fù)雜趟脂，數(shù)據(jù)就夠安全泰讽。

7. 傳輸加密后的信息
這部分信息是服務(wù)段用私鑰加密后的信息，可以在客戶端被還原

8. 客戶端解密信息
客戶端用之前生成的私鑰解密服務(wù)段傳過來的信息昔期，于是獲取了解密后的內(nèi)容已卸。整個過程第三方即使監(jiān)聽到了數(shù)據(jù)，也束手無策镇眷。

SSL/TLS概念

SSL/TLS是加密通信協(xié)議咬最，SSL由NetScape在1994年設(shè)計，1999年互聯(lián)網(wǎng)標(biāo)準(zhǔn)化組織ISOC接替NetScape公司欠动，發(fā)布了SSL的升級版TLS 1.0版∮牢冢現(xiàn)在主流的瀏覽器等都支持TLS1.2版本惑申，如iOS9中新增App Transport Security（簡稱ATS）特性，強制http轉(zhuǎn)向https翅雏，其中加密通信協(xié)議就需要TLS1.2及以上版本圈驼。

SSL/TLS協(xié)議的基本思路是采用公鑰加密法，也就是說望几，客戶端先向服務(wù)器端索要公鑰绩脆，然后用公鑰加密信息，服務(wù)器收到密文后橄抹，用自己的私鑰解密靴迫。

SSL/TLS協(xié)議的基本過程是這樣的：

（1） 客戶端向服務(wù)器端索要并驗證公鑰。
（2） 雙方協(xié)商生成"對話密鑰"楼誓。
（3） 雙方采用"對話密鑰"進行加密通信玉锌。

所以說SSL/TLS協(xié)議主要是包含非對稱加密（公鑰加密）和對稱加密，用非對稱加密來得到對稱加密的"對話秘鑰"疟羹，然后用對稱加密來進行加密通信主守。

兩個問題

如何保證公鑰不被篡改？

解決方法：將公鑰放在數(shù)字證書中榄融。只要證書是可信的参淫，公鑰就是可信的。那如何保證證書是可信的呢愧杯？證書由CA機構(gòu)進行頒發(fā)涎才，而游覽器內(nèi)置了這些CA機構(gòu)的根證書，只要由這些CA機構(gòu)辦法的數(shù)字證書即是可信的民效。

為什么不直接使用公鑰加密憔维，還要加上個對稱加密？

公鑰加密是非對稱加密畏邢，加密計算量大，而對稱加密運算速度非臣爝海快舒萎。所以這里只有第一次握手時進行公鑰加密來得到對稱加密的"對話密鑰"，之后的通信就使用對稱加密來進行通信了蹭沛。

加密算法

• 對稱密碼算法

是指加密和解密使用相同的密鑰臂寝，典型的有DES、RC5摊灭、IDEA（分組加密）咆贬，RC4（序列加密）；

• 非對稱密碼算法

又稱為公鑰加密算法帚呼，是指加密和解密使用不同的密鑰（公開的公鑰用于加密掏缎，私有的私鑰用于解密）皱蹦。比如A發(fā)送，B接收眷蜈，A想確保消息只有B看到沪哺，需要B生成一對公私鑰，并拿到B的公鑰酌儒。于是A用這個公鑰加密消息辜妓，B收到密文后用自己的與之匹配的私鑰解密即可。反過來也可以用私鑰加密公鑰解密忌怎。也就是說對于給定的公鑰有且只有與之匹配的私鑰可以解密籍滴，對于給定的私鑰榴啸，有且只有與之匹配的公鑰可以解密孽惰。典型的算法有RSA要销，DSA，DH歇由；

• 散列算法

散列變換是指把文件內(nèi)容通過某種公開的算法谢谦，變成固定長度的值（散列值）袁梗，這個過程可以使用密鑰也可以不使用剥懒。這種散列變換是不可逆的盐肃，也就是說不能從散列值變成原文撒会。因此媒吗，散列變換通常用于驗證原文是否被篡改。典型的算法有：MD5乙埃，SHA闸英，Base64，CRC等介袜。

關(guān)于CA及數(shù)字證書

什么是CA

CA(Certificate Authority)是數(shù)字證書認(rèn)證中心的簡稱甫何，是指發(fā)放、管理米酬、廢除數(shù)字證書的機構(gòu)沛豌。

CA的作用是檢查證書持有者身份的合法性，并簽發(fā)證書（在證書上簽字）赃额，以防證書被偽造或篡改加派，以及對證書和密鑰進行管理。

CA 也擁有一個證書（內(nèi)含公鑰）和私鑰跳芳。網(wǎng)上的公眾用戶通過驗證 CA 的簽字從而信任 CA 芍锦，任何人都可以得到 CA 的證書（含公鑰），用以驗證它所簽發(fā)的證書飞盆。
如果用戶想得到一份屬于自己的證書娄琉，他應(yīng)先向 CA 提出申請。在 CA 判明申請者的身份后吓歇，便為他分配一個公鑰孽水，并且 CA 將該公鑰與申請者的身份信息綁在一起，并為之簽字后城看，便形成證書發(fā)給申請者女气。

如果一個用戶想鑒別另一個證書的真?zhèn)危陀?CA 的公鑰對那個證書上的簽字進行驗證测柠，一旦驗證通過炼鞠，該證書就被認(rèn)為是有效的缘滥。

證書的內(nèi)容

數(shù)字證書的格式遵循X.509標(biāo)準(zhǔn)，X.509是由國際電信聯(lián)盟（ITU-T）制定的數(shù)字證書標(biāo)準(zhǔn)谒主，規(guī)范了公開密鑰認(rèn)證朝扼、證書吊銷列表、授權(quán)證書霎肯、證書路徑驗證算法等擎颖。

證書的內(nèi)容包括：電子簽證機關(guān)的信息、公鑰用戶信息姿现、公鑰肠仪、權(quán)威機構(gòu)的簽字和有效期等等。

下圖就表示一個數(shù)字證書包含的內(nèi)容：

我們這里能看到頒發(fā)機構(gòu)簽名是由申請者信息經(jīng)過哈希算法得到hash值备典，然后再用機構(gòu)的私鑰進行加密异旧。所以這個簽名只有辦法機構(gòu)的公鑰才能解密，而一般權(quán)威CA機構(gòu)的根證書（含公鑰）都內(nèi)置在瀏覽器中提佣，所以客戶端接收到這個數(shù)字證書后吮蛹，先把申請者信息用同樣的哈希算法得到hash值h1，然后用公鑰進行辦法機構(gòu)簽名解密得到hash值h2拌屏，如果h1==h2潮针，則表示證書是有效的。

下圖就是Charles的根證書例子：

編碼格式

同樣的X.509證書,可能有不同的編碼格式,目前有以下兩種編碼格式倚喂。

PEM - Privacy Enhanced Mail,打開看文本格式,以"-----BEGIN..."開頭, "-----END..."結(jié)尾,內(nèi)容是BASE64編碼.
查看PEM格式證書的信息:openssl x509 -in certificate.pem -text -noout
Apache和*NIX服務(wù)器偏向于使用這種編碼格式.

DER - Distinguished Encoding Rules,打開看是二進制格式,不可讀.
查看DER格式證書的信息:openssl x509 -in certificate.der -inform der -text -noout
Java和Windows服務(wù)器偏向于使用這種編碼格式.

相關(guān)的文件擴展名

這是比較誤導(dǎo)人的地方,雖然我們已經(jīng)知道有PEM和DER這兩種編碼格式,但文件擴展名并不一定就叫"PEM"或者"DER",常見的擴展名除了PEM和DER還有以下這些,它們除了編碼格式可能不同之外,內(nèi)容也有差別,但大多數(shù)都能相互轉(zhuǎn)換編碼格式每篷。

CRT - CRT應(yīng)該是certificate的三個字母,其實還是證書的意思,常見于*NIX系統(tǒng),有可能是PEM編碼,也有可能是DER編碼,大多數(shù)應(yīng)該是PEM編碼,相信你已經(jīng)知道怎么辨別.

CER - 還是certificate,還是證書,常見于Windows系統(tǒng),同樣的,可能是PEM編碼,也可能是DER編碼,大多數(shù)應(yīng)該是DER編碼.

KEY - 通常用來存放一個公鑰或者私鑰,并非X.509證書,編碼同樣的,可能是PEM,也可能是DER。
查看KEY的辦法:openssl rsa -in mykey.key -text -noout
如果是DER格式的話:openssl rsa -in mykey.key -text -noout -inform der

CSR - Certificate Signing Request,即證書簽名請求,這個并不是證書,而是向權(quán)威證書頒發(fā)機構(gòu)獲得簽名證書的申請,其核心內(nèi)容是一個公鑰(當(dāng)然還附帶了一些別的信息),在生成這個申請的時候,同時也會生成一個私鑰,私鑰要自己保管好端圈。
查看的辦法:openssl req -noout -text -in my.csr
如果是DER格式的話:openssl req -noout -text -in my.csr -inform der

PFX/P12 - predecessor of PKCS#12,對*nix服務(wù)器來說,一般CRT和KEY是分開存放在不同文件中的,但Windows的IIS則將它們存在一個PFX文件中,(因此這個文件包含了證書及私鑰)這樣會不會不安全焦读？應(yīng)該不會,PFX通常會有一個"提取密碼",你想把里面的東西讀取出來的話,它就要求你提供提取密碼,PFX使用的時DER編碼,如何把PFX轉(zhuǎn)換為PEM編碼？
openssl pkcs12 -in for-iis.pfx -out for-iis.pem -nodes
這個時候會提示你輸入提取代碼. for-iis.pem就是可讀的文本舱权。
生成pfx的命令類似這樣:openssl pkcs12 -export -in certificate.crt -inkey privateKey.key -out certificate.pfx -certfile CACert.crt

其中CACert.crt是CA(權(quán)威證書頒發(fā)機構(gòu))的根證書,有的話也通過-certfile參數(shù)一起帶進去.這么看來,PFX其實是個證書密鑰庫.

JKS - 即Java Key Storage,這是Java的專利,跟OpenSSL關(guān)系不大,利用Java的一個叫"keytool"的工具,可以將PFX轉(zhuǎn)為JKS,當(dāng)然了,keytool也能直接生成JKS,不過在此就不多表了矗晃。

證書編碼的轉(zhuǎn)換

• .crt轉(zhuǎn).der方法

openssl x509 -in cert.crt -out cert.der -outform DER

• .crt轉(zhuǎn).cer方法

openssl x509 -in cert.crt -out cert.cer -outform DER

• .crt轉(zhuǎn).pem方法

openssl x509 -in cert.crt -out cert.pem -outform PEM

生成自簽名證書的步驟

建立CA

• 在任意目錄建立文件夾，文件夾名稱任意

mkdir ca

• 進入到新建立的文件夾ca

cd ca

• 生成CA私鑰

openssl genrsa -out ca.key 2048

• 用CA私鑰生成CA的證書

openssl req -new -x509 -days 36500 -key ca.key -out ca.crt -subj "/C=CN/ST=Hangzhou/L=Hangzhou/O=Teamsun/OU=Dasheng" 

• 建立CA相應(yīng)目錄

 mkdir demoCA

 cd demoCA/
 
 mkdir newcerts

 touch index.txt

 echo '01' > serial

生成server端證書

• 進入ca文件夾

cd ca

• 生成server私鑰

openssl genrsa -out server.key 2048

• 使用server私鑰生成server端證書請求文件

openssl req -new -key server.key -out server.csr -subj "/C=CN/ST=Hangzhou/L=Hangzhou/O=Teamsun/OU=dasheng/CN=dasheng"

• 使用server證書請求文件通過CA生成自簽名證書

openssl ca -in server.csr -out server.crt -cert ca.crt -keyfile ca.key

• 驗證server證書

openssl verify -CAfile ca.crt server.crt

測試

• 使用server證書測試單向認(rèn)證

1. 打開窗口1啟動server

openssl s_server -accept 10001 -key server.key -cert server.crt

2. 打開窗口2啟動客戶端

openssl s_client -connect localhost:10001

3. 連接成功后在任意一個窗口輸入字符串會傳輸?shù)搅硗庖粋€窗口回顯宴倍。

腳本

快速創(chuàng)建證書的腳本

使用（host表示證書用于的域名张症，cerFile表示證書保存的目錄）：

sh ./generate_certificate.sh host cerFile

信任自簽名證書

查看證書鏈

Chrome57及后續(xù)版本Chrome瀏覽器用戶如要查看SSL證書信息只能通過開發(fā)者工具（右鍵->檢查），選擇安全標(biāo)簽（Security）進行查看了鸵贬。然后點擊View certificate查看證書鏈俗他，如下圖為查看www.google.com的證書鏈：

信任證書

在MAC上直接雙擊證書，然后在鑰匙串里就能看到這個證書了阔逼，我們能看到證書上會顯示此證書是由不被信任的簽發(fā)者簽發(fā)的或此根證書不被信任拯辙。然后我們再在鑰匙串中雙擊證書->信任->使用此證書時：始終信任。

這里我們可以信任兩種證書：CA根證書和CA簽名過的數(shù)字證書。兩種證書在鑰匙串中顯示的顏色是不一樣的涯保。

下圖就是自己創(chuàng)建的兩種證書：

我們信任兩種證書都可以使請求變成安全的請求，在瀏覽器中輸入的時候就不會有不安全的提示了周伦。這里說一下為什么兩種證書都可以夕春。

首先說CA根證書，這種就是我們正常的流程专挪，CA根證書用公鑰解密數(shù)字證書的簽名得到hash值及志，然后根據(jù)hash值相等判斷證書有效。
而不信任根證書只信任數(shù)字證書寨腔，就很容易理解了速侈，他們本來就是同一張證書，也不用通過加密解密什么的來判斷了迫卢。

Chrome信任根證書后提示鏈接不安全

這里我信任根證書之后還是提示鏈接不安全：ERR_CERT_WEAK_SIGNATURE_ALGORITHM倚搬。而信任數(shù)字證書則沒問題。發(fā)生這種情況的原因是Chrome 57版本以后是不支持SHA-1算出的hash值的證書簽名的乾蛤，而我們上面生成的證書默認(rèn)為SHA-1每界，這里只要改為SHA-256就可以了。

//用CA私鑰生成CA的證書
openssl req -new -x509 -days 36500 -key ca.key -out ca.crt -subj "/C=CN/ST=Hangzhou/L=Hangzhou/O=Teamsun/OU=Dasheng" -sha256

//使用server證書請求文件通過CA生成自簽名證書
openssl ca -in server.csr -out server.crt -cert ca.crt -keyfile ca.key -sha256

獲取證書小技巧

有時候我們沒有這個網(wǎng)站的證書家卖，那要如何得到呢眨层？

1. 使用openssl能直接得到這個證書:

openssl s_client -connect 172.16.10.244:8000 </dev/null 2>/dev/null | openssl x509 -outform DER > https.cer
```

2. 直接Safari輸入網(wǎng)站，如果是不安全的上荡，會顯示下圖趴樱，然后點擊顯示證書，勾選連接時始終信任酪捡，點擊繼續(xù)證書就添加到鑰匙串中了叁征。
   

iOS中使用自簽名證書

iOS9中新增App Transport Security（簡稱ATS）特性, 主要使到原來請求的時候用到的HTTP，都轉(zhuǎn)向TLS1.2協(xié)議進行傳輸沛善。這也意味著所有的HTTP協(xié)議都強制使用了HTTPS協(xié)議進行傳輸航揉。一般如果我們HTTPS服務(wù)使用的證書是CA權(quán)威機構(gòu)頒發(fā)的話，客戶端不用修改任何代碼金刁，因為iOS系統(tǒng)已經(jīng)內(nèi)置了這些權(quán)威機構(gòu)的根證書帅涂。但是如果是自簽名的證書的話就需要修改代碼來內(nèi)部信任這部分證書了。

AFNetworking使用自簽名證書

AFNetWorking封裝了如何使用自簽名證書尤蛮，簡單的使用方式如下媳友。

//先導(dǎo)入證書，找到證書的路徑
NSString *cerPath = [[NSBundle mainBundle] pathForResource:@"cert" ofType:@"der"];
NSData *certData = [NSData dataWithContentsOfFile:cerPath];
NSSet * certSet = [[NSSet alloc] initWithObjects:certData, nil];
    
//AFSSLPinningModeNone 這個模式表示不做 SSL pinning产捞，只跟瀏覽器一樣在系統(tǒng)的信任機構(gòu)列表里驗證服務(wù)端返回的證書醇锚。若證書是信任機構(gòu)簽發(fā)的就會通過，若是自己服務(wù)器生成的證書，這里是不會通過的焊唬。

//AFSSLPinningModeCertificate 這個模式表示用證書綁定方式驗證證書恋昼，需要客戶端保存有服務(wù)端的證書拷貝，這里驗證分兩步赶促，第一步驗證證書的域名/有效期等信息液肌，第二步是對比服務(wù)端返回的證書跟客戶端返回的是否一致。
    
//AFSSLPinningModePublicKey 這個模式同樣是用證書綁定方式驗證鸥滨，客戶端要有服務(wù)端的證書拷貝嗦哆，只是驗證時只驗證證書里的公鑰，不驗證證書的有效期等信息婿滓。只要公鑰是正確的老速，就能保證通信不會被竊聽，因為中間人沒有私鑰凸主，無法解開通過公鑰加密的數(shù)據(jù)橘券。
    
AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeNone];
// 是否允許,NO-- 不允許無效的證書
[securityPolicy setAllowInvalidCertificates:YES];
// 設(shè)置證書
[securityPolicy setPinnedCertificates:certSet];
//是否驗證域名信息
securityPolicy.validatesDomainName = NO;

    
AFHTTPSessionManager *manager = [[AFHTTPSessionManager manager] initWithBaseURL:[NSURL URLWithString:@"https://192.168.3.13:8000"]];
manager.securityPolicy = securityPolicy;
manager.responseSerializer = [AFHTTPResponseSerializer serializer];
[manager GET:@"/getInfo" parameters:@{@"t":@"1490927497.569"} progress:^(NSProgress * progress){
} success:^(NSURLSessionDataTask *task, id responseObject) {
    NSArray * array = [NSJSONSerialization JSONObjectWithData:responseObject options:NSJSONReadingMutableLeaves error:nil];
    NSLog(@"OK === %@",array);
} failure:^(NSURLSessionDataTask *task, NSError *error) {
    NSLog(@"error ==%@",error.description);
}];

證書需要滿足的條件

這里的證書使用CA根證書或CA簽名的數(shù)字證書都可以。

密鑰交換算法有RSA和ECDHE，RSA 歷史悠久，支持度好信柿，但不支持 PFS（Perfect Forward Secrecy）；而 ECDHE 是使用了 ECC（橢圓曲線）的 DH（Diffie-Hellman）算法鬓梅，計算速度快，支持 PFS谨湘。

1. iOS支持的秘鑰交換算法為：至少2048位的 RSA 密鑰或至少256位的 ECC 密鑰

2. 服務(wù)器證書的哈希算法必須為 SHA-2绽快，其摘要長度至少位256位。

3. 證書格式為.der紧阔，很多網(wǎng)上的教程都寫的是.cer坊罢，應(yīng)該是使用的舊版AFNetWorking，最新版的不支持.cer擅耽，需要使用.der格式活孩。

中間人攻擊

概念

關(guān)于Https最常講到的就是中間人攻擊，即所謂的Man-in-the-middle attack(MITM)乖仇。也就是攻擊者插入原先攻擊的雙方憾儒，讓雙方以為還在直接跟對方通訊，但實際上雙方的通信對方已變成了中間人乃沙，信息已經(jīng)是被中間人獲取或篡改起趾。

其實http的中間人攻擊是最簡單的，因為http都是通過明文傳輸警儒，而且沒有任何認(rèn)證之類的東西训裆。我們常常用的Charles抓包就是一個最簡單的中間人攻擊。

對HTTPS進行中間人攻擊

我們用Charles進行HTTPS的抓包的時候會發(fā)現(xiàn)抓到的包都是加過密的無法查看，那是不是就意味著無法抓取HTTPS的包了呢边琉？其實也是可以的属百，通過偽造證書，并且客戶端又安裝了Charles根證書艺骂，就可以抓取到HTTPS的包并解密了诸老。

具體的步驟是這樣的，手機安裝Charles根證書钳恕，手機使用Charles的代理，所有請求都經(jīng)過Charles中間人蹄衷。Charles劫持到請求忧额，替換服務(wù)端的證書為自己的偽證書，然后發(fā)送給客戶端愧口，客戶端使用Charles根證書來驗證這個偽證書睦番，驗證通過得到公鑰，然后用公鑰加密對話秘鑰發(fā)送回Charles中間人耍属，Charles中間人私用私鑰解密得到對話秘鑰并保存托嚣，然后再把對話秘鑰用服務(wù)端的公鑰加密返回給服務(wù)端，這樣就表示兩端握手成功厚骗，可以進行通信了示启。而且中間人也獲得了之后的對話秘鑰，可以解密之后的對話信息领舰。

Charles實現(xiàn)HTTPS抓包

這里基本的HTTP抓包的設(shè)置就不講了夫嗓，下面是基于實現(xiàn)基本的HTTP抓包的基礎(chǔ)上來實現(xiàn)HTTPS的抓包解密。

• 安裝Charles CA根證書
  點擊Help->SSL Proxying->Install Charles Root Certification ...冲秽，會彈出如下提示舍咖，鏈接代理，手機瀏覽器輸入chls.pro/ssl锉桑，就可以安裝根證書了排霉。
  

• 設(shè)置SSL代理
  點擊Proxy->SSL Proxying Setting，勾選Enable SSL Proxying民轴，然后點擊Add輸入要SSL代理的請求Host和Port攻柠，可以使用通配符來表示某一類請求。
  

  
  或者在對應(yīng)的請求上右鍵選擇Enable SSL Proxying杉武，就會把這一個請求加入到上面的SSL代理列表中（類似于點擊Add的效果）辙诞。
  

做完上述步驟后重新請求就能得到解密后的信息了。抓取PC端的HTTPS包也類似轻抱，在Help->SSL Proxying中下載證書飞涂，雙擊安裝證書，并選擇始終信任即可。

參考

超文本傳輸安全協(xié)議
圖解HTTPS
HTTPS從原理到應(yīng)用
那些證書相關(guān)的玩意兒
SSL/TLS協(xié)議運行機制的概述
SSL/TLS協(xié)議及Openssl工具的實現(xiàn)
openssl自簽名證書生成與單雙向驗證
iOS 10 適配 ATS
iOS安全系列之一：HTTPS
iOS安全系列之二：HTTPS進階