HTTPS 原理解析

一 前言

　　在說HTTPS以前先說說什麼是HTTP，HTTP就是咱們平時瀏覽網頁時候使用的一種協議。HTTP協議傳輸的數據都是未加密的，也就是明文的，所以使用HTTP協議傳輸隱私信息很是不安全。爲了保證這些隱私數據能加密傳輸，因而網景公司設計了SSL（Secure Sockets Layer）協議用於對HTTP協議傳輸的數據進行加密，從而就誕生了HTTPS。SSL目前的版本是3.0，被IETF（Internet Engineering Task Force）定義在RFC 6101中，以後IETF對SSL 3.0進行了升級，因而出現了TLS（Transport Layer Security） 1.0，定義在RFC 2246。實際上咱們如今的HTTPS都是用的TLS協議，可是因爲SSL出現的時間比較早，而且依舊被如今瀏覽器所支持，所以SSL依然是HTTPS的代名詞，但不管是TLS仍是SSL都是上個世紀的事情，SSL最後一個版本是3.0，從此TLS將會繼承SSL優良血統繼續爲咱們進行加密服務。目前TLS的版本是1.2，定義在RFC 5246中，暫時尚未被普遍的使用 ()

概念可參考百科

http://baike.baidu.com/link?url=M8pBu1j_22f0PW6izvAOCTjhepyRcT320U9LDmjyzb586OYS_aBALxfqIGVca1V-8MJeSl3bTUEOThMuwpamPK

 

 

二  HTTPS 驗證原理

　　Https在真正請求數據前，先會與服務有幾回握手驗證，以證實相互的身份，如下圖爲例

 

 

 

2.1  驗證流程

 

 注：文中所寫的序號與圖不對應但流程是對應的

1 客戶端發起一個https的請求，把自身支持的一系列Cipher Suite（密鑰算法套件，簡稱Cipher）發送給服務端

 

2  服務端，接收到客戶端全部的Cipher後與自身支持的對比，若是不支持則鏈接斷開，反之則會從中選出一種加密算法和HASH算法

   以證書的形式返回給客戶端 證書中還包含了 公鑰 頒證機構 網址 失效日期等等。

 

3 客戶端收到服務端響應後會作如下幾件事

    3.1 驗證證書的合法性    

　　  頒發證書的機構是否合法與是否過時，證書中包含的網站地址是否與正在訪問的地址一致等

        證書驗證經過後，在瀏覽器的地址欄會加上一把小鎖(每家瀏覽器驗證經過後的提示不同 不作討論)

   3.2 生成隨機密碼

        若是證書驗證經過，或者用戶接受了不授信的證書，此時瀏覽器會生成一串隨機數，而後用證書中的公鑰加密。 　　　　　　

    3.3 HASH握手信息

       用最開始約定好的HASH方式，把握手消息取HASH值，  而後用 隨機數加密 「握手消息+握手消息HASH值(簽名)」  並一塊兒發送給服務端

       在這裏之因此要取握手消息的HASH值，主要是把握手消息作一個簽名，用於驗證握手消息在傳輸過程當中沒有被篡改過。

 

4  服務端拿到客戶端傳來的密文，用本身的私鑰來解密握手消息取出隨機數密碼，再用隨機數密碼 解密 握手消息與HASH值，並與傳過來的HASH值作對比確認是否一致。

    而後用隨機密碼加密一段握手消息(握手消息+握手消息的HASH值 )給客戶端

 

5  客戶端用隨機數解密並計算握手消息的HASH，若是與服務端發來的HASH一致，此時握手過程結束，以後全部的通訊數據將由以前瀏覽器生成的隨機密碼並利用對稱加密算法進行加密  

     由於這串密鑰只有客戶端和服務端知道，因此即便中間請求被攔截也是無法解密數據的，以此保證了通訊的安全

  

非對稱加密算法：RSA，DSA/DSS     在客戶端與服務端相互驗證的過程當中用的是對稱加密 
對稱加密算法：AES，RC4，3DES     客戶端與服務端相互驗證經過後，以隨機數做爲密鑰時，就是對稱加密
HASH算法：MD5，SHA1，SHA256  在確認握手消息沒有被篡改時 

 

 

2.2  客戶端如何驗證 證書的合法性？

 

1. 驗證證書是否在有效期內。

　　在服務端面返回的證書中會包含證書的有效期，能夠經過失效日期來驗證 證書是否過時

2. 驗證證書是否被吊銷了。

　　被吊銷後的證書是無效的。驗證吊銷有CRL(證書吊銷列表)和OCSP(在線證書檢查)兩種方法。

證書被吊銷後會被記錄在CRL中，CA會按期發佈CRL。應用程序能夠依靠CRL來檢查證書是否被吊銷了。

CRL有兩個缺點，一是有可能會很大，下載很麻煩。針對這種狀況有增量CRL這種方案。二是有滯後性，就算證書被吊銷了，應用也只能等到發佈最新的CRL後才能知道。

增量CRL也能解決一部分問題，但沒有完全解決。OCSP是在線證書狀態檢查協議。應用按照標準發送一個請求，對某張證書進行查詢，以後服務器返回證書狀態。

OCSP能夠認爲是即時的（實際實現中可能會有必定延遲），因此沒有CRL的缺點。

 

3. 驗證證書是不是上級CA簽發的。

windows中保留了全部受信任的根證書，瀏覽器能夠查看信任的根證書，天然能夠驗證web服務器的證書，

是否是由這些受信任根證書頒發的或者受信任根證書的二級證書機構頒發的（根證書機構可能會授權給底下的中級證書機構，而後由中級證書機構頒發中級證書）

