https與TLS/SSL 握手協議、record protocol簡介

時間 2019-11-07

標籤 https tls ssl 握手協議 record protocol 簡介欄目 SSL 简体版

原文原文鏈接

https即 HTTP Secure,HTTP的通訊接口部分用SSL和TLS協議代替，並不是是一種新的協議。html

TLS協議是在SSL3.0的基礎上開發的協議，如下統一用TLS協議來講明前端

http的問題

通訊使用明文，內容被竊聽後存在安全問題
不驗證通訊方的身份，可能遭到假裝
沒法驗證報文的完整性，內容可能遭到篡改

http問題解決思路

明文不行，考慮先加密再傳輸呢？好比我傳輸過程當中使用一種加密算法，在瀏覽器端本身加密和解密，服務端也提供對應的策略來加密和解密。前端代碼基本屬於徹底暴露在全部人的面前，這種本身實現加密和解密的機制都會被別人知曉（祕鑰都會被看到），毫無安全性可言，另外若是每一個人都要這麼搞一套，那就是重複造輪子，時間成本巨大，並且還不必定能作到很安全。linux

固然還包括性能、兼容性等等問題。git

通訊加密祕鑰的安全性問題

祕鑰確定不能硬編碼寫到代碼中，一種解決方式是在每次通訊的過程當中先生成祕鑰，而後的信息再用這個祕鑰進行加密通訊，可是初次傳輸過程當中，仍然會出現明文傳輸祕鑰的問題，一旦被竊聽，後續全部的加密都都白費算法

初次祕鑰傳輸的問題

密碼學中的非對稱加密能夠解決這種場景，非對稱加密擁有兩個祕鑰：公鑰和私鑰。公鑰能夠解開私鑰加密的內容，私鑰能夠解開公鑰加密的內容，那麼只要私鑰不泄密，經過公鑰加密的內容就算被截取，現有的技術手段，是很難經過截取的內容和公鑰獲得原有的內容瀏覽器

公鑰可否信任

若是獲取的公鑰是竊聽人的公鑰，而不是真正服務提供方的公鑰，那麼後續的通訊加密都是使用的竊聽人的公鑰，竊聽人也天然使用本身的私鑰能夠進行解密。所以獲取的公鑰必須是可以信任的。
解決方式是把公鑰放到數字證書中，這個證書由受信任的第三方機構進行頒發，並經過三方的私鑰進行加密。客戶端發起請求首先會向服務端請求三方的證書，客戶端經過三方的公鑰進行解密後，就安全拿到了服務端的公鑰。安全

第三方的公鑰自己則是由瀏覽器和操做系統本身去維護bash

證書被替換的風險

竊聽人也能夠本身去申請個證書，放上本身的公鑰，這樣客戶端一樣也能夠經過三方的公鑰解密，可是解密出來的倒是竊聽人的公鑰。解決方式是使用數字簽名，證書上涵蓋如何根據證書來生成數字簽名的方法，與經過第三方機構的公鑰解析到數字簽名想比較，驗證數字簽名是否同樣，同樣則代表證書確是要訪問的服務的。服務器

好比證書上會寫所表明的網站，校驗的時候加上訪問的網站，就能夠獲得對應的信息session

https的通訊過程

https是創建在TLS協議之上的，它的通訊過程也是以TLS爲基礎。首先進行"握手"，經過以後再進行通訊

TLS握手協議概述

客戶端發送 ClientHello 信息，包含
- 一個隨機數
- 客戶端所支持的協議版本
- 客戶端支持的對稱加密算法
- key_share(代表使用Diffie-Hellman) 或者是 pre_shared_key 或者這二者都有
服務端收到 ClientHello 以後，返回一個 ServerHello 信息，包含：
- 協議的版本，好比TLS1.3
- 一個隨機數
- 使用的加密算法
- 若是決定使用 (EC)DHE key,那麼會包含 "key_share" ;若是使用 PSK key,就會包含 "pre_shared_key"
服務端發送證書

若是客戶端也須要驗證，會再發送一個要證書的請求給客戶端
服務端發送 Server Hello Done 給客戶端，表示Server Hello結束

