本文內(nèi)容轉(zhuǎn)載自博客園HTTPS協(xié)議解析
在說HTTPS之前先說說什么是HTTP敦腔，HTTP就是我們平時瀏覽網(wǎng)頁時候使用的一種協(xié)議。HTTP協(xié)議傳輸?shù)臄?shù)據(jù)都是未加密的胞谭，也就是明文的垃杖，因此使用HTTP協(xié)議傳輸隱私信息非常不安全。為了保證這些隱私數(shù)據(jù)能加密傳輸丈屹，于是網(wǎng)景公司設(shè)計了SSL（Secure Sockets Layer）協(xié)議用于對HTTP協(xié)議傳輸?shù)臄?shù)據(jù)進行加密调俘，從而就誕生了HTTPS。SSL目前的版本是3.0旺垒，被IETF（Internet Engineering Task Force）定義在RFC 6101中彩库，之后IETF對SSL 3.0進行了升級，于是出現(xiàn)了TLS（Transport Layer Security） 1.0先蒋，定義在RFC 2246骇钦。實際上我們現(xiàn)在的HTTPS都是用的TLS協(xié)議，但是由于SSL出現(xiàn)的時間比較早竞漾，并且依舊被現(xiàn)在瀏覽器所支持眯搭，因此SSL依然是HTTPS的代名詞，但無論是TLS還是SSL都是上個世紀的事情畴蹭，SSL最后一個版本是3.0坦仍，今后TLS將會繼承SSL優(yōu)良血統(tǒng)繼續(xù)為我們進行加密服務(wù)鳍烁。目前TLS的版本是1.2叨襟，定義在RFC 5246中，暫時還沒有被廣泛的使用幔荒，具體概念可參考百科HTTPS概念.
二 HTTPS 驗證原理
Https在真正請求數(shù)據(jù)前糊闽，先會與服務(wù)有幾次握手驗證，以證明相互的身份爹梁，以下圖為例
2.1 驗證流程
注：文中所寫的序號與圖不對應(yīng)但流程是對應(yīng)的
1 客戶端發(fā)起一個https的請求右犹，把自身支持的一系列Cipher Suite（密鑰算法套件，簡稱Cipher）發(fā)送給服務(wù)端
2 服務(wù)端姚垃，接收到客戶端所有的Cipher后與自身支持的對比念链，如果不支持則連接斷開，反之則會從中選出一種加密算法和HASH算法以證書的形式返回給客戶端 證書中還包含了 公鑰 頒證機構(gòu) 網(wǎng)址 失效日期等等积糯。
3 客戶端收到服務(wù)端響應(yīng)后會做以下幾件事
3.1 驗證證書的合法性
頒發(fā)證書的機構(gòu)是否合法與是否過期掂墓，證書中包含的網(wǎng)站地址是否與正在訪問的地址一致等證書驗證通過后，在瀏覽器的地址欄會加上一把小鎖(每家瀏覽器驗證通過后的提示不一樣不做討論)
3.2 生成隨機密碼
如果證書驗證通過看成，或者用戶接受了不授信的證書君编，此時瀏覽器會生成一串隨機數(shù)，然后用證書中的公鑰加密川慌。
3.3 HASH握手信息
用最開始約定好的HASH方式吃嘿，把握手消息取HASH值祠乃， 然后用 隨機數(shù)加密 “握手消息+握手消息HASH值(簽名)” 并一起發(fā)送給服務(wù)端.在這里之所以要取握手消息的HASH值，主要是把握手消息做一個簽名兑燥，用于驗證握手消息在傳輸過程中沒有被篡改過亮瓷。
4 服務(wù)端拿到客戶端傳來的密文，用自己的私鑰來解密握手消息取出隨機數(shù)密碼贪嫂，再用隨機數(shù)密碼 解密 握手消息與HASH值寺庄，并與傳過來的HASH值做對比確認是否一致。
然后用隨機密碼加密一段握手消息(握手消息+握手消息的HASH值 )給客戶端
5 客戶端用隨機數(shù)解密并計算握手消息的HASH力崇，如果與服務(wù)端發(fā)來的HASH一致斗塘，此時握手過程結(jié)束，之后所有的通信數(shù)據(jù)將由之前瀏覽器生成的隨機密碼并利用對稱加密算法進行加密.因為這串密鑰只有客戶端和服務(wù)端知道亮靴，所以即使中間請求被攔截也是沒法解密數(shù)據(jù)的馍盟，以此保證了通信的安全.
非對稱加密算法：RSA，DSA/DSS茧吊，在客戶端與服務(wù)端相互驗證的過程中用的是對稱加密
對稱加密算法：AES贞岭，RC4，3DES搓侄，客戶端與服務(wù)端相互驗證通過后瞄桨，以隨機數(shù)作為密鑰時，就是對稱加 密
HASH算法：MD5讶踪，SHA1芯侥，SHA256 在確認握手消息沒有被篡改時
2.2 客戶端如何驗證 證書的合法性？
1. 驗證證書是否在有效期內(nèi)乳讥。
在服務(wù)端面返回的證書中會包含證書的有效期柱查，可以通過失效日期來驗證 證書是否過期
2. 驗證證書是否被吊銷了。
被吊銷后的證書是無效的云石。驗證吊銷有CRL(證書吊銷列表)和OCSP(在線證書檢查)兩種方法唉工。
證書被吊銷后會被記錄在CRL中，CA會定期發(fā)布CRL汹忠。應(yīng)用程序可以依靠CRL來檢查證書是否被吊銷了淋硝。
CRL有兩個缺點，一是有可能會很大宽菜，下載很麻煩谣膳。針對這種情況有增量CRL這種方案。二是有滯后性赋焕，就算證書被吊銷了参歹，應(yīng)用也只能等到發(fā)布最新的CRL后才能知道。
增量CRL也能解決一部分問題隆判，但沒有徹底解決犬庇。OCSP是在線證書狀態(tài)檢查協(xié)議僧界。應(yīng)用按照標(biāo)準發(fā)送一個請求，對某張證書進行查詢臭挽，之后服務(wù)器返回證書狀態(tài)捂襟。
OCSP可以認為是即時的（實際實現(xiàn)中可能會有一定延遲），所以沒有CRL的缺點欢峰。
3. 驗證證書是否是上級CA簽發(fā)的葬荷。
windows中保留了所有受信任的根證書，瀏覽器可以查看信任的根證書纽帖，自然可以驗證web服務(wù)器的證書宠漩，
是不是由這些受信任根證書頒發(fā)的或者受信任根證書的二級證書機構(gòu)頒發(fā)的（根證書機構(gòu)可能會受權(quán)給底下的中級證書機構(gòu)，然后由中級證書機構(gòu)頒發(fā)中級證書）
在驗證證書的時候懊直，瀏覽器會調(diào)用系統(tǒng)的證書管理器接口對證書路徑中的所有證書一級一級的進行驗證扒吁，只有路徑中所有的證書都是受信的，整個驗證的結(jié)果才是受信
三 手機如何抓取HTTPS的請求數(shù)據(jù)
當(dāng)站點由HTTP轉(zhuǎn)成HTTPS后是更安全了室囊，但是有時候要看線上的請求數(shù)據(jù)解決問題時卻麻煩了雕崩，因為是HTTPS的請求，你就算攔截到了那也是加密的數(shù)據(jù)融撞，沒有任何意義盼铁。
那有方法解決嗎？ 答案是肯定的尝偎！ 接下來就來個實例教程饶火，教大家如何查看HTTPS的請求數(shù)據(jù)
首先需要安裝Fiddler 用于攔截請求，和頒發(fā)https證書
3.1 Fiddler根證書導(dǎo)出
按圖中操作把導(dǎo)出冬念，再將導(dǎo)出的的根證書"FiddlerRoot.cer" 的后輟名 改為"crt" "FiddlerRoot.crt" 因為手機沒法直接安裝 cer格式的證書
3.2 證書安裝
在本機把證書移到本機IIS中的某個網(wǎng)站的物理目錄中趁窃，然后在手機瀏覽器中訪問該證書的目錄 如："192.168.0.102：8001/FiddlerRoot.crt"
如圖
此時手機會提示按裝根證書牧挣，其實安裝一個不受信的根證書是非常危險的急前，如果你安裝了某些釣魚網(wǎng)站或者有危害的根證書，那只要是該根證書下的所有證書都會驗證通過瀑构，
那隨便一個釣魚網(wǎng)的網(wǎng)站只要安裝了該根證書下的證書裆针，都不會有任何警告提示。
很可能讓用戶有財產(chǎn)損失寺晌。所以在安裝根證書時世吨，手機系統(tǒng)會要求你輸入鎖屏密碼，以確保是本人操作呻征。
安裝過程如下
Fiddler的根證書名字都提示了是不受信的根證書
安裝完成
3.3 通過Fiddler抓取手機的HTTPS請求
Fiddler默認偵聽的端口是8888,把手機WiFI的Http 代理設(shè)為本機Fiddler的地址如下圖
這樣手機上所有的請求都會先通過Fiddler耘婚，F(xiàn)iddler再轉(zhuǎn)發(fā)到目標(biāo)服務(wù)器
注意： 在家中的路由器中有線與無線通常不在一個網(wǎng)段，會導(dǎo)致Fiddler無法抓到手機的包陆赋，需要手動設(shè)置路由沐祷，可自行百度
代理也設(shè)好之后便可以開始抓到Https的請求內(nèi)容了如圖
Https的默認端口號是 “443”可以看出紅框中的是未裝根證書前的請求嚷闭，加了一把小鎖，而且請求記錄都是灰色的
而安裝證書后請求則一切正常赖临，請求內(nèi)容也都可以正嘲蹋看到。
3.4 為什么安裝了Fiddler根證書可以看到Https請求內(nèi)容
要解釋這個問題兢榨，就需要了解最開始的Https的驗證原理了嗅榕，回顧一下，先是客戶端把自己支持的加密方式提交到服務(wù)端吵聪，然后服務(wù)端 會返回一個證書
到這一步問題來了凌那，手機未什么要安裝Fiddler的證書呢？
第一 因為Fiddler在客戶端(手機)發(fā)出Https請求時吟逝，充當(dāng)了服務(wù)器的角色案怯，需要返回一個證書給客戶端，
但是Fiddler的證書并不是CA機構(gòu)頒發(fā)的澎办，客戶端一驗證就知道是假的連接肯定就斷了嘲碱，那怎么辦呢？
那就想辦法讓客戶端信任這個服務(wù)端局蚀，于是就在客戶端安裝一個Fiddler的根證書麦锯。
所以只要是通過Fiddler的Https請求，驗證根證書時自然會通過琅绅，因為Fiddler的根證書你已經(jīng)受信了扶欣！
第二 現(xiàn)在只是客戶端(手機)和Fiddler這個偽服務(wù)端的Https驗證通過了，還沒有到真正的服務(wù)端去取數(shù)據(jù)的千扶，此時Fiddler會以客戶端的身份與真正的服務(wù)端再進行一次HTTPS的驗證料祠，最后拿到數(shù)據(jù)后
又以服務(wù)端的身份與客戶端(手機)通信。也就是說在一次請求中數(shù)據(jù)被兩次加解密澎羞，一次是手機到Fiddler髓绽，一次是Fiddler到真正的服務(wù)端。
整個過程 手機----》Fiddler----》 服務(wù)器 Fiddler 即充當(dāng)了服務(wù)端又充當(dāng)了客戶端妆绞，才使得數(shù)據(jù)能夠正常的交互顺呕，這個過程中最重要的一環(huán)就是手機端安裝的 根證書！
四 總結(jié)
寫了這么多括饶，其實也只是把Https的基本流程寫清楚了一部分株茶，這其中每一個步驟深入下去都是一門學(xué)科，而對于我們而言图焰，能清楚其大致運作流程启盛，做到心中有數(shù)據(jù)就算可以了，
Https在目前的網(wǎng)絡(luò)數(shù)據(jù)安全傳輸占據(jù)著重要地位，目前可能也沒有更優(yōu)的方案來代替Https僵闯。另外一定要注意 不要隨便安裝不確定的的根證書笤闯，以免帶來不必要的損失。
寫這篇文章時棍厂，已經(jīng)進入我的春節(jié)假期颗味，而我也已經(jīng)踏上了 回家的火車，大家有疑問可以在評論中回復(fù)牺弹，如有錯誤之處還望大家能指出浦马，以免誤導(dǎo)他人
提前祝大家新年快樂！
