傳輸層安全性協定(英語: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網絡傳真等應用程式中,廣泛使用這個協定。許多網站,如GoogleFacebookWikipedia等也以這個協定來建立安全連線,傳送資料。目前已成為互聯網上保密通訊的工業標準。

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

概論

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

TLS協定的優勢是與高層的應用層協定(如HTTPFTPTelnet等)無耦合。應用層協定能透明地執行在TLS協定之上,由TLS協定進行建立加密通道需要的協商和認證。應用層協定傳送的數據在通過TLS協定時都會被加密,從而保證通訊的私密性。

TLS協定是可選的,必須組態客戶端和伺服器才能使用。主要有兩種方式實現這一目標:一個是使用統一的TLS協定通訊埠(例如:用於HTTPS的埠443);另一個是客戶端請求伺服器連接到TLS時使用特定的協定機制(例如:電子郵件常用的STARTTLS)。一旦客戶端和伺服器都同意使用TLS協定,他們通過使用一個交握過程協商出一個有狀態的連接以傳輸數據[1]。通過交握,客戶端和伺服器協商各種參數用於建立安全連接:

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

發展歷史

More information 協定, 發佈時間 ...
協定 發佈時間 狀態
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年
Close

安全網絡編程

早期的研究工作,為方便改造原有網絡應用程式,在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]

  • 1.0版本從未公開過,因為存在嚴重的安全漏洞。
  • 2.0版本在1995年2月發佈。2011年,RFC 6176 標準棄用了SSL 2.0。
  • 3.0版本在1996年發佈,是由網景工程師保羅·科切英語Paul_Carl_KocherPhil KarltonAlan 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月發表[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)從密碼套件中分離出來。
  • 移除MD5SHA1密碼雜湊函數的支援。
  • 請求數碼簽章
  • 整合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]

More information 演算法, SSL 2.0 ...
身份驗證和金鑰交換協定列表
演算法 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的定義
Close

過程

參考文獻

外部連結

參見

Wikiwand in your browser!

Seamless Wikipedia browsing. On steroids.

Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.

Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.