傳輸層安全性協定

傳輸層安全性協定（Transport Layer Security，縮寫：TLS），前身稱為安全套接層（Secure Sockets Layer，縮寫：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握手過程就會失敗，並且斷開所有的連接。

## 發展歷史

協議｜發布時間｜狀態

SSL 1.0｜未公佈｜未公佈

SSL 2.0｜1995年｜已於2011年棄用

SSL 3.0｜1996年｜已於2015年棄用

TLS 1.0｜1999年｜於2021年棄用

TLS 1.1｜2006年｜於2021年棄用

TLS 1.2｜2008年

TLS 1.3｜2018年

### 安全網路編程

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

### 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。

### TLS 1.0

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

### TLS 1.1

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

- 隱式IV被替換成一個顯式的IV。
- 更改分組密碼模式中的填充錯誤。
- 支持IANA登記的參數。

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

### 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以避免安全問題。

### TLS 1.3

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

- 將密鑰交換演算法（如ECDHE）和認證演算法（如RSA）從密碼套件中分離出來。
- 移除MD5、SHA1密碼雜湊函數的支持。
- 請求數字簽名。
- 集成HKDF和半短暫DH提議。
- 替換使用TLS-PSK和票據的恢復。
- 支持1-RTT握手並初步支持0-RTT。
- 通過在密鑰協商期間使用臨時密鑰來保證完善的前向安全性。
- 放棄許多不安全或過時特性的支持，包括數據壓縮、重新協商、非AEAD加密演算法、靜態RSA和靜態DH密鑰交換、自定義DHE分組、點格式協商、更改密碼本規範的協議、UNIX時間的Hello消息，以及長度欄位AD輸入到AEAD密碼本。
- 較TLS 1.2速度更快，效能更好。
- 移除RC4加密演演算法的支援。
- 集成會話散列的使用。
- 棄用記錄層版本號和凍結數以改進向後兼容性。
- 將一些安全相關的演算法細節從附錄移動到標準，並將ClientKeyShare降級到附錄。
- 支援Ed25519和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設為默認，然而由於類似Blue Coat Systems等不兼容組件而被取消。

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性能差距的部落格。

## 演算法

### 密鑰交換和密鑰協商

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

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

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

演算法｜SSL 2.0｜SSL 3.0｜TLS 1.0｜TLS 1.1｜TLS 1.2｜TLS 1.3｜狀態

RSA｜是｜是｜是｜是｜是｜否｜RFC中TLS 1.2的定義

DH-RSA｜否｜是｜是｜是｜是｜否

DHE-RSA（具有前向安全性）｜否｜是｜是｜是｜是｜是

ECDH-RSA｜否｜否｜是｜是｜是｜否

ECDHE-RSA（具有前向安全性）｜否｜否｜是｜是｜是｜是

DH-DSS｜否｜是｜是｜是｜是｜否

DHE-DSS（具有前向安全性）｜否｜是｜是｜是｜是｜否

DHE-ECDSA (具有前向安全性)｜否｜否｜否｜否｜否｜是

ECDH-ECDSA｜否｜否｜是｜是｜是｜否

ECDHE-ECDSA（具有前向安全性）｜否｜否｜是｜是｜是｜是

DHE-EdDSA (具有前向安全性)｜否｜否｜否｜否｜否｜是

ECDH-EdDSA｜否｜否｜是｜是｜是｜否

ECDHE-EdDSA (具有前向安全性)｜否｜否｜是｜是｜是｜是

PSK｜否｜否｜是｜是｜是｜是

RSA-PSK｜否｜否｜是｜是｜是｜否

DHE-PSK（具有前向安全性）｜否｜否｜是｜是｜是｜是

ECDHE-PSK（具有前向安全性）｜否｜否｜是｜是｜是｜是

SRP｜否｜否｜是｜是｜是｜否

SRP-DSS｜否｜否｜是｜是｜是｜否

SRP-RSA｜否｜否｜是｜是｜是｜否

Kerberos｜否｜否｜是｜是｜是｜?

DH-ANON（不安全）｜否｜是｜是｜是｜是｜否

ECDH-ANON（不安全）｜否｜否｜是｜是｜是｜否

GOST R 34.10-94 / 34.10-2001｜否｜否｜是｜是｜是｜在RFC草案中提出

GOST R 34.10-2012｜否｜否｜否｜否｜是｜是｜中TLS 1.2、1.3的定義

### 加密密碼

密碼｜協議版本｜狀態

類型｜演算法｜長度（bits）｜SSL 2.0｜SSL 3.0｜TLS 1.0｜TLS 1.1｜TLS 1.2｜TLS 1.3