在驗證證書的時候，瀏覽器會調用系統的證書管理器接口對證書路徑中的全部證書一級一級的進行驗證，只有路徑中全部的證書都是受信的，整個驗證的結果纔是受信

 

 

 

 

 

三  手機如何抓取HTTPS的請求數據

 

　　　　當站點由HTTP轉成HTTPS後是更安全了，可是有時候要看線上的請求數據解決問題時卻麻煩了，由於是HTTPS的請求，你就算攔截到了那也是加密的數據，沒有任何意義。

　　那有方法解決嗎？ 答案是確定的！ 接下來就來個實例教程，教你們如何查看HTTPS的請求數據

 

　　首先須要安裝Fiddler 用於攔截請求，和頒發https證書

 

3.1  Fiddler根證書導出

   

  按圖中操做把導出，再將導出的的根證書" FiddlerRoot.cer" 的後輟名 改成"crt"  " FiddlerRoot.crt" 由於手機無法直接安裝 cer格式的證書

 

    

 

3.2  證書安裝

　 在本機把證書移到本機IIS中的某個網站的物理目錄中，而後在手機瀏覽器中訪問該證書的目錄 如："192.168.0.102：8001/FiddlerRoot.crt"

 如圖

 

    

 

　　此時手機會提示按裝根證書，其實安裝一個不受信的根證書是很是危險的，若是你安裝了某些釣魚網站或者有危害的根證書，那隻要是該根證書下的全部證書都會驗證經過，

那隨便一個釣魚網的網站只要安裝了該根證書下的證書，都不會有任何警告提示。

極可能讓用戶有財產損失。因此在安裝根證書時，手機系統會要求你輸入鎖屏密碼，以確保是本人操做。

安裝過程以下

 

　　Fiddler的根證書名字都提示了是不受信的根證書

    

 

安裝完成

 

    

 

 

 

 

3.3  經過Fiddler抓取手機的HTTPS請求

 

       Fiddler默認偵聽的端口是8888,把手機WiFI的Http 代理設爲本機Fiddler的地址以下圖

   這樣手機上全部的請求都會先經過Fiddler，Fiddler再轉發到目標服務器

 

注意： 在家中的路由器中有線與無線一般不在一個網段，會致使Fiddler沒法抓到手機的包，須要手動設置路由，可自行百度

 

    

 

 

 

    代理也設好以後即可以開始抓到Https的請求內容瞭如圖

Https的默認端口號是 「443」能夠看出紅框中的是未裝根證書前的請求，加了一把小鎖，並且請求記錄都是灰色的

而安裝證書後請求則一切正常，請求內容也均可以正常看到。

 

    

 

 

3.4  爲何安裝了Fiddler根證書能夠看到Https請求內容

 

　　要解釋這個問題，就須要瞭解最開始的Https的驗證原理了，回顧一下，先是客戶端把本身支持的加密方式提交到服務端，而後服務端 會返回一個證書

到這一步問題來了，手機未什麼要安裝Fiddler的證書呢？

　　第一 由於Fiddler在客戶端(手機)發出Https請求時，充當了服務器的角色，須要返回一個證書給客戶端，

可是Fiddler的證書並非CA機構頒發的，客戶端一驗證就知道是假的鏈接確定就斷了，那怎麼辦呢？

那就想辦法讓客戶端信任這個服務端，因而就在客戶端安裝一個Fiddler的根證書。

因此只要是經過Fiddler的Https請求，驗證根證書時天然會經過，由於Fiddler的根證書你已經受信了！

 

     第二 如今只是客戶端(手機)和Fiddler這個僞服務端的Https驗證經過了，尚未到真正的服務端去取數據的，此時Fiddler會以客戶端的身份與真正的服務端再進行一次HTTPS的驗證，最後拿到數據後

又以服務端的身份與客戶端(手機)通訊。也就是說在一次請求中數據被兩次加解密，一次是手機到Fiddler，一次是Fiddler到真正的服務端。

 

整個過程  手機----》Fiddler----》 服務器  Fiddler 即充當了服務端又充當了客戶端，才使得數據可以正常的交互，這個過程當中最重要的一環就是手機端安裝的 根證書！

 

 

 

 

四  總結

 

　寫了這麼多，其實也只是把Https的基本流程寫清楚了一部分，這其中每個步驟深刻下去都是一門學科，而對於咱們而言，能清楚其大體運做流程，作到心中有數據就算能夠了，

Https在目前的網絡數據安全傳輸佔據着重要地位，目前可能也沒有更優的方案來代替Https。另一定要注意 不要隨便安裝不肯定的的根證書，以避免帶來沒必要要的損失。

寫這篇文章時，已經進入個人春節假期，而我也已經踏上了 回家的火車，你們有疑問能夠在評論中回覆，若有錯誤之處還望你們能指出，以避免誤導他人

 

提早祝你們新年快樂！

 

 

 

 

若是您以爲本文讓您有所收穫，不妨點下贊，爲個人付出，給一點點回報！

若是您以爲本人也有點意思，不妨點個觀注，你們一塊兒談技術，談人生！

 

 

 如下爲參考資料

http://www.guokr.com/post/114121/  https原理

 

http://www.guokr.com/post/116169/ SSL證書

 

http://www.cnblogs.com/svan/p/5090201.html https工做原理

 

http://blog.csdn.net/clh604/article/details/22179907 Https 原理

 

https://www.zhihu.com/question/37370216/answer/71956414   瀏覽器如何驗證HTTPS證書的合法性？

 

http://blog.csdn.net/wkk2620632/article/details/39433673    公鑰證書cer,pfx

 

http://www.07net01.com/zhishi/640504.html   數字證書資料cer和pfx的區別