TLS

TLS
維基百科介紹:
傳輸層安全性協定（英語：Transport Layer Security，縮寫：TLS）及其前身安全通訊協定（英語：Secure Sockets Layer，縮寫：SSL）是一種安全協定，目的是為網際網路通訊提供安全及資料完整性保障。網景公司（Netscape）在1994年推出首版網頁瀏覽器－網景領航員時，推出HTTPS協定，以SSL進行加密，這是SSL的起源。IETF將SSL進行標準化，1999年公布第一版TLS標準檔案。隨後又公布RFC 5246 （2008年8月）與 RFC 6176 （2011年3月）。在瀏覽器、電子郵件、即時通訊、VoIP、網路傳真等應用程式中，廣泛支援這個協定。主要的網站，如Google、Facebook等也以這個協定來建立安全連線，傳送資料。目前已成為網際網路上保密通訊的工業標準。

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交握過程就會失敗，並且斷開所有的連接。

發展歷史

More information: 協定, 發布時間…

協定發布時間狀態SSL 1.0未公布未公布SSL 2.01995年已於2011年棄用SSL 3.01996年已於2015年棄用TLS 1.01999年計劃於2020年棄用TLS 1.12006年計劃於2020年棄用TLS 1.22008年TLS 1.32018年

Close

安全網絡編程

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

SSL 1.0、2.0和3.0

SSL（Secure Sockets Layer）是網景公司（Netscape）設計的主要用於Web的安全傳輸協定，這種協定在Web上獲得了廣泛的應用[3]。
基礎演算法由作為網景公司的首席科學家塔希爾·蓋莫爾（Taher Elgamal）編寫，所以他被人稱為「SSL之父」。[4][5]
2014年10月，Google發布在SSL 3.0中發現設計缺陷，建議禁用此一協定。攻擊者可以向TLS發送虛假錯誤提示，然後將安全連接強行降級到過時且不安全的SSL 3.0，然後就可以利用其中的設計漏洞竊取敏感資訊。Google在自己公司相關產品中陸續禁止回溯相容，強制使用TLS協定。Mozilla也在11月25日發布的Firefox 34中徹底禁用了SSL 3.0。微軟同樣發出了安全通告[6]。

1.0版本從未公開過，因為存在嚴重的安全漏洞。

2.0版本在1995年2月發布，但因為存在數個嚴重的安全漏洞而被3.0版本替代[7]。

3.0版本在1996年發布，是由網景工程師Paul Kocher、Phil Karlton和Alan Freier完全重新設計的。較新版本的SSL/TLS基於SSL 3.0。SSL 3.0作為歷史文獻IETF通過 RFC 6101 發表。

TLS 1.0

IETF將SSL標準化，即 RFC 2246，並將其稱為TLS（Transport Layer Security）。從技術上講，TLS 1.0與SSL 3.0的差異非常微小。但正如RFC所述"the differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough to preclude interoperability between TLS 1.0 and SSL 3.0"（本協定和SSL 3.0之間的差異並不是顯著，卻足以排除TLS 1.0和SSL 3.0之間的互操作性）。TLS 1.0包括可以降級到SSL 3.0的實現，這削弱了連接的安全性[8]:1–2。

TLS 1.1

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

加入對CBC攻擊的保護：

隱式IV被替換成一個顯式的IV。

更改區塊加密法模式中的填充錯誤。

支援IANA登記的參數。[8]:2

TLS 1.2

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

可使用密碼組合選項指定偽隨機函式使用SHA-256替換MD5-SHA-1組合。

可使用密碼組合選項指定在完成訊息的雜湊認證中使用SHA-256替換MD5-SHA-1演算法，但完成訊息中雜湊值的長度仍然被截斷為96位。

在交握期間MD5-SHA-1組合的數位簽章被替換為使用單一Hash方法，預設為SHA-1。

增強伺服器和用戶端指定Hash和簽章演算法的能力。

擴大經過身分驗證的加密密碼，主要用於GCM和CCM模式的AES加密的支援。

加入TLS擴充定義和AES密碼組合[8]:2。所有TLS版本在2011年3月發布的RFC 6176中刪除了對SSL的相容，這樣TLS對談將永遠無法協商使用的SSL 2.0以避免安全問題。

TLS 1.3

參見：來回通訊延遲

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

將金鑰協商和認證演算法從密碼套件中分離出來。

移除脆弱和較少使用的命名橢圓曲線支援（參見橢圓曲線密碼學）。

移除MD5和SHA-224密碼雜湊函式的支援。

請求數位簽章，即便使用之前的組態。

整合HKDF（英語：Key derivation function）和半短暫DH提議。

替換使用PSK（英語：TLS-PSK）和票據的恢復。

支援1-RTT交握並初步支援0-RTT。

通過在(EC)DH金鑰協定期間使用臨時金鑰來保證完善的前向安全性。

放棄許多不安全或過時特性的支援，包括資料壓縮、重新協商、非AEAD密碼本、靜態RSA和靜態DH金鑰交換、自訂DHE分組、點格式協商、更改密碼本規範的協定、UNIX時間的Hello訊息，以及長度欄位AD輸入到AEAD密碼本。

禁止用於向下相容性的SSL和RC4協商。

整合對談雜湊的使用。

棄用記錄層版本號和凍結數以改進向下相容性。

