HTTPS 基本流程2

 

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  在確認握手消息沒有被篡改時 

 

==================================================================================

每一個人都講得不太同樣，雖然基本上是相同的。

第一二步的時候，是須要隨機數的，這裏沒有寫出來。

關於  3.3 HASH握手信息 就更加迷惑了。

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

       

首先，握手消息是什麼？看其餘的文章，通常就是pre-master （又稱爲premaster、premaster secret ？），把premaster 按照第一次握手肯定的hash算法 取hash，而後 「 隨機數加密 」， 這裏又是一個 隨機數？ 搞不懂了！ 這個隨機數是如何產生的？ 內容是？ 我總以爲這裏多是寫錯了， 這裏應該是 用服務器公鑰加密 " 握手消息+握手消息HASH值 "。 

可是有的書上又說用 " 服務器公鑰加密 premaster （也就是握手消息） "， 這裏是沒有用公鑰加密 premaster 的hash 的 。 若是這樣作，也沒有什麼，但這樣又會衍生一點問題： 假設服務端拿到這個加密後的 「 握手消息+握手消息HASH值 」， 用私鑰解密， 那麼獲得 「 premaster握手消息+premaster握手消息HASH值 」， 那麼我須要把premaster 取出來， 可是如今 premaster 和 premaster 的hash 混在了一塊， 如何分離？ 除非 中間有個固定的分隔符？其實這樣想是錯的， premaster 並不會發送， 永遠不會發送。

「 並一塊兒發送給服務端 」 這裏的並一塊兒，是指哪些內容？ 想了想， 應該是這樣的： 先發送 premaster  公鑰加密值， 再發送premaster 的hash 的 公鑰加密值。分別發送，（應該是分兩次發送， 否則， 又須要一個 分隔符了， 比較麻煩， 看到其餘資料的介紹也是 分屢次 ）。 因此說呢，這裏的 「 並一塊兒 」  有至關大的 迷惑，容易產生誤解。。

 

可是呢，  premaster 的hash 的 公鑰加密值， 有必要發送嗎？ 發送是保險起見， 爲了驗證premaster  是否已經被更改， 由於服務器的公鑰是 任何人均可見的，若是流量被middleman 劫持，隨便加密了一個 隨機數，而後 用公鑰加密，而後發送過來， 服務器端無法肯定它是否已經發生 改變，而後把middleman 當作最開始通訊的客戶端，而後和middleman 通訊，這樣就出問題了。 由於http是無狀態的， 客戶端-服務端 創建通訊過程有不少步驟，每個步驟均可能 被劫持，所以， 在沒有徹底創建通訊、信道 以前，每個步驟都要驗證。因此後面這一句是 很是正確的：

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

握手消息的HASH值 是必不可少須要發送給服務端的。可是我又看到有資料這樣描述：

encrypted_handshake_message，結合以前全部通訊參數的 hash 值與其它相關信息生成一段數據，採用協商密鑰 session secret 與算法進行加密，而後發送給服務器用於數據與握手驗證

這樣的描述，也十分的不清晰， " 結合以前全部通訊參數的 hash 值 " 究竟是什麼？ 莫非就是前面說的 premaster 的hash ？ 「 與其它相關信息生成一段數據 」 具體什麼數據沒關係，由於 咱們僅僅是用它作比較， 以驗證 協商密鑰 session secret （我以爲就是 master secret） 的正確。 問題是 這裏的 「 與 」， 怎麼理解， 是直接拼在一塊兒嗎？ 這樣的話，premaster 的hash 和 「 一段數據 」 中間是否是又須要一個分隔符？

 

 random client 和 random server, Pre-master, 容易理解， Master secret 還好理解, key material, 又是什麼？

 

    Key 通過12輪迭代計算會獲取到12個 hash 值，分組成爲6個元素，列表以下：

 

 

 居然出現了 12個 hash 值 ，我看通常資料根本沒有題這麼詳細。 是真的有嗎？ 

(2).密鑰使用 

    Key 通過12輪迭代計算會獲取到12個 hash 值，分組成爲6個元素，列表以下：

  (a) mac key、encryption key 和 IV 是一組加密元素，分別被客戶端和服務器使用，可是這兩組元素都被兩邊同時獲取;

    (b) 客戶端使用 client 組元素加密數據，服務器使用 client 元素解密;服務器使用 server 元素加密，client 使用 server 元素解密;
    (c) 雙向通訊的不一樣方向使用的密鑰不一樣，破解通訊至少須要破解兩次;
    (d) encryption key 用於對稱加密數據;
    (e) IV 做爲不少加密算法的初始化向量使用，具體能夠研究對稱加密算法;
    (f) Mac key 用於數據的完整性校驗;

（3）.數據加密通訊過程
    (a) 對應用層數據進行分片成合適的 block;
    (b) 爲分片數據編號，防止重放攻擊;
    (c) 使用協商的壓縮算法壓縮數據;
    (d) 計算 MAC 值和壓縮數據組成傳輸數據;
    (e) 使用 client encryption key 加密數據，發送給服務器 server;
    (f) server 收到數據以後使用 client encrytion key 解密，校驗數據，解壓縮數據，從新組裝。
注：MAC值的計算包括兩個 Hash 值：client Mac key 和 Hash (編號、包類型、長度、壓縮數據)。
--------------------- 
做者：hherima 
來源：CSDN 
原文：https://blog.csdn.net/hherima/article/details/52469674 
版權聲明：本文爲博主原創文章，轉載請附上博文連接！

這裏的「 數據加密通訊過程 」 很差理解，分片，壓縮，計算MAC，能夠理解。client encryption key 是什麼？  是否是就是  cipher suite 中 確認過的  對稱加密算法 的密鑰嗎 ?  不該該就是 協商密鑰嗎？  不該該就是 master secret 嗎？  server encryption key 就更加很差理解了， 通訊創建ok了後，就進入了 對稱加密的 通道了吧！