傳輸層安全性( TLS ) 是一種加密協(xié)議，旨在為計算機網(wǎng)絡(luò)上的通信提供安全保障。該協(xié)議廣泛應(yīng)用于電子郵件、即時消息和IP 語音等應(yīng)用中，但其在保護HTTPS 方面的應(yīng)用最為廣泛。

TLS 協(xié)議的主要目的是通過使用加密技術(shù)（例如使用證書）在兩個或多個通信計算機應(yīng)用程序之間提供安全性，包括隱私性（機密性）、完整性和真實性。它在表示層運行，本身由兩層組成：TLS 記錄和 TLS握手協(xié)議。

與之密切相關(guān)的數(shù)據(jù)報傳輸層安全性( DTLS ) 是一種通信協(xié)議，可為基于數(shù)據(jù)報的應(yīng)用程序提供安全性。在技術(shù)寫作中，當(dāng)“( D ) TLS ”適用于兩個版本時，通常會提到它。

描述

客戶端-服務(wù)器應(yīng)用程序使用 TLS協(xié)議以一種旨在防止竊聽和篡改的方式通過網(wǎng)絡(luò)進行通信。

由于應(yīng)用程序可以使用或不使用 TLS（或 SSL）進行通信，因此客戶端必須請求服務(wù)器建立 TLS 連接。實現(xiàn)此目的的主要方法之一是使用不同的端口號進行 TLS 連接。端口 80 通常用于未加密的HTTP流量，而端口 443 是用于加密HTTPS流量的常用端口。另一種機制是向服務(wù)器發(fā)出特定于協(xié)議的STARTTLS請求，以將連接切換到 TLS - 例如，在使用郵件和新聞協(xié)議時。

一旦客戶端和服務(wù)器同意使用 TLS，它們就會使用握手程序協(xié)商有狀態(tài)連接。協(xié)議使用非對稱密碼握手來建立密碼設(shè)置，以及會話特定的共享密鑰，使用對稱密碼對進一步的通信進行加密。在此握手過程中，客戶端和服務(wù)器就用于建立連接安全性的各種參數(shù)達成一致：

• 當(dāng)客戶端連接到啟用 TLS 的服務(wù)器并請求安全連接時，握手開始，并且客戶端提供支持的密碼套件（密碼和哈希函數(shù)）列表。
• 從此列表中，服務(wù)器選擇它也支持的密碼和哈希函數(shù)，并將該決定通知客戶端。
• 然后，服務(wù)器通常會以數(shù)字證書的形式提供身份證明。證書包含服務(wù)器名稱、保證證書真實性的受信任證書頒發(fā)機構(gòu)(CA) 以及服務(wù)器的公共加密密鑰。
• 客戶端在繼續(xù)之前確認(rèn)證書的有效性。
• 要生成用于安全連接的會話密鑰，客戶端可以執(zhí)行以下操作之一：
  • 使用服務(wù)器的公鑰加密一個隨機數(shù)，并將結(jié)果發(fā)送給服務(wù)器（只有服務(wù)器才能使用其私鑰解密）；然后雙方使用該隨機數(shù)生成唯一的會話密鑰，用于會話期間的后續(xù)數(shù)據(jù)加密和解密，或者
  • 使用Diffie-Hellman 密鑰交換安全地生成一個隨機且唯一的會話密鑰，用于加密和解密，該密鑰具有前向保密的附加屬性：如果服務(wù)器的私鑰將來被泄露，則它不能用于解密當(dāng)前會話，即使該會話被第三方攔截和記錄。

這樣就結(jié)束了握手并開始建立安全連接，該連接使用會話密鑰進行加密和解密，直到連接關(guān)閉。如果上述任何一個步驟失敗，則 TLS 握手失敗，并且不會創(chuàng)建連接。

