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).金鑰使用這裡的「 資料加密通訊過程 」 不好理解，分片，壓縮，計算mac，可以理解。client encryption key 是什麼？ 是不是就是 cipher suite 中 確認過的 對稱加密演算法 的金鑰嗎 ? 不應該就是 協商金鑰嗎？ 不應該就是 master secret 嗎？ server encryption key 就更加不好理解了， 通訊建立ok了後，就進入了 對稱加密的 通道了吧！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 用於資料的完整性校驗;
HTTPS加密流程
1 客戶端發起https請求首先向服務端傳送客戶端ssl tls協議版本號 支援的加密演算法種類 如 rsa加密演算法，des對稱加密演算法，sha1摘要演算法 產生隨機數等資訊 2 服務端向瀏覽器回傳 ssl tls 協議版本號 選擇一種客戶端瀏覽器支援的加密演算法和hash演算法 隨機數 服務端...
HTTPS 實現流程
https協議其實就是http over tsl，基礎的http通訊是明文的，有三大風險 資訊被竊聽，資訊被篡改，身份的冒充。tsl協議就是為防範這些風險存在的。tsl使用非對稱加密保護下的對稱加密在保證了通訊效率的同時防止竊聽，使用證書體系防止資訊篡改和身份冒認。注意 tsl協議握手階段的通訊是明...
HTTPS通訊流程
https的通訊流程 1 客戶端向伺服器發起ssl通訊，報文中包含客戶端支援的ssl的指定版本，加密元件列表 所使用的加密演算法及金鑰長度 2 伺服器的響應報文中，包含ssl版本以及加密元件，伺服器的加密元件內容是從客戶端發來的加密元件列表中篩選出來的，伺服器還會發乙個公開金鑰並且帶有公鑰證書 3 ...