傳輸層安全性協定

傳輸層安全性協定（，縮寫：TLS），前身稱為安全套接層（，縮寫：SSL）是一種安全協議，目的是為網際網路通訊提供安全及資料完整性保障。

網景公司（Netscape）在 1994 年推出首版網頁瀏覽器－網景領航員時，推出 HTTPS 協定，以 SSL 進行加密，這是 SSL 的起源。

IETF 將 SSL 進行標準化，1999 年公佈 TLS 1.0 標準檔案（RFC 2246）。隨後又公佈 TLS 1.1（RFC 4346，2006 年）、TLS 1.2（RFC 5246，2008 年）和 TLS 1.3（RFC 8446，2018 年）。在瀏覽器、電子郵件、即時通訊、VoIP、網路傳真等應用程式中，廣泛使用這個協定。許多網站，如 Google、Facebook、Wikipedia 等也以這個協定來建立安全連線，傳送資料。目前已成為網際網路上保密通訊的工業標準。

SSL 包含記錄層（Record Layer）和傳輸層，記錄層協議確定傳輸層資料的封裝格式。傳輸層安全協議使用 X.509 認證，之後利用非對稱加密演算來對通訊方做身份認證，之後交換對稱密匙作為會話密匙（Session key）。這個會談密匙是用來將通訊兩方交換的資料做加密，保證兩個應用間通訊的保密性和可靠性，使客戶與伺服器應用之間的通訊不被攻擊者竊聽。

概論

TLS 協定採用主從式架構模型，用於在兩個應用程式間透過網路建立起安全的連線，防止在交換資料時受到竊聽及篡改。

TLS 協議的優勢是與高層的應用層協議（如 HTTP、FTP、Telnet 等）無耦合。應用層協議能透明地執行在 TLS 協議之上，由 TLS 協議進行建立加密通道需要的協商和認證。應用層協議傳送的資料在透過 TLS 協議時都會被加密，從而保證通訊的私密性。

TLS 協議是可選的，必須配置客戶端和伺服器才能使用。主要有兩種方式實現這一目標：一個是使用統一的 TLS 協議通訊埠（例如：用於 HTTPS 的埠 443）；另一個是客戶端請求伺服器連線到 TLS 時使用特定的協議機制（例如：電子郵件常用的 STARTTLS）。一旦客戶端和伺服器都同意使用 TLS 協議，他們透過使用一個握手過程協商出一個有狀態的連線以傳輸資料。透過握手，客戶端和伺服器協商各種引數用於建立安全連線：

當客戶端連線到支援 TLS 協議的伺服器要求建立安全連線並列出了受支援的密碼套件（包括加密演算法、雜湊演算法等），握手開始。
伺服器從該列表中決定密碼套件，並通知客戶端。
伺服器發回其數字證書，此證書通常包含伺服器的名稱、受信任的證書頒發機構（CA）和伺服器的公鑰。
客戶端確認其頒發的證書的有效性。
為了生成會話金鑰用於安全連線，客戶端使用伺服器的公鑰加密隨機生成的金鑰，並將其傳送到伺服器，只有伺服器才能使用自己的私鑰解密。
利用隨機數，雙方生成用於加密和解密的對稱金鑰。這就是 TLS 協議的握手，握手完畢後的連線是安全的，直到連線（被）關閉。如果上述任何一個步驟失敗，TLS 握手過程就會失敗，並且斷開所有的連線。

發展歷史

2.1 安全網路程式設計

早期的研究工作，為方便改造原有網路應用程式，在 1993 年已經有了相似的 Berkeley 套接字安全傳輸層 API 方法。

2.2 SSL 1.0、2.0 和 3.0

SSL（Secure Sockets Layer）是網景公司（Netscape）設計的主要用於 Web 的安全傳輸協議，這種協議在 Web 上獲得了廣泛的應用。

基礎演算法由作為網景公司的首席科學家塔希爾・蓋莫爾（Taher Elgamal）編寫，所以他被人稱為 “SSL 之父”。

