SSL/TLS概述

TLS協議分爲兩層

• 底層(Record Layer)
• 上層(ChangeCipherSpec Protocol<20>, Alert Protocol<21>, Handshake Protocol<22>, Application Data Protocol<23>)

Record Layer處於TLS協議最底層，爲TLS協議提供安全可靠的鏈接，爲高層協議提供數據封裝，壓縮，加密等基本功能支持，指定了數據類型，SSL版本以及數據長度(Byte)。因爲TLS版本衆多，客戶端和服務端協商ssl版本時，存在必定的兼容性，具體參照TLS 兼容性問題。好比當客戶端須要兼容ssl老版本服務端時，會把recordLayer的ssl version設置爲{03,XX}(即SSL3.0，TLS 1.0，1.1，1.2)中的任意值，一般是客戶端支持的最低版本。

Handshake Protocol位於Record Layer之上，爲Record Layer的負載，相似TCP層爲IP層負載。HandShake Protocol層用於傳輸加密數據前，客戶端與服務端的握手協商

協商過程

1. 客戶端發出請求（Client Hello）

客戶端向服務端發送的Client Hello報文中包含如下信息：

(1) Version。支持的協議版本，好比TLS 1.2版

(2) Random。一個客戶端生成的隨機數，稍後與服務端產生的隨機數生成對話密鑰(Master Secret)

(3) Cipher Suites。支持的加密方法，好比RSA公鑰加密

Cipher Suite格式：認證算法_密鑰協商交換算法_加密算法_摘要算法（TLS, ECDHE_RSA, AES_256_GCM, SHA256）

(4) Compression Method。支持的壓縮方法，null表示不壓縮

(5) Session ID。若是以前連過該服務端，能夠複用會話，而無需從新進行TLS握手

(6) Extension。server_name(請求的服務端域名)，sinature_algorithms等

2. 服務端迴應

從Server Hello到Server Hello Done，有些服務端是每條單獨發送，有的服務端是合併一塊兒發送。

2.1 Server Hello

(1) Version。服務端確認使用的SSL版本，好比TLS 1.2版本。若是瀏覽器與服務器支持的版本不一致，會進行協商雙方都兼容的版本，若是沒有則關閉鏈接。TLS 兼容性問題

(2) Random。一個服務端生成的隨機數，稍後用於生成對話密鑰

(3) Cipher Suite。服務端從client hello提供的Cipher Suites列表中選取要使用的加密套件

(4) Compression Method。服務端從client hello提供的Compression Method列表中選取要使用的壓縮方法

(5) Session ID。若服務端容許客戶端在之後通訊中重用本次會話，則服務端會爲本次會話分配Session ID

(6) Extension。

2.2 Certificate

服務端在收到客戶端的Client Hello以後，將服務端的X.509證書發送給客戶端，最下層證書在前（用戶證書在前，上級證書在後）。發送的證書是二進制格式，並不是base64以後的格式。

2.3 Server key Exchange(可選)

DHE_DSS,DHE_RSA,DH_anon,
對於使用DHE/ECDHE非對稱密鑰協商算法的SSL握手，將發送該類型握手。
RSA算法不會繼續該握手流程（DH、ECDH也不會發送server key exchange）
客戶端在收到Server Key Exchange後，首先使用服務端證書中的公鑰對簽名進行RSA解密並校驗散列值。若是解密校驗經過，則基於ECDH參數中的Pubkey，經過必定算法算出Pre-Master Secret

2.4 Certificate Request(可選)

對於重要的保密數據，服務端還須要對客戶端進行驗證，服務端能夠向客戶端發出Certificate Request消息，要求客戶端發送證書進行合法性驗證

2.5 Server Hello Done

通知客戶端Server Hello消息結束

3. 客戶端迴應

客戶端收到服務端的Server Hello Done後，首先驗證服務端證書。若是證書不是可信機構頒佈、或者證書中的域名與實際域名不一致、或者證書已通過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通訊。若是證書沒有問題，客戶端就會從證書中取出服務器的公鑰。而後，向服務器發送下面三項信息。

（1） 一個隨機數。該隨機數用服務器公鑰加密，防止被竊聽。

（2） 編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送。

（3） 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面發送的全部內容的hash值，用來供服務器校驗。

上面第一項的隨機數，是整個握手階段出現的第三個隨機數，又稱"pre-master key"。有了它之後，客戶端和服務器就同時有了三個隨機數，接着雙方就用事先商定的加密方法，各自生成本次會話所用的同一把"會話密鑰"。

至於爲何必定要用三個隨機數，來生成"會話密鑰"

3.1. Certificate(可選)

將客戶端證書發送給服務端作合法性校驗

3.2. Client Key Exchange

客戶端密鑰交換並經過隨機數生成Master-Key

3.3. Certificate Verify

客戶端發送這個類型報文須要知足兩個條件：

• 服務端請求了客戶端證書
• 客戶端發送了非0長度的證書

3.4. Change Cipher Spec

告知服務端，客戶端已經切換到協商好的的加密套件（Cipher Suite），表示隨後的信息都將用雙方商定的加密方法和密鑰發送。

3.5 Encrypted Handshake Message

客戶端使用協商好的對稱密鑰進行加密的第一個報文，目的一個是告訴服務端整個握手過程收到了什麼數據，發送了什麼數據，保證中間沒人篡改報文，二是確認密鑰的正確性，若是這個報文加解密校驗成功，那麼對稱密鑰就是正確的

4. 服務端最後迴應

4.1 Change Cipher Spec

編碼改變通知，告知客戶端，服務端已經切換到選定的加密套件（Cipher Suite），表示隨後的信息都將用雙方商定的加密方法和密鑰發送。

4.2 Encrypted Handshake Message

服務端使用協商好的對稱密鑰進行加密的第一個報文，目的一個是告訴客戶端整個握手過程收到了什麼數據，發送了什麼數據，保證中間沒人篡改報文，二是確認密鑰的正確性，若是這個報文加解密校驗成功，那麼對稱密鑰就是正確的

5. Application Data