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

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

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

描述

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

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

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

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

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

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

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

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

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

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

（SSL 和 TLS 協(xié)議）

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

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

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