若是客戶端收到了證書請求，會先發送客戶端證書
客戶端對服務器的證書進行校驗，沒經過則發送警告給使用者，確認是否繼續，經過則返回 Pre master secret（這也是客戶端產生的一個隨機數）,這個 Pre master secret 自己會使用證書中的公鑰進行加密
客戶端發送 Change Cipher Spec 報文，表示後續通訊都會採用雙方商定的加密方法和祕鑰發送。
客戶端會根據以前傳遞的隨機數(2個)以及 Pre master secret 這三個隨機數生成一個master_ key,而後從master_key中提取會話用的祕鑰，用它加密一段內容，涵蓋在這裏客戶端發送Finished報文中，表示客戶端握手階段結束同時也用來校驗加密通道
服務器發送 Change Cipher Spec ，表示服務端也切換到位
服務端拿到公鑰加密後的 Pre master secret 後，經過私鑰解密，使用與客戶端相同的方法，以及步驟7中的3個隨機數，生成會話用的祕鑰，使用這個加密祕鑰發送一個Finished報文給客戶端，驗證加密通道，同時服務端握手結束

客戶端和服務端都能對Finished信息正常解密且消息被驗證，說明通道創建，後續經過上面產生的會話祕鑰對數據進行加密傳輸

非對稱加密與對稱加密的混合使用

握手過程當中，有一個隨機數是使用非對稱祕鑰加密後傳輸的，傳輸成功以後，兩者生成的最後一個會話祕鑰用來通話，這是由於非對稱祕鑰加密和解密處理速度相對對稱祕鑰要慢，所以僅在握手階段使用非對稱祕鑰傳遞，通訊的時候使用握手階段生成的會話祕鑰進行加密

3個隨機數

在握手的階段首先是客戶端隨機生成了一個隨機數，這是明文傳輸的，接着服務端返回了一個隨機數，也是明文傳輸的，最後客戶端使用了一個pre_master_key經過非對稱加密的方式加密傳輸的，爲何用到了3個隨機數再通過計算獲得一個master_key，而後才提取會話key？

首先說一下 pre_master_key,在握手的過程當中，會先約定好到底使用按個 Cipher Suit,好比約定使用RSA或者是(EC)DH suites 【(elliptic curve) Diffie-Hellman】，RSA會發送一個隨機的48字節的 pre_master_key給服務端，可是 (EC)DH卻不是，它產生的可能比48字節要長，也有可能要短，並且分佈並不均衡。雖然經過RSA或者是(EC)DH是保證了pre_master_key自己的保密性，可是根據狀況的不一樣，產生的祕鑰格長度(格式)不一致，而多數狀況下，保持同樣長度的祕鑰會有很好的結果，好比同樣的長度容許將祕鑰交換端與加密端區分開來(打個比方，不能根據長度猜到究竟是用的那個非對稱算法)，某種程度上來講也就具有更好的隨機性。於是最好處理下pre_master_key保證最終輸出的key的一致性

另外從安全性考慮，pre_master_key一旦使用後須要刪掉

而對於產生pre_master_key的算法對於rsa來講每次是隨機的，可是對於dh，包括ecdh算法(不考慮匿名dh和瞬時dh)，就只有hello消息中的兩個隨機數因子了。可是ssl協議自己並不信任每一個主機都能產生徹底隨機的數字，若是隨機數不隨機,被猜出來就不合適了，所以選用3個隨機數來達到更好的隨機效果

隨機帶來的好處一個是當前的通訊不容易被纔出來，另外每次都會不同，就是說就算當前的被纔出來了，歷史上的也沒法解出正確的密文(也叫前向保護)。
最終經過PRF算法計算出一個固定長度爲48字節的master_key，從中再提取出對應的會話key,提取規則以下：

client_write_MAC_key[SecurityParameters.mac_key_length]
      server_write_MAC_key[SecurityParameters.mac_key_length]
      client_write_key[SecurityParameters.enc_key_length]  //會話key
      server_write_key[SecurityParameters.enc_key_length] //會話key
      client_write_IV[SecurityParameters.fixed_iv_length]
      server_write_IV[SecurityParameters.fixed_iv_length]
複製代碼