分組密碼及其加密方式｜AES GCM｜256, 128｜不適用｜不適用｜不適用｜不適用｜安全｜安全｜RFC中TLS 1.2的定義

AES CCM｜不適用｜不適用｜不適用｜不適用｜安全｜安全

AES CBC｜不適用｜不安全｜依賴於後期加入的措施｜依賴於後期加入的措施｜依賴於後期加入的措施｜不適用

Camellia GCM｜256, 128｜不適用｜不適用｜不適用｜不適用｜安全｜不適用

Camellia CBC｜不適用｜不安全｜依賴於後期加入的措施｜依賴於後期加入的措施｜依賴於後期加入的措施｜不適用

ARIA加密演算法 GCM｜256, 128｜不適用｜不適用｜不適用｜不適用｜安全｜不適用

ARIA加密演算法 CBC｜不適用｜不適用｜依賴於後期加入的措施｜依賴於後期加入的措施｜依賴於後期加入的措施｜不適用

SEED加密演算法 CBC｜128｜不適用｜不安全｜依賴於後期加入的措施｜依賴於後期加入的措施｜依賴於後期加入的措施｜不適用

3DES EDE CBCSweet32攻擊能破解分組長度為64位元的區塊加密法。｜112儘各3DES的金鑰長度為168位元, 它的有效安全性僅為112位元，遠低於建議的最少128位元。｜不安全｜不安全｜不安全｜不安全｜不安全｜不適用

GOST加密演算法 CNT｜256｜不適用｜不適用｜不安全｜不安全｜不安全｜不適用｜定義於

GOST加密演算法 CTR｜256｜不適用｜不適用｜不安全｜不安全｜不安全｜不適用｜定義於

GOST R 34.12-2015 Kuznyechik CTR｜256｜不適用｜不適用｜不適用｜不適用｜安全｜不適用｜定義於

GOST加密演算法 MGM｜256｜不適用｜不適用｜不適用｜不適用｜不適用｜不安全｜定義於

GOST R 34.12-2015 Kuznyechik MGM｜256｜不適用｜不適用｜不適用｜不適用｜不適用｜安全｜定義於

IDEA CBCTLS 1.2已移除IDEA和DES。｜128｜不安全｜不安全｜不安全｜不安全｜不適用｜不適用｜從TLS 1.2標準中移除

DES CBC｜56｜不安全｜不安全｜不安全｜不安全｜不適用｜不適用

40｜不安全｜不安全｜不安全｜不適用｜不適用｜不適用｜在TLS 1.1及之後版本禁止

RC2 CBC｜40｜不安全｜不安全｜不安全｜不適用｜不適用｜不適用

流加密｜ChaCha20-Poly1305｜256｜不適用｜不適用｜不適用｜不適用｜安全｜安全｜RFC中TLS 1.2的定義

RC4｜128｜不安全｜不安全｜不安全｜不安全｜不安全｜不適用｜由定義所有版本TLS禁止

40｜不安全｜不安全｜不安全｜不適用｜不適用｜不適用

Null｜不安全｜不安全｜不安全｜不安全｜不安全｜不適用｜RFC中TLS 1.2的定義

標註

### 數據完整性

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

演算法｜SSL 2.0｜SSL 3.0｜TLS 1.0｜TLS 1.1｜TLS 1.2｜TLS 1.3｜狀態

HMAC-MD5｜是｜是｜是｜是｜是｜否｜RFC中TLS 1.2的定義

HMAC-SHA1｜否｜是｜是｜是｜是｜否

HMAC-SHA256/384｜否｜否｜否｜否｜是｜否

AEAD｜否｜否｜否｜否｜是｜是

GOST 28147-89 IMIT｜否｜否｜否｜否｜是｜否｜中TLS 1.2的定義

GOST R 34.11-94｜否｜否｜否｜否｜是｜//datatracker.ietf.org/doc/html/draft-chudov-cryptopro-cptls-04 RFC Draft中TLS 1.2的定義

GOST R 34.12-2015 AEAD｜否｜否｜否｜否｜否｜是｜中TLS 1.3的定義

## 過程

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

TLS包含幾個基本階段：

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

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

- 身份驗證：RSA、DSA、ECDSA。
- 密鑰交換：PSK、Diffie-Hellman、ECDH。
- 對稱密鑰加密：RC4、DES、3DES、AES、ChaCha20以及Camellia。
- 散列函數：MD5、SHA家族。

## 外部連結

- SSL/TLS/WTLS原理
- SSL配置指南
- SSL狀態檢查、格式轉換、漏洞掃描工具