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了後，就進入了 對稱加密的 通道了吧！