跳至內容

傳輸層安全性協定

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書
（重新導向自传输层安全）
  「TLS」重新導向至此。關於其他用法，請見「TLS (消歧義)」。
網際網路協定套組
應用層
傳輸層
網路層
連結層

傳輸層安全性協定（英語：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協定，他們通過使用一個交握過程協商出一個有狀態的連接以傳輸資料[1]。通過交握，客戶端和伺服器協商各種參數用於建立安全連接：

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

發展歷史

[編輯]
協定 發布時間 狀態
SSL 1.0 未公佈 未公佈
SSL 2.0 1995年 已於2011年棄用[2]
SSL 3.0 1996年 已於2015年棄用[3]
TLS 1.0 1999年 於2021年棄用[4]
TLS 1.1 2006年 於2021年棄用[4]
TLS 1.2 2008年
TLS 1.3 2018年

安全網路編程

[編輯]

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

SSL 1.0、2.0和3.0

[編輯]

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

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

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

TLS 1.0

[編輯]

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

TLS 1.1

[編輯]

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

  • 加入對CBC攻擊的保護：
    • 隱式IV被替換成一個顯式的IV。
    • 更改區塊加密法模式中的填充錯誤。
  • 支援IANA登記的參數。[11]:2

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

TLS 1.2

[編輯]

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

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

TLS 1.3

[編輯]
參見：來回通訊延遲

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

  • 將金鑰交換演算法（如ECDHE）和認證演算法（如RSA）從密碼套件中分離出來。
  • 移除MD5、SHA1密碼雜湊函式的支援。
  • 請求數位簽章。
  • 整合HKDF（英語：Key derivation function）和半短暫DH提議。
  • 替換使用PSK（英語：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）。[14]

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

Google Chrome曾在2017年短時間將TLS 1.3設為預設，然而由於類似Blue Coat Systems（英語：Blue Coat Systems）等不相容組件而被取消。[18]

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

演算法

[編輯]
主條目：密碼套件

金鑰交換和金鑰協商

[編輯]

在客戶端和伺服器開始交換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）[22]、預共享金鑰（在TLS交握協定中被稱為TLS_PSK）[23]和安全遠端密碼（在TLS交握協定中被稱為TLS_SRP）。[24]

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

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

身分驗證和金鑰交換協定列表
演算法 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（具有前向安全性） 否 是 是 是 是 否[26]
DHE-ECDSA (具有前向安全性) 否 否 否 否 否 是
ECDH-ECDSA 否 否 是 是 是 否
ECDHE-ECDSA（具有前向安全性） 否 否 是 是 是 是
DHE-EdDSA (具有前向安全性) 否 否 否 否 否 是
ECDH-EdDSA 否 否 是 是 是 否
ECDHE-EdDSA (具有前向安全性)[27] 否 否 是 是 是 是
PSK 否 否 是 是 是 是
RSA-PSK（英語：Pre-shared key） 否 否 是 是 是 否
DHE-PSK（英語：Pre-shared key）（具有前向安全性） 否 否 是 是 是 是
ECDHE-PSK（英語：Pre-shared key）（具有前向安全性） 否 否 是 是 是 是
SRP 否 否 是 是 是 否
SRP-DSS 否 否 是 是 是 否
SRP-RSA 否 否 是 是 是 否
Kerberos 否 否 是 是 是 ?
DH-ANON（不安全） 否 是 是 是 是 否
ECDH-ANON（不安全） 否 否 是 是 是 否
GOST R 34.10-94 / 34.10-2001（英語：GOST）[28] 否 否 是 是 是 在RFC草案中提出
GOST R 34.10-2012（英語：GOST）[29] 否 否 否 否 是 是 RFC 9189 9367中TLS 1.2、1.3的定義

加密密碼