將一些安全相關的演算法細節從附錄移動到標準，並將ClientKeyShare降級到附錄。

加入帶有Poly1305訊息驗證碼的ChaCha20流加密。

加入Ed25519（英語：EdDSA#Ed25519）和Ed448數位簽章演算法。

加入x25519和x448金鑰交換協定。

將支援加密伺服器名稱指示（Encrypted Server Name Indication, ESNI）。[11]

網路安全服務（NSS）是由Mozilla開發並由其網路瀏覽器Firefox使用的加密庫，自2017年2月起便預設啟用TLS 1.3。[12]隨後TLS 1.3被加入到2017年3月發布的Firefox 52.0中，但它由於某些用戶的相容性問題，預設情況下禁用。[13]直到Firefox 60.0才正式預設啟用。[14]
Google Chrome曾在2017年短時間將TLS 1.3設為預設，然而由於類似Blue Coat Systems（英語：Blue Coat Systems）等不相容元件而被取消。[15]
wolfSSL在2017年5月發布的3.11.1版本中啟用了TLS 1.3。[16] 作為第一款支援TLS 1.3部署，wolfSSL 3.11.1 支援 TLS 1.3 Draft 18（ 現已支援到Draft 28），[17]同時官方也發布了一系列關於TLS 1.2和TLS 1.3效能差距的部落格。[18]

算法

主條目：密碼套件

密鑰交換和密鑰協商

在用戶端和伺服器開始交換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）[19]和預共用金鑰（在TLS交握協定中被稱為TLS_PSK）。[20]
TLS_DH_anon和TLS_ECDH_anon的金鑰協商協定不能驗證伺服器或用戶，因為易受中間人攻擊因此很少使用。只有TLS_DHE和TLS_ECDHE提供前向保密能力。
在交換過程中使用的公鑰/私鑰加密金鑰的長度和在交換協定過程中使用的公鑰憑證也各不相同，因而提供的強健性的安全。2013年7月，Google宣布向其用戶提供的TLS加密將不再使用1024位元公鑰並切換到2048位元，以提高安全性。[21]

More information: 演算法, SSL 2.0 …

加密密碼

參見：區塊加密法工作模式

More information: 密碼, 協定版本…

標註

More information: Tap to expand…

數據完整性

訊息鑑別碼（MAC）用於對資料完整性進行認證。HMAC用於CBC模式的塊密碼和串流加密法，AEAD用於身分驗證加密，例如GCM模式和CCM模式。

More information: 演算法, SSL 2.0 …

過程



雙向憑證認證的SSL交握過程。

以下簡要介紹SSL協定的工作方式。用戶端要收發幾個交握訊號：

傳送一個「ClientHello」訊息，內容包括：支援的協定版本，比如TLS1.0版，一個用戶端生成的亂數（稍後用於生成「對談金鑰」），支援的加密演算法（如RSA公鑰加密）和支援的壓縮演算法。

然後收到一個「ServerHello」訊息，內容包括：確認使用的加密通訊協定版本，比如TLS 1.0版本（如果瀏覽器與伺服器支援的版本不一致，伺服器關閉加密通訊），一個伺服器生成的亂數（稍後用於生成「對話金鑰」），確認使用的加密方法（如RSA公鑰加密），伺服器憑證。

當雙方知道了連接參數，用戶端與伺服器交換憑證（依靠被選擇的公鑰系統）。這些憑證通常基於X.509，不過已有草案支援以OpenPGP為基礎的憑證。

伺服器請求用戶端公鑰。用戶端有憑證即雙向身分認證，沒憑證時隨機生成公鑰。

用戶端與伺服器通過公鑰保密協商共同的主私鑰（雙方隨機協商），這通過精心謹慎設計的偽亂數功能實現。結果可能使用Diffie-Hellman交換，或簡化的公鑰加密，雙方各自用私鑰解密。所有其他關鍵資料的加密均使用這個「主金鑰」。資料傳輸中記錄層（Record layer）用於封裝更高層的HTTP等協定。記錄層資料可以被隨意壓縮、加密，與訊息驗證碼壓縮在一起。每個記錄層包都有一個Content-Type段用以記錄更上層用的協定。

TLS

TLS利用金鑰演算法在網際網路上提供端點身分認證與通訊保密，其基礎是公鑰基礎設施。不過在實現的典型例子中，只有網路服務者被可靠身分驗證，而其用戶端則不一定。這是因為公鑰基礎設施普遍商業運營，電子簽章憑證通常需要付費購買。協定的設計在某種程度上能夠使主從架構應用程式通訊本身預防竊聽、干擾和訊息偽造。
TLS包含三個基本階段：

對等協商支援的金鑰演算法

基於非對稱金鑰的資訊傳輸加密和身分認證、基於PKI憑證的身分認證

基於對稱金鑰的資料傳輸保密

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

公鑰私鑰非對稱金鑰保密系統：RSA、Diffie-Hellman、DSA;

對稱金鑰保密系統：RC2、RC4、IDEA、DES、Triple DES、AES以及Camellia；

單向雜湊函式：MD5、SHA1以及SHA256。

TLS/SSL有多樣的安全保護措施：

所有的記錄層資料均被編號，用於訊息驗證碼校驗。

參考文獻

More information: Tap to expand…

外部連結

維基共享資源中相關的多媒體資源：傳輸層安全性協定

SSL/TLS/WTLS原理