2014 年 10 月，Google 發布在 SSL 3.0 中發現設計缺陷，建議停用此一協議。攻擊者可以向 TLS 傳送虛假錯誤提示，然後將安全連線強行降級到過時且不安全的 SSL 3.0，然後就可以利用其中的設計漏洞竊取敏感資訊。Google 在自己公司相關產品中陸續禁止回溯相容，強制使用 TLS 協議。Mozilla 也在 11 月 25 日發布的 Firefox 34 中徹底停用了 SSL 3.0。微軟同樣發出了安全通告。

1.0 版本從未公開過，因為存在嚴重的安全漏洞。
2.0 版本在 1995 年 2 月釋出。2011 年，RFC 6176 標準棄用了 SSL 2.0。
3.0 版本在 1996 年釋出，是由網景工程師、Phil Karlton 和 Alan Freier 完全重新設計的。2015 年，RFC 7568 標準棄用了 SSL 3.0。

2.3 TLS 1.0

IETF 將 SSL 標準化，即 RFC 2246 ，並將其稱為 TLS（Transport Layer Security）。

2.4 TLS 1.1

TLS 1.1 在 RFC 4346 中定義，於 2006 年 4 月發表，它是 TLS 1.0 的更新。在此版本中的差異包括：

新增對 CBC 攻擊的保護：
隱式 IV 被替換成一個顯式的 IV。
更改分組密碼模式中的填充錯誤。
支援 IANA 登記的引數。

微軟、Google、蘋果、Mozilla 四家瀏覽器業者在 2020 年終止支援 TLS 1.0 及 1.1 版。2021 年 3 月，RFC 8996 標準棄用了 TLS 1.0 和 TLS 1.1。

2.5 TLS 1.2

TLS 1.2 在 RFC 5246 中定義，於 2008 年 8 月發表。它基於更早的 TLS 1.1 規範。主要區別包括：

增加 SHA-2 密碼雜湊函式。
增加 AEAD 加密演算法，如 GCM 模式。
新增 TLS 擴充套件定義和 AES 密碼組合。所有 TLS 版本在 2011 年 3 月釋出的 RFC 6176 中刪除了對 SSL 的相容，這樣 TLS 會話將永遠無法協商使用的 SSL 2.0 以避免安全問題。

2.6 TLS 1.3

TLS 1.3 在 RFC 8446 中定義，於 2018 年 8 月發表。它與 TLS 1.2 的主要區別包括：

將金鑰交換演算法（如 ECDHE）和認證演算法（如 RSA）從密碼套件中分離出來。
移除 MD5、SHA1 密碼雜湊函式的支援。
請求數字簽名。
整合和半短暫 DH 提議。
替換使用和票據的恢復。
支援 1-RTT 握手並初步支援 0-RTT。
透過在金鑰協商期間使用臨時金鑰來保證完善的前向安全性。
放棄許多不安全或過時特性的支援，包括資料壓縮、重新協商、非 AEAD 加密演算法、靜態 RSA 和靜態 DH 金鑰交換、自定義 DHE 分組、點格式協商、更改密碼本規範的協議、UNIX 時間的 Hello 訊息，以及長度欄位 AD 輸入到 AEAD 密碼本。
較 TLS 1.2 速度更快，效能更好。
移除 RC4 加密演演算法的支援。
整合會話雜湊的使用。
棄用記錄層版本號和凍結數以改進向後相容性。
將一些安全相關的演算法細節從附錄移動到標準，並將 ClientKeyShare 降級到附錄。
支援和 Ed448 數字簽名演算法。
支援 X25519 金鑰交換。
支援帶 Poly1305 訊息驗證碼的 ChaCha20 加密演演算法。
支援加密伺服器名稱指示（Encrypted Server Name Indication, ESNI）。

網路安全服務（NSS）是由 Mozilla 開發並由其網路瀏覽器 Firefox 使用的加密庫，自 2017 年 2 月起便預設啟用 TLS 1.3。隨後 TLS 1.3 被新增到 2017 年 3 月釋出的 Firefox 52.0 中，但它由於某些使用者的相容性問題，預設情況下停用。直到 Firefox 60.0 才正式預設啟用。