[編輯]
參見：區塊加密法工作模式
針對公開可行的攻擊的密碼安全性
密碼 協定版本 狀態
類型 演算法 長度（bits） SSL 2.0 SSL 3.0
[n 1][n 2][n 3][n 4] 		TLS 1.0
[n 1][n 3] 		TLS 1.1
[n 1] 		TLS 1.2
[n 1] 		TLS 1.3
區塊加密法及其加密方式 AES GCM[30][n 5] 256, 128 不適用 不適用 不適用 不適用 安全 安全 RFC中TLS 1.2的定義
AES CCM[31][n 5] 不適用 不適用 不適用 不適用 安全 安全
AES CBC[n 6] 不適用 不安全 依賴於後期加入的措施 依賴於後期加入的措施 依賴於後期加入的措施 不適用
Camellia GCM[32][n 5] 256, 128 不適用 不適用 不適用 不適用 安全 不適用
Camellia CBC[33][n 6] 不適用 不安全 依賴於後期加入的措施 依賴於後期加入的措施 依賴於後期加入的措施 不適用
ARIA加密演算法（英語：ARIA_(cipher)） GCM[34][n 5] 256, 128 不適用 不適用 不適用 不適用 安全 不適用
ARIA加密演算法（英語：ARIA_(cipher)） CBC[34][n 6] 不適用 不適用 依賴於後期加入的措施 依賴於後期加入的措施 依賴於後期加入的措施 不適用
SEED加密演算法（英語：SEED (cipher)） CBC[35][n 6] 128 不適用 不安全 依賴於後期加入的措施 依賴於後期加入的措施 依賴於後期加入的措施 不適用
3DES EDE CBC[n 6][n 7] 112[n 8] 不安全 不安全 不安全 不安全 不安全 不適用
GOST 28147-89（英語：GOST_(block_cipher)） CNT[28][n 7] 256 不適用 不適用 不安全 不安全 不安全 不適用 定義於RFC 4357
GOST R 34.12-2015 Magma（英語：GOST_(block_cipher)） CTR[29][n 7] 256 不適用 不適用 不安全 不安全 不安全 不適用 定義於RFC 4357 9189
GOST R 34.12-2015 Kuznyechik（英語：Kuznyechik） CTR[29] 256 不適用 不適用 不適用 不適用 安全 不適用 定義於RFC 9189
GOST R 34.12-2015 Magma（英語：GOST_(block_cipher)） MGM[29][n 5][n 7] 256 不適用 不適用 不適用 不適用 不適用 不安全 定義於RFC 9367
GOST R 34.12-2015 Kuznyechik（英語：Kuznyechik） MGM[29][n 5] 256 不適用 不適用 不適用 不適用 不適用 安全 定義於RFC 9367
IDEA CBC[n 6][n 7][n 9] 128 不安全 不安全 不安全 不安全 不適用 不適用 從TLS 1.2標準中移除
DES CBC[n 6][n 7][n 9] 056 不安全 不安全 不安全 不安全 不適用 不適用
040[n 10] 不安全 不安全 不安全 不適用 不適用 不適用 在TLS 1.1及之後版本禁止
RC2（英語：RC2） CBC[n 6][n 7] 040[n 10] 不安全 不安全 不安全 不適用 不適用 不適用
流加密 ChaCha20-Poly1305[40][n 5] 256 不適用 不適用 不適用 不適用 安全 安全 RFC中TLS 1.2的定義
RC4[n 11] 128 不安全 不安全 不安全 不安全 不安全 不適用 由RFC 7465定義所有版本TLS禁止
040[n 10] 不安全 不安全 不安全 不適用 不適用 不適用
None Null[n 12] – 不安全 不安全 不安全 不安全 不安全 不適用 RFC中TLS 1.2的定義
標註
  1. ^ 1.0 1.1 1.2 1.3 RFC 5746 must be implemented to fix a renegotiation flaw that would otherwise break this protocol.
  2. ^ If libraries implement fixes listed in RFC 5746, this violates the SSL 3.0 specification, which the IETF cannot change unlike TLS. Fortunately, most current libraries implement the fix and disregard the violation that this causes.
  3. ^ 3.0 3.1 The BEAST attack breaks all block ciphers (CBC ciphers) used in SSL 3.0 and TLS 1.0 unless mitigated by the client and/or the server. See § Web browsers.
  4. ^ The POODLE attack breaks all block ciphers (CBC ciphers) used in SSL 3.0 unless mitigated by the client and/or the server. See § Web browsers.
  5. ^ 5.0 5.1 5.2 5.3 5.4 5.5 5.6 認證加密 (倒如GCM和CCM) 只適用於TLS 1.2或以上版本。
  6. ^ 6.0 6.1 6.2 6.3 6.4 6.5 6.6 6.7 如該加密系統並未移除所有計時旁路，幸運十三攻擊能破解CBC加密。
  7. ^ 7.0 7.1 7.2 7.3 7.4 7.5 7.6 Sweet32攻擊能破解分組長度為64位元的區塊加密法。[36]
  8. ^ 儘各3DES的金鑰長度為168位元, 它的有效安全性僅為112位元，[37] 遠低於建議的最少128位元。[38]
  9. ^ 9.0 9.1 TLS 1.2已移除IDEA和DES。[39]
  10. ^ 10.0 10.1 10.2 此等金鑰長度只有40位元的密碼套件為降級版本，以符合（於2000年被大幅放寬）美國對某些高強度加密技術的出口管制。自TLS 1.1起，它們均被禁用。
  11. ^ Use of RC4 in all versions of TLS is prohibited by RFC 7465 (because RC4 attacks weaken or break RC4 used in SSL/TLS).
  12. ^ Authentication only, no encryption.

