傳輸層安全性協定

出自Local Chinese Wikipedia
(重新導向自SSL
跳至導覽 跳至搜尋

Template:Expand language Template:NoteTA 腳本錯誤:沒有「redirect hatnote」這個模塊。 腳本錯誤:沒有「sidebar」這個模塊。

傳輸層安全性協定Template:Langx,縮寫:腳本錯誤:沒有「Lang」這個模塊。),前身稱為安全套接層Template:Langx,縮寫:腳本錯誤:沒有「Lang」這個模塊。)是一種安全協議,目的是為互聯網通信提供安全及數據完整性保障。

網景公司(腳本錯誤:沒有「Lang」這個模塊。)在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)。這個會談密匙是用來將通訊兩方交換的資料做加密,保證兩個應用間通信的保密性和可靠性,使客戶與伺服器應用之間的通信不被攻擊者竊聽。

概論[編輯]

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

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

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

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

Template:Internet security protocols

發展歷史[編輯]

協議 發佈時間 狀態
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(腳本錯誤:沒有「Lang」這個模塊。)是網景公司(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年發佈,是由網景工程師Template:LePhil KarltonAlan Freier完全重新設計的。2015年,RFC 7568 標準棄用了SSL 3.0。

TLS 1.0[編輯]

IETF將SSL標準化,即 RFC 2246 ,並將其稱為TLS(腳本錯誤:沒有「Lang」這個模塊。)。

TLS 1.1[編輯]

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

  • 添加對CBC攻擊的保護:
    • 隱式IV被替換成一個顯式的IV
    • 更改分組密碼模式中的填充錯誤。
  • 支持IANA登記的參數。[11]Template:Rp

微軟、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]Template:Rp。所有TLS版本在2011年3月發佈的RFC 6176中刪除了對SSL的兼容,這樣TLS會話將永遠無法協商使用的SSL 2.0以避免安全問題。

TLS 1.3[編輯]

腳本錯誤:沒有「Labelled list hatnote」這個模塊。 TLS 1.3在 RFC 8446 中定義,於2018年8月發表。[13]它與TLS 1.2的主要區別包括:

  • 密鑰交換算法(如ECDHE)和認證算法(如RSA)從密碼套件中分離出來。
  • 移除MD5SHA1密碼雜湊函數的支持。
  • 請求數字簽名
  • 集成Template:Tsl和半短暫DH提議。
  • 替換使用Template:Tsl和票據的恢復。
  • 支持1-RTT握手並初步支持0-RTT。
  • 通過在密鑰協商期間使用臨時密鑰來保證完善的前向安全性
  • 放棄許多不安全或過時特性的支持,包括數據壓縮、重新協商、非AEAD加密算法、靜態RSA和靜態DH密鑰交換、自定義DHE分組、點格式協商、更改密碼本規範的協議、UNIX時間的Hello消息,以及長度字段AD輸入到AEAD密碼本。
  • 較TLS 1.2速度更快,效能更好。
  • 移除RC4加密演算法的支援。
  • 集成會話散列的使用。
  • 棄用記錄層版本號和凍結數以改進向後兼容性。
  • 將一些安全相關的算法細節從附錄移動到標準,並將ClientKeyShare降級到附錄。
  • 支援腳本錯誤:沒有「ilh」這個模塊。和Ed448數字簽名算法。
  • 支援X25519密鑰交換。
  • 支援帶Poly1305訊息驗證碼ChaCha20加密演算法。
  • 支持加密伺服器名稱指示腳本錯誤:沒有「Lang」這個模塊。, 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設為默認,然而由於類似腳本錯誤:沒有「ilh」這個模塊。等不兼容組件而被取消。[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]

算法[編輯]

腳本錯誤:沒有「main」這個模塊。

密鑰交換和密鑰協商[編輯]