Google Chrome 曾在 2017 年短時間將 TLS 1.3 設為預設，然而由於類似等不相容元件而被取消。

wolfSSL 在 2017 年 5 月釋出的 3.11.1 版本中啟用了 TLS 1.3。作為第一款支援 TLS 1.3 部署，wolfSSL 3.11.1 支援 TLS 1.3 Draft 18（現已支援到 Draft 28），同時官方也釋出了一系列關於 TLS 1.2 和 TLS 1.3 效能差距的部落格。

演算法

3.1 金鑰交換和金鑰協商

在客戶端和伺服器開始交換 TLS 所保護的加密資訊之前，他們必須安全地交換或協定加密金鑰和加密資料時要使用的密碼。用於金鑰交換的方法包括：使用 RSA 演算法生成公鑰和私鑰（在 TLS 握手協議中被稱為 TLSRSA）、Diffie-Hellman（在 TLS 握手協議中被稱為 TLSDH）、臨時 Diffie-Hellman（在 TLS 握手協議中被稱為 TLSDHE）、橢圓曲線迪菲 - 赫爾曼（在 TLS 握手協議中被稱為 TLSECDH）、臨時橢圓曲線 Diffie-Hellman（在 TLS 握手協議中被稱為 TLSECDHE）、匿名 Diffie-Hellman（在 TLS 握手協議中被稱為 TLSDHanon）、預共享金鑰（在 TLS 握手協議中被稱為 TLSPSK）和安全遠端密碼（在 TLS 握手協議中被稱為 TLS_SRP）。

TLSDHanon 和 TLSECDHanon 的金鑰協商協議不能驗證伺服器或使用者，因為易受中間人攻擊因此很少使用。只有 TLSDHE 和 TLSECDHE 提供前向保密能力。

在交換過程中使用的公鑰 / 私鑰加密金鑰的長度和在交換協議過程中使用的公鑰證書也各不相同，因而提供的強健性的安全。2013 年 7 月，Google 宣佈向其使用者提供的 TLS 加密將不再使用 1024 位公鑰並切換到至少 2048 位，以提高安全性。

3.2 加密密碼

標註

3.3 資料完整性

訊息鑑別碼（MAC）用於對資料完整性進行認證。HMAC 用於 CBC 模式的塊密碼。AEAD 例如 GCM 模式和 CCM 模式使用 AEAD 內建的訊息鑒別碼，不使用 HMAC。另外，在 TLS 握手過程中需要使用基於 HMAC 的偽隨機函式（PRF），或。

過程

TLS 在網際網路上為 HTTP 等應用程式提供身份驗證、加密、完整性，其基礎是公鑰基礎設施。這是因為公鑰基礎設施普遍商業運營。TLS 協議的設計在某種程度上能夠使主從架構應用程式通訊預防竊聽、干擾和訊息偽造。

TLS 包含幾個基本階段：

對等協商支援的 TLS 版本，和支援的密碼套件。
基於非對稱金鑰的身份認證，通常是基於 PKI 證書的身份認證。伺服器將其 X.509 證書傳送給客戶端，由客戶端驗證伺服器的身份。如果伺服器要驗證客戶端的證書，則客戶端可能會將客戶端證書傳送給伺服器。通常僅驗證伺服器，不驗證客戶端。
基於對稱金鑰的資料加密。客戶端生成隨機數作為對談金鑰，並使用伺服器公鑰（伺服器公鑰在伺服器證書中）加密對談金鑰，最後將已加密的對談金鑰傳送給伺服器。由伺服器的私鑰解密出對談金鑰。最後使用此對談金鑰加密資料。TLS 也可以使用預共用金鑰（PSK）作為對稱金鑰。

在第一階段，客戶端與伺服器協商所用密碼演算法。當前廣泛實現的演算法選擇如下：

身份驗證：RSA、DSA、ECDSA；
金鑰交換：、Diffie-Hellman、ECDH；
對稱金鑰加密：RC4、DES、3DES、AES、ChaCha20 以及 Camellia；
雜湊函式：MD5、SHA 家族。