Loading AI tools
用於保護傳輸中數據的密碼協議 来自维基百科,自由的百科全书
傳輸層安全性協定(英語:Transport Layer Security,縮寫:TLS),前身稱為安全通訊協定(英語:Secure Sockets Layer,縮寫:SSL)是一種安全協定,目的是為網際網路通訊提供安全及資料完整性保障。
![]() | 此條目可參照英語維基百科相應條目來擴充。 (2020年8月11日) |
網景公司(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]。通過交握,客戶端和伺服器協商各種參數用於建立安全連接:
早期的研究工作,為方便改造原有網路應用程式,在1993年已經有了相似的Berkeley通訊端安全傳輸層API方法[5]。
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.1在 RFC 4346 中定義,於2006年4月發表[10],它是TLS 1.0的更新。在此版本中的差異包括:
微軟、Google、蘋果、Mozilla四家瀏覽器業者在2020年終止支援TLS 1.0及1.1版[12]。2021年3月,RFC 8996標準棄用了TLS 1.0和TLS 1.1[4]。
TLS 1.2在 RFC 5246 中定義,於2008年8月發表。它基於更早的TLS 1.1規範。主要區別包括:
TLS 1.3在 RFC 8446 中定義,於2018年8月發表。[13]它與TLS 1.2的主要區別包括:
網路安全服務(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等不相容組件而被取消。[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 | 否 | 否 | 是 | 是 | 是 | 否 | |
DHE-PSK(具有前向安全性) | 否 | 否 | 是 | 是 | 是 | 是 | |
ECDHE-PSK(具有前向安全性) | 否 | 否 | 是 | 是 | 是 | 是 | |
SRP | 否 | 否 | 是 | 是 | 是 | 否 | |
SRP-DSS | 否 | 否 | 是 | 是 | 是 | 否 | |
SRP-RSA | 否 | 否 | 是 | 是 | 是 | 否 | |
Kerberos | 否 | 否 | 是 | 是 | 是 | ? | |
DH-ANON(不安全) | 否 | 是 | 是 | 是 | 是 | 否 | |
ECDH-ANON(不安全) | 否 | 否 | 是 | 是 | 是 | 否 | |
GOST R 34.10-94 / 34.10-2001[28] | 否 | 否 | 是 | 是 | 是 | 在RFC草案中提出 | |
GOST R 34.10-2012[29] | 否 | 否 | 否 | 否 | 是 | 是 | RFC 9189 9367中TLS 1.2、1.3的定義 |