資料完整性

[編輯]

訊息鑑別碼（MAC）用於對資料完整性進行認證。HMAC用於CBC模式的塊密碼。AEAD例如GCM模式和CCM模式使用AEAD內建的訊息鑒別碼，不使用HMAC[41]。另外，在TLS交握過程中需要使用基於HMAC的偽隨機函式（PRF），或HKDF（英語：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（英語：GOST (hash function)） 否 否 否 否 是 否 RFC 9189中TLS 1.2的定義
GOST R 34.11-94（英語：GOST (hash function)） 否 否 否 否 是 RFC Draft中TLS 1.2的定義
GOST R 34.12-2015（英語：GOST (hash function)） AEAD 否 否 否 否 否 是 RFC 9367中TLS 1.3的定義

過程

[編輯]

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

TLS包含幾個基本階段：

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

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

參考文獻

[編輯]
  1. ^ "SSL/TLS in Detail （頁面存檔備份，存於網際網路檔案館）". Microsoft TechNet. Updated July 31, 2003.
  2. ^ RFC 6176. [2020-05-22]. （原始內容存檔於2016-12-06）. 
  3. ^ RFC 7568. [2020-05-22]. （原始內容存檔於2018-03-28）. 
  4. ^ 4.0 4.1 4.2 RFC 8996. [2021-03-25]. （原始內容存檔於2021-03-24）. 
  5. ^ 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
  6. ^ THE SSL PROTOCOL. Netscape Corporation. 2007 [2014-12-02]. （原始內容存檔於1997-06-14）. 
  7. ^ Messmer, Ellen. Father of SSL, Dr. Taher Elgamal, Finds Fast-Moving IT Projects in the Middle East. Network World. [30 May 2014]. （原始內容存檔於2014年5月31日）. 
  8. ^ Greene, Tim. Father of SSL says despite attacks, the security linchpin has lots of life left. Network World. [30 May 2014]. （原始內容存檔於2014年5月31日）. 
  9. ^ POODLE: SSLv3 vulnerability (CVE-2014-3566). [21 October 2014]. （原始內容存檔於2016-03-17）. 
  10. ^ Dierks, T. and E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.1, RFC 4346. April 2006 [2014-12-02]. （原始內容存檔於2017-12-24）. 
  11. ^ 11.0 11.1 Polk, Tim; McKay, Terry; Chokhani, Santosh. Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations (PDF). National Institute of Standards and Technology: 67. April 2014 [2014-05-07]. （原始內容存檔 (PDF)於2014-05-08）. 
  12. ^ 林妍溱. 微軟、蘋果、Google及Mozilla四大瀏覽器業者在2020年終止支援TLS 1.0、1.1. iThome. 2018-10-16 [2020-01-12]. （原始內容存檔於2020-01-12）. 
  13. ^ Joseph A. Salowey; Sean Turner; Christopher A. Wood. TLS 1.3. IETF. 2018-08-10 [2018-08-11]. （原始內容存檔於2018-08-11） （英語）. 
  14. ^ pigsrollaroundinthem. TLS 1.3 下的 SNI 将让审查变得更困难. Solidot. 2018-08-16 [2018-08-27]. （原始內容存檔於2018-08-27）. 
  15. ^ NSS 3.29 release notes. Mozilla Developer Network. February 2017 [2018-08-11]. （原始內容存檔於2017-02-22）. 
  16. ^ Enable TLS 1.3 by default. Bugzilla@Mozilla. 16 October 2016 [10 October 2017]. （原始內容存檔於2018-08-12）. 
  17. ^ Firefox — Notes (60.0). Mozilla. [2018-05-10]. （原始內容存檔於2018-05-09） （美國英語）. 
  18. ^ ProxySG, ASG and WSS will interrupt SSL connections when clients using TLS 1.3 access sites also using TLS 1.3. BlueTouch Online. 16 May 2017 [11 September 2017]. （原始內容存檔於2017-09-12）. 
  19. ^ wolfSSL TLS 1.3 BETA Release Now Available. info@wolfssl.com. 11 May 2017 [11 May 2017]. （原始內容存檔於2018-07-25）. 
  20. ^ TLS 1.3 PROTOCOL SUPPORT. info@wolfssl.com. （原始內容存檔於2018-07-26）. 
  21. ^ TLS 1.3 Draft 28 Support in wolfSSL. info@wolfssl.com. 14 June 2018 [14 June 2018]. （原始內容存檔於2018-07-25）. 
  22. ^ RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2. Internet Engineering Task Force. [9 September 2013]. （原始內容存檔於2017-12-24）. 
  23. ^ P. Eronen, Ed. RFC 4279: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). Internet Engineering Task Force. [9 September 2013]. （原始內容存檔於2013-09-05）. 
  24. ^ D. Taylor, Ed. Using the Secure Remote Password (SRP) Protocol for TLS Authentication. Internet Engineering Task Force. November 2007 [December 21, 2014]. RFC 5054 可免費查閱. doi:10.17487/RFC5054 可免費查閱. （原始內容存檔於December 7, 2014）. 
  25. ^ Gothard, Peter. Google updates SSL certificates to 2048-bit encryption. Computing. Incisive Media. [9 September 2013]. （原始內容存檔於2013-09-22）. 
  26. ^ Sean Turner. Consensus: remove DSA from TLS 1.3. September 17, 2015 [2018-01-28]. （原始內容存檔於2015-10-03）. 
  27. ^ RFC 8422
  28. ^ RFC 5288 5289
  29. ^ RFC 6655 7251
  30. ^ RFC 6367
  31. ^ RFC 5932 6367
  32. ^ 34.0 34.1 RFC 6209
  33. ^ RFC 4162
  34. ^ On the Practical (In-)Security of 64-bit Block Ciphers — Collision Attacks on HTTP over TLS and OpenVPN (PDF). 2016-10-28 [2017-06-08]. （原始內容存檔 (PDF)於2017-04-24）. 
  35. ^ NIST Special Publication 800-57 Recommendation for Key Management — Part 1: General (Revised) (PDF). 2007-03-08 [2014-07-03]. （原始內容 (PDF)存檔於2014-06-06）. 
  36. ^ Qualys SSL Labs. SSL/TLS Deployment Best Practices. [2 June 2015]. （原始內容存檔於2015-07-04）. 
  37. ^ RFC 5469
  38. ^ RFC 7905
  39. ^ AEAD Ciphers. [2014-12-02]. （原始內容存檔於2017-12-24）. 

外部連結

[編輯]
維基共享資源上的相關多媒體資源：傳輸層安全性協定

參見

[編輯]
取自「https://zh.wikipedia.org/w/index.php?title=傳輸層安全性協定&oldid=83520925」