傳輸層安全性協定（，縮寫：），前身稱為安全套接層（，縮寫：）是一種安全協議，目的是為網際網路通訊提供安全及資料完整性保障。 網景公司在 1994 年推出首版網頁瀏覽器－網景領航員時，推出 HTTPS 協定，以 SSL 進行加密，這是 SSL 的起源。 IETF 將 SSL 進行標準化，1999 年公佈 TLS 10 標準檔案（RFC 2246）。隨後又公佈 TLS 11（RFC 4346，2006 年）、TLS 12（RFC 5246，2008 年）和 TLS 13（RFC 8446，2018 年）。在瀏覽器、電子郵件、即時通訊、VoIP、網路傳真等應用程式中，廣泛使用這個協定。許多網站，如 Google、Facebook、Wikipedia 等也以這個協定來建立安全連線，傳送資料。目前已成為網際網路上保密通訊的工業標準。 SSL 包含記錄層（Record Layer）和傳輸層，記錄層協議確定傳輸層資料的封裝格式。傳輸層安全協議使用 X509 認證，之後利用非對稱加密演算來對通訊方做身份認證，之後交換對稱密匙作為會話密匙（Session key）。這個會談密匙是用來將通訊兩方交換的資料做加密，保證兩個應用間通訊的保密性和可靠性，使客戶與伺服器應用之間的通訊不被攻擊者竊聽。 概論 TLS 協定採用主從式架構模型，用於在兩個應用程式間透過網路建立起安全的連線，防止在交換資料時受到竊聽及篡改。 TLS 協議的優勢是與高層的應用層協議（如 HTTP、FTP、Telnet 等）無耦合。應用層協議能透明地執行在 TLS 協議之上，由 TLS 協議進行建立加密通道需要的協商和認證。應用層協議傳送的資料在透過 TLS 協議時都會被加密，從而保證通訊的私密性。 TLS 協議是可選的，必須配置客戶端和伺服器才能使用。主要有兩種方式實現這一目標：一個是使用統一的 TLS 協議通訊埠（例如：用於 HTTPS 的埠 443）；另一個是客戶端請求伺服器連線到 TLS 時使用特定的協議機制（例如：電子郵件常用的 STARTTLS）。一旦客戶端和伺服器都同意使用 TLS 協議，他們透過使用一個握手過程協商出一個有狀態的連線以傳輸資料 SSLTLS in Detail Microsoft TechNet Updated July 31 2003。透過握手，客戶端和伺服器協商各種引數用於建立安全連線： 當客戶端連線到支援 TLS 協議的伺服器要求建立安全連線並列出了受支援的密碼套件（包括加密演算法、雜湊演算法等），握手開始。 伺服器從該列表中決定密碼套件，並通知客戶端。 伺服器發回其數字證書，此證書通常包含伺服器的名稱、受信任的證書頒發機構（CA）和伺服器的公鑰。 客戶端確認其頒發的證書的有效性。 為了生成會話金鑰用於安全連線，客戶端使用伺服器的公鑰加密隨機生成的金鑰，並將其傳送到伺服器，只有伺服器才能使用自己的私鑰解密。 利用隨機數，雙方生成用於加密和解密的對稱金鑰。這就是 TLS 協議的握手，握手完畢後的連線是安全的，直到連線（被）關閉。如果上述任何一個步驟失敗，TLS 握手過程就會失敗，並且斷開所有的連線。 發展歷史 協議 發布時間 狀態 SSL 10 SSL 20 1995 年 已於 2011 年棄用 SSL 30 1996 年 已於 2015 年棄用 TLS 10 1999 年 於 2021 年棄用 TLS 11 2006 年 於 2021 年棄用 TLS 12 2008 年 TLS 13 2018 年 安全網路程式設計 早期的研究工作，為方便改造原有網路應用程式，在 1993 年已經有了相似的 Berkeley 套接字安全傳輸層 API 方法 Thomas Y C Woo Raghuram Bindignavle Shaowen Su and Simon S Lam SNP An interface for secure network programming Proceedings USENIX Summer Technical Conference June 1994。 SSL 10、20 和 30 SSL是網景公司（Netscape）設計的主要用於 Web 的安全傳輸協議，這種協議在 Web 上獲得了廣泛的應用。 基礎演算法由作為網景公司的首席科學家塔希爾蓋莫爾（Taher Elgamal）編寫，所以他被人稱為 SSL 之父。 2014 年 10 月，Google 發布在 SSL 30 中發現設計缺陷，建議停用此一協議。攻擊者可以向 TLS 傳送虛假錯誤提示，然後將安全連線強行降級到過時且不安全的 SSL 30，然後就可以利用其中的設計漏洞竊取敏感資訊。Google 在自己公司相關產品中陸續禁止回溯相容，強制使用 TLS 協議。Mozilla 也在 11 月 25 日發布的 Firefox 34 中徹底停用了 SSL 30。微軟同樣發出了安全通告。 10 版本從未公開過，因為存在嚴重的安全漏洞。 20 版本在 1995 年 2 月釋出。2011 年，RFC 6176 標準棄用了 SSL 20。 30 版本在 1996 年釋出，是由網景工程師、Phil Karlton 和 Alan Freier 完全重新設計的。2015 年，RFC 7568 標準棄用了 SSL 30。 TLS 10 IETF 將 SSL 標準化，即 RFC 2246 ，並將其稱為 TLS。 TLS 11 TLS 11 在 RFC 4346 中定義，於 2006 年 4 月發表，它是 TLS 10 的更新。在此版本中的差異包括： 新增對 CBC 攻擊的保護： 隱式 IV 被替換成一個顯式的 IV。 更改分組密碼模式中的填充錯誤。 支援 IANA 登記的引數。 微軟、Google、蘋果、Mozilla 四家瀏覽器業者在 2020 年終止支援 TLS 10 及 11 版。2021 年 3 月，RFC 8996 標準棄用了 TLS 10 和 TLS 11。 TLS 12 TLS 12 在 RFC 5246 中定義，於 2008 年 8 月發表。它基於更早的 TLS 11 規範。主要區別包括： 增加 SHA2 密碼雜湊函式。 增加 AEAD 加密演算法，如 GCM 模式。 新增 TLS 擴充套件定義和 AES 密碼組合。所有 TLS 版本在 2011 年 3 月釋出的 RFC 6176 中刪除了對 SSL 的相容，這樣 TLS 會話將永遠無法協商使用的 SSL 20 以避免安全問題。 TLS 13 TLS 13 在 RFC 8446 中定義，於 2018 年 8 月發表。它與 TLS 12 的主要區別包括： 將金鑰交換演算法（如 ECDHE）和認證演算法（如 RSA）從密碼套件中分離出來。 移除 MD5、SHA1 密碼雜湊函式的支援。 請求數字簽名。 整合和半短暫 DH 提議。 替換使用和票據的恢復。 支援 1RTT 握手並初步支援 0RTT。 透過在金鑰協商期間使用臨時金鑰來保證完善的前向安全性。 放棄許多不安全或過時特性的支援，包括資料壓縮、重新協商、非 AEAD 加密演算法、靜態 RSA 和靜態 DH 金鑰交換、自定義 DHE 分組、點格式協商、更改密碼本規範的協議、UNIX 時間的 Hello 訊息，以及長度欄位 AD 輸入到 AEAD 密碼本。 較 TLS 12 速度更快，效能更好。 移除 RC4 加密演演算法的支援。 整合會話雜湊的使用。 棄用記錄層版本號和凍結數以改進向後相容性。 將一些安全相關的演算法細節從附錄移動到標準，並將 ClientKeyShare 降級到附錄。 支援和 Ed448 數字簽名演算法。 支援 X25519 金鑰交換。 支援帶 Poly1305 訊息驗證碼的 ChaCha20 加密演演算法。 支援加密伺服器名稱指示（ ESNI）。 網路安全服務（NSS）是由 Mozilla 開發並由其網路瀏覽器 Firefox 使用的加密庫，自 2017 年 2 月起便預設啟用 TLS 13。隨後 TLS 13 被新增到 2017 年 3 月釋出的 Firefox 520 中，但它由於某些使用者的相容性問題，預設情況下停用。直到 Firefox 600 才正式預設啟用。 Google Chrome 曾在 2017 年短時間將 TLS 13 設為預設，然而由於類似等不相容元件而被取消。 wolfSSL 在 2017 年 5 月釋出的 3111 版本中啟用了 TLS 13。作為第一款支援 TLS 13 部署，wolfSSL 3111 支援 TLS 13 Draft 18（現已支援到 Draft 28），同時官方也釋出了一系列關於 TLS 12 和 TLS 13 效能差距的部落格。 演算法 金鑰交換和金鑰協商 在客戶端和伺服器開始交換 TLS 所保護的加密資訊之前，他們必須安全地交換或協定加密金鑰和加密資料時要使用的密碼。用於金鑰交換的方法包括：使用 RSA 演算法生成公鑰和私鑰（在 TLS 握手協議中被稱為 TLS_RSA）、DiffieHellman（在 TLS 握手協議中被稱為 TLS_DH）、臨時 DiffieHellman（在 TLS 握手協議中被稱為 TLS_DHE）、橢圓曲線迪菲 赫爾曼（在 TLS 握手協議中被稱為 TLS_ECDH）、臨時橢圓曲線 DiffieHellman（在 TLS 握手協議中被稱為 TLS_ECDHE）、匿名 DiffieHellman（在 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 20 SSL 30 TLS 10 TLS 11 TLS 12 TLS 13 狀態 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 RFC 中 TLS 12 的定義 在 RFC 草案中提出 中 TLS 12、13 的定義 加密密碼 針對公開可行的攻擊的密碼安全性 密碼 密碼 密碼 協議版本 協議版本 協議版本 協議版本 協議版本 協議版本 狀態 型別 演算法 長度（bits） SSL 20 SSL 30 must be implemented to fix a renegotiation flaw that would otherwise break this protocolIf libraries implement fixes listed in this violates the SSL 30 specification which the IETF cannot change unlike TLS Fortunately most current libraries implement the fix and disregard the violation that this causesThe BEAST attack breaks all block ciphers CBC ciphers used in SSL 30 and TLS 10 unless mitigated by the client andor the server See Web browsersThe POODLE attack breaks all block ciphers CBC ciphers used in SSL 30 unless mitigated by the client andor the server See Web browsers TLS 10 TLS 11 TLS 12 TLS 13 狀態 分組密碼及其加密方式 AES GCM 認證加密 倒如 GCM 和 CCM 只適用於 TLS 12 或以上版本。 256 128 RFC 中 TLS 12 的定義 分組密碼及其加密方式 AES CCM 256 128 RFC 中 TLS 12 的定義 分組密碼及其加密方式 AES CBC 256 128 RFC 中 TLS 12 的定義 分組密碼及其加密方式 Camellia GCM 256 128 RFC 中 TLS 12 的定義 分組密碼及其加密方式 Camellia CBC 256 128 RFC 中 TLS 12 的定義 分組密碼及其加密方式 GCM 256 128 RFC 中 TLS 12 的定義 分組密碼及其加密方式 CBC 256 128 RFC 中 TLS 12 的定義 分組密碼及其加密方式 CBC 128 RFC 中 TLS 12 的定義 分組密碼及其加密方式 3DES EDE CBC 如該加密系統並未移除所有計時旁路，幸運十三攻擊能破解 CBC 加密。 112 RFC 中 TLS 12 的定義 分組密碼及其加密方式 CNT 256 定義於 分組密碼及其加密方式 CTR 256 定義於 分組密碼及其加密方式 CTR 256 定義於 分組密碼及其加密方式 MGM 256 定義於 分組密碼及其加密方式 MGM 256 定義於 分組密碼及其加密方式 IDEA CBC 128 從 TLS 12 標準中移除 分組密碼及其加密方式 DES CBC 56 從 TLS 12 標準中移除 分組密碼及其加密方式 DES CBC 40 此等金鑰長度只有 40 位元的密碼套件為降級版本，以符合（於 2000 年被大幅放寬）美國對某些高強度加密技術的出口管制。自 TLS 11 起，它們均被停用。 在 TLS 11 及之後版本禁止 分組密碼及其加密方式 CBC 40 在 TLS 11 及之後版本禁止 流加密 ChaCha20Poly1305 256 RFC 中 TLS 12 的定義 流加密 RC4Use of RC4 in all versions of TLS is prohibited by because RC4 attacks weaken or break RC4 used in SSLTLS 128 由定義所有版本 TLS 禁止 流加密 RC4Use of RC4 in all versions of TLS is prohibited by because RC4 attacks weaken or break RC4 used in SSLTLS 40 由定義所有版本 TLS 禁止 None NullAuthentication only no encryption RFC 中 TLS 12 的定義 標註 資料完整性 訊息鑑別碼（MAC）用於對資料完整性進行認證。HMAC 用於 CBC 模式的塊密碼。AEAD 例如 GCM 模式和 CCM 模式使用 AEAD 內建的訊息鑒別碼，不使用 HMAC。另外，在 TLS 握手過程中需要使用基於 HMAC 的偽隨機函式（PRF），或。 資料的完整性 演算法 SSL 20 SSL 30 TLS 10 TLS 11 TLS 12 TLS 13 狀態 HMACMD5 RFC 中 TLS 12 的定義 HMACSHA1 RFC 中 TLS 12 的定義 HMACSHA256384 RFC 中 TLS 12 的定義 AEAD RFC 中 TLS 12 的定義 中 TLS 12 的定義 RFC Draft 中 TLS 12 的定義 AEAD 中 TLS 13 的定義 過程 TLS 在網際網路上為 HTTP 等應用程式提供身份驗證、加密、完整性，其基礎是公鑰基礎設施。這是因為公鑰基礎設施普遍商業運營。TLS 協議的設計在某種程度上能夠使主從架構應用程式通訊預防竊聽、干擾和訊息偽造。 TLS 包含幾個基本階段： 對等協商支援的 TLS 版本，和支援的密碼套件。 基於非對稱金鑰的身份認證，通常是基於 PKI 證書的身份認證。伺服器將其 X509 證書傳送給客戶端，由客戶端驗證伺服器的身份。如果伺服器要驗證客戶端的證書，則客戶端可能會將客戶端證書傳送給伺服器。通常僅驗證伺服器，不驗證客戶端。 基於對稱金鑰的資料加密。客戶端生成隨機數作為對談金鑰，並使用伺服器公鑰（伺服器公鑰在伺服器證書中）加密對談金鑰，最後將已加密的對談金鑰傳送給伺服器。由伺服器的私鑰解密出對談金鑰。最後使用此對談金鑰加密資料。TLS 也可以使用預共用金鑰（PSK）作為對稱金鑰。 在第一階段，客戶端與伺服器協商所用密碼演算法。當前廣泛實現的演算法選擇如下： 身份驗證：RSA、DSA、ECDSA； 金鑰交換：、DiffieHellman、ECDH； 對稱金鑰加密：RC4、DES、3DES、AES、ChaCha20 以及 Camellia； 雜湊函式：MD5、SHA 家族。 參考文獻 外部連結 SSLTLSWTLS 原理 SSL 配置指南 SSL 狀態檢查、格式轉換、漏洞掃描工具 參見 應用層協議協商 SSL 加速 擴充套件驗證證書 Category 加密協議 Category 網際網路標準 Category 網路協議 Category 電子商務 Category 保密通訊