在客戶端和伺服器開始交換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 狀態
Template:Depends RFC中TLS 1.2的定義
Template:Depends
DHE-RSA(具有前向安全性
Template:Depends
ECDHE-RSA(具有前向安全性
Template:Depends
DHE-DSS(具有前向安全性 [26]
DHE-ECDSA (具有前向安全性)
Template:Depends
ECDHE-ECDSA(具有前向安全性
DHE-EdDSA (具有前向安全性)
Template:Depends
ECDHE-EdDSA (具有前向安全性)[27]
Template:Depends
Template:Depends
DHE-PSK(具有前向安全性
ECDHE-PSK(具有前向安全性
Template:Depends
Template:Depends
Template:Depends
Template:Depends ?
Template:Bad
Template:Bad
Template:Tsl[28] 在RFC草案中提出
Template:Tsl[29] Template:IETF RFC中TLS 1.2、1.3的定義

加密密碼[編輯]

腳本錯誤:沒有「Labelled list hatnote」這個模塊。

針對公開可行的攻擊的密碼安全性
密碼 協議版本 狀態
類型 算法 長度(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] 不適用 Template:Bad Template:Depends Template:Depends Template:Depends 不適用
Camellia GCM[32][n 5] 256, 128 不適用 不適用 不適用 不適用 安全 不適用
Camellia CBC[33][n 6] 不適用 Template:Bad Template:Depends Template:Depends Template:Depends 不適用
Template:Le GCM[34][n 5] 256, 128 不適用 不適用 不適用 不適用 安全 不適用
Template:Le CBC[34][n 6] 不適用 不適用 Template:Depends Template:Depends Template:Depends 不適用
Template:Le CBC[35][n 6] 128 不適用 Template:Bad Template:Depends Template:Depends Template:Depends 不適用
3DES EDE CBC[n 6]Template:Refn 112Template:Refn Template:Bad Template:Bad Template:Bad Template:Bad Template:Bad 不適用
Template:Le CNT[28][n 7] 256 不適用 不適用 Template:Bad Template:Bad Template:Bad 不適用 定義於Template:IETF RFC
Template:Le CTR[29][n 7] 256 不適用 不適用 Template:Bad Template:Bad Template:Bad 不適用 定義於Template:IETF RFC
Template:Tsl CTR[29] 256 不適用 不適用 不適用 不適用 安全 不適用 定義於Template:IETF RFC
Template:Le MGM[29][n 5][n 7] 256 不適用 不適用 不適用 不適用 不適用 Template:Bad 定義於Template:IETF RFC
Template:Tsl MGM[29][n 5] 256 不適用 不適用 不適用 不適用 不適用 安全 定義於Template:IETF RFC
IDEA CBC[n 6][n 7]Template:Refn 128 Template:Bad Template:Bad Template:Bad Template:Bad 不適用 不適用 從TLS 1.2標準中移除
DES CBC[n 6][n 7][n 8] 056 Template:Bad Template:Bad Template:Bad Template:Bad 不適用 不適用
040[n 9] Template:Bad Template:Bad Template:Bad 不適用 不適用 不適用 在TLS 1.1及之後版本禁止
Template:Le CBC[n 6][n 7] 040[n 9] Template:Bad Template:Bad Template:Bad 不適用 不適用 不適用
流加密 ChaCha20-Poly1305[36][n 5] 256 不適用 不適用 不適用 不適用 安全 安全 RFC中TLS 1.2的定義
RC4[n 10] 128 Template:Bad Template:Bad Template:Bad Template:Bad Template:Bad 不適用 Template:IETF RFC定義所有版本TLS禁止
040[n 9] Template:Bad Template:Bad Template:Bad 不適用 不適用 不適用
None Null[n 11] Template:Bad Template:Bad Template:Bad Template:Bad Template:Bad 不適用 RFC中TLS 1.2的定義
標註
  1. 1.0 1.1 1.2 1.3 Template:IETF RFC must be implemented to fix a renegotiation flaw that would otherwise break this protocol.
  2. If libraries implement fixes listed in Template:IETF RFC, 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 認證加密 (倒如GCMCCM) 只適用於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 引用錯誤:無效的 <ref> 標籤,未定義名稱為 Sweet32 的參考文獻內容文字。
  8. 引用錯誤:無效的 <ref> 標籤,未定義名稱為 removal_from_tls1.2 的參考文獻內容文字。
  9. 9.0 9.1 9.2 此等密鑰長度只有40位元的密碼套件為降級版本,以符合(於2000年被大幅放寬)美國對某些高強度加密技術的出口管制。自TLS 1.1起,它們均被禁用。
  10. Use of RC4 in all versions of TLS is prohibited by Template:IETF RFC (because RC4 attacks weaken or break RC4 used in SSL/TLS).
  11. Authentication only, no encryption.

數據完整性[編輯]

訊息鑑別碼(MAC)用於對數據完整性進行認證。HMAC用於CBC模式的塊密碼AEAD例如GCM模式和CCM模式使用AEAD內建的訊息鑒別碼,不使用HMAC[37]。另外,在TLS握手過程中需要使用基於HMAC的偽隨機函數(PRF),或腳本錯誤:沒有「ilh」這個模塊。

數據的完整性
算法 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
Template:Tsl Template:IETF RFC中TLS 1.2的定義
Template:Tsl RFC Draft中TLS 1.2的定義
Template:Tsl AEAD Template:IETF RFC中TLS 1.3的定義

過程[編輯]

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

TLS包含幾個基本階段:

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

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

參考文獻[編輯]

外部連結[編輯]

腳本錯誤:沒有「Side box」這個模塊。

參見[編輯]

腳本錯誤:沒有「Portal」這個模塊。

Template:TLS和SSL 腳本錯誤:沒有「Navbox」這個模塊。 腳本錯誤:沒有「navbox」這個模塊。