TLS 和 SSL 不能簡單地歸入OSI 模型或TCP/IP 模型中的任何單個層。TLS 運行于“某些可靠的傳輸協(xié)議（ TCP）之上”，這意味著它位于傳輸層之上。它為更高層提供加密，這通常是表示層的功能。但是，應(yīng)用程序通常將 TLS 用作傳輸層，即使使用 TLS 的應(yīng)用程序必須主動控制發(fā)起 TLS 握手和處理交換的身份驗證證書。

當(dāng)受 TLS 保護時，客戶端和服務(wù)器之間的連接將具有以下所有屬性：?

• 該連接是私密的（或具有保密性），因為使用對稱密鑰算法來加密傳輸?shù)臄?shù)據(jù)。此對稱加密的密鑰是針對每個連接唯一生成的，并且基于在會話開始時協(xié)商的共享密鑰。在傳輸?shù)谝粋€字節(jié)的數(shù)據(jù)之前，服務(wù)器和客戶端會協(xié)商使用哪種加密算法和加密密鑰的詳細(xì)信息（見下文）。共享密鑰的協(xié)商既安全（協(xié)商的密鑰對竊聽者不可用，也無法獲得，即使是將自己置于連接中間的攻擊者也無法獲得），又可靠（沒有攻擊者可以在協(xié)商期間修改通信而不被發(fā)現(xiàn)）。
• 可以使用公鑰加密技術(shù)來驗證通信雙方的身份。此驗證對于服務(wù)器來說是必需的，對于客戶端來說是可選的。
• 該連接是可靠的（或具有完整性），因為傳輸?shù)拿織l消息都包括使用消息認(rèn)證碼進行的消息完整性檢查，以防止在傳輸過程中發(fā)生未檢測到的數(shù)據(jù)丟失或更改。

TLS 支持多種不同的方法來交換密鑰、加密數(shù)據(jù)和驗證消息完整性。因此，TLS 的安全配置涉及許多可配置參數(shù)，并且并非所有選項都提供上面列表中描述的所有隱私相關(guān)屬性。

有人試圖破壞 TLS 試圖提供的通信安全性，并且該協(xié)議已多次修訂以應(yīng)對這些安全威脅。在發(fā)現(xiàn)潛在的安全漏洞后，網(wǎng)絡(luò)瀏覽器開發(fā)人員已多次修改其產(chǎn)品以防御這些漏洞。

（SSL 和 TLS 協(xié)議）

由于 DTLS 協(xié)議數(shù)據(jù)報保留了底層傳輸（應(yīng)用程序）的語義，因此它不會受到與流協(xié)議相關(guān)的延遲的影響，但是應(yīng)用程序必須處理數(shù)據(jù)包重新排序、數(shù)據(jù)報丟失以及大于數(shù)據(jù)報網(wǎng)絡(luò)數(shù)據(jù)包大小的數(shù)據(jù)。由于 DTLS 使用 UDP 或 SCTP 而不是 TCP，因此在用于創(chuàng)建 VPN 隧道時， 它避免了TCP 崩潰問題。

2006 年最初發(fā)布的 DTLS 1.0 版并不是一份獨立文檔。它是作為 TLS 1.1 的一系列增量版本發(fā)布的。[ 11 ]同樣，2012 年發(fā)布的后續(xù) DTLS 是 TLS 1.2 的增量版本。它被賦予了 DTLS 1.2 的版本號以匹配其 TLS 版本。最后，2022 年的 DTLS 1.3 是 TLS 1.3 的增量版本。與之前的兩個版本一樣，DTLS 1.3 旨在提供“與 TLS 1.3 相當(dāng)?shù)陌踩ＷC，但順序保護/不可重放性除外”。

許多VPN 客戶端（包括Cisco AnyConnect 和 InterCloud Fabric、 OpenConnect、ZScaler隧道、F5 Networks Edge VPN Client、和 Citrix Systems NetScaler）都使用 DTLS 來保護 UDP 流量。此外，所有現(xiàn)代 Web 瀏覽器都支持用于WebRTC的 DTLS-SRTP 。