TLS
傳輸層安全 (Transport Layer Security) 對通過 Internet 發送的資料進行加密，以確保竊聽者和黑客無法看到您傳輸的內容，這對于密碼、信用卡號和個人通信等私人和敏感資訊特別有用，本章解釋了 TLS 是什么、它是如何作業的以及為什么要部署它，
未受保護的資料由應用層提供給TLS
- TLS處理加密（用于發送）、解密（用于接收）和完整性檢查
- TLS將受保護的資料提供給傳輸層
- TLS設計為在TCP之上運行
- 但也可以通過UDP實作
Datagram Transport Layer Security (DTLS)
TLS 是一種加密協議，可為通過 Internet 在應用程式之間發送的資料提供端到端的安全性，用戶最熟悉的是它在安全網路瀏覽中的使用，尤其是在建立安全會話時出現在網路瀏覽器中的掛鎖圖示，但是，它也可以而且確實應該用于其他應用程式，例如電子郵件、檔案傳輸、視頻/音頻會議、即時訊息和 IP 語音，以及 DNS 和 NTP 等 Internet 服務，
TLS握手
TLS握手和SSL握手
SSL 或 Secure Sockets Layer是為HTTP開發的原始安全協議，不久前，SSL 被 TLS 或傳輸層安全性取代，SSL 握手現在稱為 TLS 握手，盡管“SSL”名稱仍在廣泛使用，
什么時候發生TLS握手
每當用戶通過 HTTPS 導航到網站并且瀏覽器首先開始查詢網站的源服務器時，就會發生 TLS 握手，每當任何其他通信使用 HTTPS（包括API 呼叫和基于 HTTPS 的 DNS查詢）時，也會發生 TLS 握手，
TLS 握手發生在通過 TCP 握手打開TCP連接之后，
TLS握手步驟
TLS 握手是由客戶端和服務器交換的一系列資料報或訊息，TLS 握手涉及多個步驟，因為客戶端和服務器交換完成握手所需的資訊并使進一步的對話成為可能，
TLS 握手中的確切步驟將根據所使用的密鑰交換演算法的種類和雙方支持的密碼套件而有所不同，RSA 密鑰交換演算法雖然現在被認為不安全，但在 1.3 之前的 TLS 版本中使用，大致如下：
- 'client hello' 訊息：客戶端通過向服務器發送“hello”訊息來啟動握手，該訊息將包括客戶端支持的 TLS 版本、支持的密碼套件以及稱為“客戶端隨機”的隨機位元組串，
- “Server hello”訊息：作為對客戶端問候訊息的回復，服務器發送一條訊息，其中包含服務器的SSL 證書、服務器選擇的密碼套件和“服務器隨機”，即服務器生成的另一個隨機位元組串，
- 身份驗證：客戶端使用頒發它的證書頒發機構驗證服務器的 SSL 證書，這確認了服務器就是它所說的那個人，并且客戶端正在與域的實際所有者進行互動，
- premaster secret：客戶端再發送一個隨機位元組串，即“premaster secret”，premaster secret 是用公鑰加密的，只能由服務器用私鑰解密，（客戶端從服務器的 SSL 證書中獲取公鑰，）
- 使用的私鑰：服務器解密預主密鑰，
- 創建會話密鑰：客戶端和服務器都從客戶端隨機、服務器隨機和預主密鑰生成會話密鑰，他們應該得到相同的結果，
- 客戶端已準備就緒：客戶端發送一條使用會話密鑰加密的“已完成”訊息，
- 服務器準備就緒：服務器發送使用會話密鑰加密的“已完成”訊息，
- 實作安全對稱加密：握手完成，使用會話密鑰繼續通信，
協議說明
較低層堆疊在TCP之上，因為它是面向連接且可靠的傳輸層協議，這一層基本上由TLS 記錄協議組成，簡而言之，記錄協議首先將高層協議資料分片成 214 位元組或更小的塊；然后可選地壓縮資料，添加訊息驗證碼，最后根據密碼規范（協商時）加密資料，添加 SSL 記錄頭，需要注意的一點是，每個塊都被打包到一個不保留客戶端訊息邊界的結構中，這意味著同一型別的多個訊息可以合并到一個結構中，
下圖描述了構建 SSL 記錄的程序，
較高層堆疊在SSL記錄協議之上，包含四個子協議，這些協議中的每一個都有一個非常特定的目的，并在通信的不同階段使用：
-
握手協議：它允許對等方相互驗證并協商密碼套件和連接的其他引數，SSL 握手協議涉及在客戶端和服務器之間交換的四組訊息（有時稱為航班），每組通常在單獨的 TCP 段中傳輸，下圖顯示了該程序的摘要，其中包含多個步驟并提供可選步驟，請注意，ChangeCipherSpec訊息不屬于該協議，因為它們本身就是一個協議，如下所示，
-
ChangeCipherSpec Protocol：它使之前協商的引數生效，因此通信變得加密，
-
警報協議：用于傳達例外并指示可能危及安全的潛在問題，
-
應用資料協議：它獲取任意資料（通常是應用層資料），并通過安全通道提供給它，
多個訊息可以連接成一個記錄層訊息，但這些訊息必須屬于同一個子協議，因此，這四個協議中的每一個都必須是自定界的（即必須包括其自己的長度欄位），
這里主要講一下握手協議
這是 TLS 中最復雜的子協議，該規范主要關注這一點，因為它處理建立安全連接所需的所有機制，下圖顯示了握手協議訊息的一般結構，TLS 規范中有 10 種握手訊息型別（不包括擴展），因此下面將分別介紹每種的具體格式，
-
HelloRequest：允許服務器重新啟動握手協商，不經常使用，如果一個連接已經建立了足夠長的時間，它的安全性被削弱了（以小時為單位），服務器可以使用這個訊息來強制客戶端重新協商新的會話密鑰，
| | | | Handshake Layer | | - ---+----+----+----+----+ | | | | | 4 | 0 | 0 | 0 | 0 | - ---+----+----+----+----+ / | \ \---------\ / \\ record \ length: 0 length\ type: 0 -
ClientHello：此訊息通常開始 TLS 握手協商，它與客戶端支持的密碼套件串列一起發送，以便服務器選擇最適合的密碼套件（最好是最強的）、壓縮方法串列和擴展串列，通過包含SessionId欄位，它還為客戶端提供了重新啟動先前會話的可能性，
| | | | Handshake Layer | | - ---+----+----+----+----+----+----+------+----+----------+--------+-----------+----------+ | 1 | | | | | |32-bit| |max 32-bit| Cipher |Compression|Extensions| |0x01| | | | 3 | 1 |random| |session Id| Suites | methods | | - ---+----+----+----+----+----+----+------+----+----------+--------+-----------+----------+ / | \ \---------\ \----\ \\ / \ \ \ \ SessionId record \ length SSL/TLS\ length \ version SessionId type: 1 (TLS 1.0 here) length CipherSuites +----+----+----+----+----+----+ | | | | | | | | | | | | | | +----+----+----+----+----+----+ \-----\ \-----\ \----\ \ \\ length cipher Id cipherId Compression methods (no practical implementation uses compression) +----+----+----+ | | | | | 0 | 1 | 0 | +----+----+----+ \-----\\ \\ length: 1 cmp Id: 0 Extensions +----+----+----+----+----+----+----- - - | | | | | | | | | | | | | |...extension data +----+----+----+----+----+----+----- - - \-----\ \-----\ \----\ \ \\ length Extension Extension data Id length -
ServerHello：ServerHello 訊息與 ClientHello 訊息非常相似，不同之處在于它只包含一個 CipherSuite 和一個 Compression 方法，如果它包含一個 SessionId（即 SessionId 長度 > 0），它會向客戶端發出信號以在將來嘗試重用它，
| | | Handshake Layer | | - ---+----+----+----+----+----+----+----------+----+----------+----+----+----+----------+ | 2 | | | | | | 32byte | |max 32byte| | | |Extensions| |0x02| | | | 3 | 1 | random | |session Id| | | | | - ---+----+----+----+----+----+----+----------+----+----------+--------------+----------+ / | \ \---------\ \----\ \ \ \----\\ / \ \ \ \ SessionId \ Compression record \ length SSL/TLS \ (if length > 0) \ method length \ version SessionId\ type: 2 (TLS 1.0 here) length CipherSuite -
證書：此訊息的正文包含一個公鑰證書鏈，證書鏈允許 TLS 支持證書層次結構和 PKI（公鑰基礎設施），
| | | | Handshake Layer | | - ---+----+----+----+----+----+----+----+----+----+----+-----------+---- - - | 11 | | | | | | | | | | | |0x0b| | | | | | | | | |certificate| ...more certificate - ---+----+----+----+----+----+----+----+----+----+----+-----------+---- - - / | \ \---------\ \---------\ \---------\ / \ \ \\ record \ length Certificate Certificate length \ chain length type: 11 length -
ServerKeyExchange：此訊息攜帶客戶端需要從服務器獲得的密鑰交換演算法引數，以便之后對稱加密作業，它是可選的，因為并非所有密鑰交換都需要服務器顯式發送此訊息，實際上，在大多數情況下，證書訊息足以讓客戶端安全地與服務器通信預主密鑰，這些引數的格式完全取決于所選的 CipherSuite，它先前已由服務器通過 ServerHello 訊息設定，
| | | Handshake Layer | | - ---+----+----+----+----+----------------+ | 12 | | | | algorithm | |0x0c| | | | parameters | - ---+----+----+----+----+----------------+ / | \ \---------\ / \\ record \ length length\ type: 12 -
CertificateRequest：當服務器需要客戶端身份認證時使用，在 Web 服務器中不常用，但在某些情況下非常重要，該訊息不僅要求客戶端提供證書，它還告訴哪些證書型別是可接受的，此外，它還指示哪些證書頒發機構被認為是值得信賴的，
| | | | Handshake Layer | | - ---+----+----+----+----+----+----+---- - - --+----+----+----+----+-----------+-- - | 13 | | | | | | | | | | | C.A. | |0x0d| | | | | | | | | | |unique name| - ---+----+----+----+----+----+----+---- - - --+----+----+----+----+-----------+-- - / | \ \---------\ \ \ \----\ \-----\ / \ \ \ Certificate \\ record \ length \ Type 1 Id Certificate\ length \ Certificate Authorities length\ type: 13 Types length Certificate Authority length -
ServerHelloDone：此訊息完成握手協商的服務器部分，它不攜帶任何附加資訊，
| | | | Handshake Layer | | - ---+----+----+----+----+ | 14 | | | | 4 |0x0e| 0 | 0 | 0 | - ---+----+----+----+----+ / | \ \---------\ / \\ record \ length: 0 length\ type: 14 -
ClientKeyExchange：它為服務器提供必要的資料來生成對稱加密的密鑰，訊息格式與 ServerKeyExchange 非常相似，因為它主要取決于服務器選擇的密鑰交換演算法，
| | | | Handshake Layer | | - ---+----+----+----+----+----------------+ | 16 | | | | algorithm | |0x10| | | | parameters | - ---+----+----+----+----+----------------+ / | \ \---------\ / \\ record \ length length\ type: 16驗證服務器的證書后，客戶端使用服務器的公鑰加密pre_master_secret,一旦計算了主密鑰，就應該從記憶體中洗掉pre_master_secret
此圖假定我們使用AES_256_CBC_SHA，因此每個密鑰都是32位元組長，
主密鑰的長度取決于密鑰交換演算法，
通信是雙向的，因此兩個方向都使用單獨的鍵：
client_write密鑰用于保護從客戶端到服務器的資料；server_write密鑰用于保護從服務器到客戶端的資料
-
CertificateVerify：客戶端使用此訊息來證明服務器擁有與其公鑰證書對應的私鑰，該訊息包含由客戶端數字簽名的散列資訊，如果服務器向客戶端發出 CertificateRequest，則它是必需的，因此它必須發送需要驗證的證書，再一次，資訊的確切大小和結構取決于商定的演算法，在所有情況下，作為散列函式輸入的資訊都是相同的，
| | | | Handshake Layer | | - ---+----+----+----+----+----------+ | 15 | | | | signed | |0x0f| | | | hash | - ---+----+----+----+----+----------+ / | \ \---------\ / \\ record \ length length\ type: 15 -
Finished：此訊息表明 TLS 協商已完成并且 CipherSuite 已激活，它應該已經加密發送，因為協商成功完成，所以必須在此之前發送 ChangeCipherSpec 協議訊息以激活加密，Finished 訊息包含所有先前握手訊息組合的哈希，后跟一個特殊數字標識服務器/客戶端角色、主密鑰和填充，生成的散列與 CertificateVerify 散列不同，因為有更多的握手訊息，
| | | | Handshake Layer | | - ---+----+----+----+----+----------+ | 20 | | | | signed | |0x14| | | | hash | - ---+----+----+----+----+----------+ / | \ \---------\ / \\ record \ length length\ type: 20
演示鏈接
TLS 資料傳輸
握手和資料包都在TLS記錄中，
區別是什么？
- 資料包沒有握手頭，直接所有資料，
- 整個有效載荷也被加密，?ChangeCipherSpec之后的所有資料包都將被加密（僅記錄頭為純文本）
用TLS記錄協議發送資料流程：
-
碎片化處理
純文本到TLS純文本：內容型別、協議版本、長度和片段，
內容型別：change_cipher_spec、alert、handshake、application_data， -
壓縮（可選）
TLSPlaintext到TLSCompressized:內容型別（與以前相同）、協議版本（與以前一樣）、長度（不同的值）和片段（壓縮形式），
-
MAC+加密：（ChangeCipherSpec之后）
TLS壓縮為TLSCiphertext:內容型別、協議版本、長度（不同）、片段+MAC+填充+填充長度（加密）
-
生成的MAC（例如，由客戶端生成）:
HMAC_hash(client_write_MAC_key, client_write_seq_num + TLSCompressed.type + TLSCompressed.version
+ TLSCompressed.length + TLSCompressed.fragment)
-
MAC包括一個序列號，以便可以檢測到丟失的、額外的或重復的訊息，
-
TLSCiphertext是對整個TLSCompressified進行加密的結果和MAC:
- 使用client_write_key和client_write_IV進行塊密碼加密
警告協議
如果連接或安全變得不穩定、受損或發生嚴重錯誤，警報協議允許發送方通知對方，這些訊息有兩種型別，警告或致命，警告訊息表明會話不穩定，并允許接收者確定是否應繼續會話，
一條致命訊息告訴收件人連接已被破壞或發生了嚴重錯誤，發送者在發送訊息后應關閉連接，警報協議還包含有關導致特定連接問題的原因的資訊，這可能包括解密失敗、未知的證書頒發機構、非法引數等等
警報協議也相當簡單，它定義了兩個欄位：嚴重性級別和警報描述，第一個欄位指示警報的嚴重性（1 表示警告，2 表示致命），而第二個欄位編碼確切的條件，支持的警報描述取決于 SSL/TLS 版本，
|
|
|
Record Layer | Alert Layer
|
|
+----+----+----+----+----+----+----+
| 21 | | | | | | |
|0x15| | | 0 | 2 | | |
+----+----+----+----+----+----+----+
/ / |
/ / |
type: 21 / |
/
/
length: 2
Alert severity dec hex
----------------------------------------
WARNING 1 0x01
FATAL 2 0x02
TLS 1.0 Alert descriptions dec hex
----------------------------------------
CLOSE_NOTIFY 0 0x00
UNEXPECTED_MESSAGE 10 0x0A
BAD_RECORD_MAC 20 0x14
DECRYPTION_FAILED 21 0x15
RECORD_OVERFLOW 22 0x16
DECOMPRESSION_FAILURE 30 0x1E
HANDSHAKE_FAILURE 40 0x28
NO_CERTIFICATE 41 0x29
BAD_CERTIFICATE 42 0x2A
UNSUPPORTED_CERTIFICATE 43 0x2B
CERTIFICATE_REVOKED 44 0x2C
CERTIFICATE_EXPIRED 45 0x2D
CERTIFICATE_UNKNOWN 46 0x2E
ILLEGAL_PARAMETER 47 0x2F
UNKNOWN_CA 48 0x30
ACCESS_DENIED 49 0x31
DECODE_ERROR 50 0x32
DECRYPT_ERROR 51 0x33
EXPORT_RESTRICTION 60 0x3C
PROTOCOL_VERSION 70 0x46
INSUFFICIENT_SECURITY 71 0x47
INTERNAL_ERROR 80 0x50
USER_CANCELLED 90 0x5A
NO_RENEGOTIATION 100 0x64
記錄格式協議
TLS 記錄標頭包含三個欄位，這些欄位是允許在其上構建更高層所必需的：
- 位元組 0：TLS 記錄型別
- 位元組 1-2：TLS 版本（主要/次要）
- 位元組 3-4：記錄中的資料長度（不包括標頭本身），支持的最大值為 16384 (16K)，
record type (1 byte)
/
/ version (1 byte major, 1 byte minor)
/ /
/ / length (2 bytes)
/ / /
+----+----+----+----+----+
| | | | | |
| | | | | | TLS Record header
+----+----+----+----+----+
Record Type Values dec hex
-------------------------------------
CHANGE_CIPHER_SPEC 20 0x14
ALERT 21 0x15
HANDSHAKE 22 0x16
APPLICATION_DATA 23 0x17
Version Values dec hex
-------------------------------------
SSL 3.0 3,0 0x0300
TLS 1.0 3,1 0x0301
TLS 1.1 3,2 0x0302
TLS 1.2 3,3 0x0303
TLS會話和連接
TLS協議是一種非對稱協議，用于區分客戶端和服務器，
- TLS會話是有狀態的，
- 它是TLS握手協議，用于創建和協調客戶端和服務器的狀態
區分兩個對等體之間的會話和連接：
最初，兩個對等方在它們之間建立TLS會話（六個狀態，主要是CipherSpec和主密鑰），然后在它們之間創建TLS連接（另外十個狀態，大部分是密鑰和IV），
稍后，兩個對等方可以從同一會話建立另一個連接，即會話重用（另一組密鑰和IV）
TLS六個會話狀態：
- 會話識別符號：服務器選擇用于標識活動會話狀態的任意位元組序列，
- 對等認證（可選）：對等方的X509.v3證書
- 壓縮方法：用于在加密之前壓縮資料的演算法
- CipherSpec：指定批量資料加密演算法和MAC演算法，還定義加密屬性，例如哈希大小
- 主密鑰：客戶端和服務器之間共享的48位元組密鑰
- 是否可恢復：一個標志，指示會話是否可用于啟動新連接（允許會話重用？）
TLS五個連接狀態
服務器和客戶端隨機：服務器和客戶端為每個連接選擇的位元組序列
服務器（客戶端）寫入MAC機密：在對服務器（客戶機）寫入的資料進行MAC操作時使用的機密
服務器（客戶機）寫入密鑰：由服務器（客戶）加密并由客戶機（服務器）解密的資料的
批量密碼密鑰，服務器（客戶端）寫入IV:用于密碼塊鏈接（CBC）
服務器（客戶端）寫入序列號：各方為每個連接的傳輸/接收訊息維護單獨的序列號，
本文來自博客園，作者：ivanlee717，轉載請注明原文鏈接：https://www.cnblogs.com/ivanlee717/p/16807760.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/518553.html
標籤：訊息安全
下一篇：TLS握手以及協議詳解