上海交通大學密碼與計算機安全實驗室（LoCCS）軟件安全小組（GoSSIP）版權所有，轉載請與作者取得聯系！

在今年的GoSSIP軟件安全小組面向全國優秀的本科同學開放的暑期實習中，來自上海交通大學的胡嘉尚同學深入研究了SSL/TLS協議，并撰寫了這篇TLS 1.3的科普文章，希望能夠幫助國內的安全研究人員和企業開發人員更加深入地理解和部署TLS 1.3協議。

======================================================================

時隔九年之后的新升級，TLS 1.3備受關注。針對目前已知的漏洞和安全威脅，IETF小組對TLS協議進行了一次大的更新，從2014年4月，第0份TLS 1.3草案公開，到2017年7月第21份草案發布，TLS 1.3的編寫工作已經進入尾聲，跨時3年的編寫，讓該協議成為有史以來最安全、也是最復雜的TLS協議。

正式的RFC雖然尚未發布，TLS 1.3已經開始被國內外一些網站使用，Chrome、Firefox、OpenSSL、Nginx等均提供了相應支持，TLS 1.3已經悄然進入我們的生活。借著這篇文章先來了解一下吧~

Part 1-簡介

20年——從開始到現在

對于安全加密通信，傳輸層安全協議（SSL/TLS）的重要性不言而喻。?
起初，網景公司針對傳輸層協議（TCP/UDP）并沒有對傳輸的數據進行加密保護的缺陷，為自家瀏覽器設計了SSL協議，于1995年公開協議的2.0版本。1999年，IETF小組基于SSL 3.0設計了與SSL協議獨立的TLS 1.0協議，正式成為互聯網傳輸層加密的標準。此后，TLS協議于2006年、2008年再次經歷更新，分別命名為TLS 1.1和TLS 1.2。?
如今的TLS協議不僅被用于傳輸層通訊，更作為一個標準的加密保護協議被廣泛應用于 FTP, 電子郵件和VPN等領域，時刻保護著我們網絡通信的安全。

當前的TLS協議存在問題

老版本的SSL協議被公認在完整性校驗、密鑰協商過程中有重大缺陷，因此，2011年與2015年IETF小組相繼聲明禁止使用SSL?2.0、3.0。?
TLS協議針對此前披露的漏洞做了相應的處理，但是因為其復雜性，還沒有一個版本能真正保證絕對的安全。?
目前最新版本的TLS 1.2發布距今已有九年時間，在此期間，許多SSL/TLS協議的新漏洞被發現，比如針對其壓縮機制的CRIME漏洞，針對CBC塊加密模式的BEAST漏洞（主要是針對SSL 3.0和TLS 1.0），早已不再是當初設計者認為的那么安全，人們迫切需要新的協議將其代替。

TLS1.3與之前的協議有較大差異

SSL/TLS協議為網絡通信提供了以下兩種功能：

建立一個安全的連接：對其中傳輸的數據提供加密保護，防止被中間人嗅探到可見明文；對數據提供完整性校驗，防止傳輸的數據被中間人修改。

建立一個可信的連接：對連接雙方的實體提供身份認證。

上述功能在以往的TLS協議中是這樣實現的：

• 加密：使用對稱加密算法（塊加密、流加密）加密會話數據，密鑰交換主要通過非對稱算法加密會話過程中使用的對稱密鑰傳遞給對方來實現（RSA）。從TLS 1.0起引入了DH密鑰交換算法作為另一種可選的密鑰交換算法。
• 完整性校驗：使用MAC對發送的報文進行完整性校驗計算，先計算MAC再加密。在TLS 1.2中引入了更具有安全性的AEAD算法（同時完成加密和完整性校驗）作為一個加密機制的備選選項 。
• 身份認證：所有的身份認證都基于證書公鑰體系完成。

因為RSA密鑰交換過程安全性完全依賴于服務器私鑰的安全性，TLS 1.3徹底廢棄了RSA密鑰交換算法。?
因為先計算MAC再加密的方法存在相當的安全缺陷，TLS 1.3廢棄了使用MAC的塊加密和流加密機制，僅采用AEAD類對稱加密算法作為唯一的加密選項。?
此外，TLS 1.3引入了一種新的密鑰協商機制——PSK。

其他新協議大的改變還包括：?
- 支持0-RTT數據傳輸?
- 廢棄了3DES、RC4、AES-CBC等加密組件。廢棄了SHA1、MD5等哈希算法。?
- 不再允許對加密報文進行壓縮、不再允許雙方發起重協商，密鑰的改變不再需要發送change_cipher_spec報文給對方。?
- 握手階段的報文可見明文大大減少。

對比以往的協議RFC中不足一頁的Major Differences from Previous。TLS 1.3確實可以稱得上是向前的一大步。

TLS 1.3包括3個子協議——alert、handshake、record

handshake協議負責協商使用的TLS版本、加密算法、哈希算法、密鑰材料和其他與通信過程有關的信息，對服務器進行身份認證，對客戶端進行可選的身份認證，最后對整個握手階段信息進行完整性校驗以防范中間人攻擊，是整個TLS協議的核心。?
record協議負責對接收到的報文進行加密解密，將其分片為合適的長度后轉發給其他協議層。?
alert協議負責處理消息傳輸與握手階段中的異常情況。?
此前的協議中還定義了一個子協議change_cipher_spec來決定何時對傳遞的數據進行加密，TLS 1.3取消了這一機制，密鑰的使用和改變隨著服務器和客戶端狀態的改變自然進行。

Part 2-新的術語

PSK（pre_shared_key）——新的密鑰交換暨身份認證機制

0-RTT：客戶端和服務端的一次交互（客戶端發一個報文，服務端回應一個報文）叫做一個RTT，TLS 1.2普遍采用2-RTT的握手過程，服務器延遲明顯。因此TLS 1.3引入了一種0-RTT的機制，即在剛開始TLS密鑰協商的時候，就能附送一部分經過加密的數據傳遞給對方。

為了實現0-RTT，需要雙方在剛開始建立連接的時候就已經持有一個對稱密鑰，這個密鑰在TLS 1.3中稱為PSK（pre_shared_key）。

PSK是TLS 1.2中的rusumption機制的一個升級，TLS握手結束后，服務器可以發送一個NST（new_session_ticket）的報文給客戶端，該報文中記錄PSK的值、名字和有效期等信息，雙方下一次建立連接可以使用該PSK值作為初始密鑰材料。

因為PSK是從以前建立的安全信道中獲得的，只要證明了雙方都持有相同的PSK，不再需要證書認證，就可以證明雙方的身份，因此，PSK也是一種身份認證機制。

ps: 0-RTT的實現有一定的安全缺陷，自身沒有抗重放攻擊的機制?
在TLS 1.3草案中提出了幾個對性能消耗比較大的可能的解決方法，感興趣的話可以找來讀一讀。

HKDF（HMAC_based_key_derivation_function）——新的密鑰導出函數

經過密鑰協商得出來的密鑰材料因為隨機性可能不夠，協商的過程能被攻擊者獲知，需要使用一種密鑰導出函數來從初始密鑰材料（PSK或者DH密鑰協商計算出來的key）中獲得安全性更強的密鑰。

HKDF正是TLS 1.3中所使用的這樣一個算法，使用協商出來的密鑰材料和握手階段報文的哈希值作為輸入，可以輸出安全性更強的新密鑰。

HKDF包括extract_then_expand的兩階段過程。extract過程增加密鑰材料的隨機性，在TLS 1.2中使用的密鑰導出函數PRF實際上只實現了HKDF的expand部分，并沒有經過extract，而直接假設密鑰材料的隨機性已經符合要求。

AEAD（Authenticated_Encrypted_with_associated_data）——唯一保留的加密方式

TLS協議的最終目的是協商出會話過程使用的對稱密鑰和加密算法，雙方最終使用該密鑰和對稱加密算法對報文進行加密。

AEAD將完整性校驗和數據加密兩種功能集成在同一算法中完成，是TLS 1.3中唯一支持的加密方式。TLS 1.2還支持流加密和CBC分組模式的塊加密方法，使用MAC來進行完整性校驗數據，這兩種方式均被證明有一定的安全缺陷。

但是有研究表明AEAD也有一定局限性：使用同一密鑰加密的明文達到一定長度后，就不能再保證密文的安全性。因此，TLS 1.3中引入了密鑰更新機制，一方可以（通常是服務器）向另一方發送Key Update（KU）報文，對方收到報文后對當前會話密鑰再使用一次HKDF，計算出新的會話密鑰，使用該密鑰完成后續的通信。

Part 3-Handshake子協議

TLS 1.3完整握手工作流

• +表示該報文中值得注意的extension
• * 表示該內容也可能不被發送
• {} 表示該內容使用handshake_key加密
• [] 表示該內容使用application_key加密

TLS 1.3握手執行步驟

TLS 1.3握手按照嚴格的順序發送不同的報文，各個報文包含標識自己種類的數據以及其他與握手協商有關的擴展數據（extension）。任何時候收到不按順序發出的報文種類，服務器會報錯，并轉交給alert協議層處理。?
一個正常情況下的TLS 1.3握手應該按照以下順序組織報文：

• 客戶端發送Client Hello（CH）報文，包含有關密鑰協商以及其他與TLS連接建立有關的擴展給服務端。
• 服務端發送Server Hello（SH）報文，包含有關密鑰協商的擴展返還給客戶端，雙方根據CH和SH的協商結果可以得出密鑰材料。
• 如果客戶端發送的CH報文不滿足服務端的需要（如：不包含服務端支持的DH組件），服務端會發送一個Hello Retry Request報文給客戶端，要求客戶端重新發送符合要求的CH報文。
• 利用密鑰材料和前兩個報文的哈希值，使用HKDF可以計算出一個handshake_key，此后握手階段的信息受該密鑰保護。
• 服務端發送Encypted Extension（EE）報文，包含其他與密鑰協商無關的擴展數據給客戶端。
• 如果使用公鑰證書進行身份認證，服務端發送Certificate報文（傳遞自己的證書信息），和Certificate Verify(CV)報文（使用自己的證書私鑰對之前的報文進行HMAC簽名證明自己持有該證書）給客戶端。
• 如果需要對客戶端身份進行認證，服務端還需要發送Certificate Request（CR）報文給對方請求客戶端發送證書。
• 服務端發送Finished報文。表明服務端到客戶端信道的握手階段結束，理論上不得再由該信道發送任何握手報文。
• 如果客戶端收到了服務端的CR報文，返回自己的Certificate報文和CV報文。
• 客戶端發送Finished報文，表明握手階段結束，可以正式開始會話通訊。Finished報文使用會話密鑰對上述所有握手信息進行HMAC簽名，校驗簽名可以檢驗握手階段的完整性，也可以驗證雙方是否協商出了一致的密鑰。

所有握手階段的報文都是由record協議層加解密、分片、填充、轉發的。?
在這個過程中，如果發生了任何錯誤（如：服務端證書驗證失敗、完整性校驗錯誤），則會發送一個alert報文，轉交給alert協議層進行錯誤處理。

其他沒有提及到的報文種類

除了正常的情況之外，還有其他一些報文可能出現在握手過程中。

用來傳遞PSK鍵值對信息的New Session Ticket（NST）報文： 之前也提到過，NST報文在連接建立后（即客戶端發送完Finished報文后），由服務端發送給客戶端，包含PSK初始值和PSK名字、有效期、用途限定等信息，雙方會在協商完畢后計算application_key的同時計算出一個resumption_key，使用resumption_key與PSK初始值做HKDF計算才正式得到真正的PSK值，用于下一次TLS連接的建立。

負責更新密鑰以保證AEAD安全性的Key Update(KU)報文。

用來實現0-RTT數據傳輸的Early Data（ED）報文： 如果使用了PSK協商密鑰，可以利用雙方都持有的PSK計算出一個early_key，使用該key在發送CH報文之后客戶端就可以發送加了密的應用數據（即ED）與服務端進行通訊，ED的發送與其他握手報文獨立，即服務端不用等待接收到ED之后再向客戶端發送SH，但是客戶端一旦受到服務端發送的Finished報文，必須立即結束ED的發送，而轉而發送一個End Of Early Data報文給服務端。除此之外，客戶端也可以在early data正常發送完畢之后，發送End Of Early Data結束ED，而不需要等待收到服務端的Finished報文。

TLS 1.3定義了12種握手報文

使用Hello傳遞的信息進行密鑰協商——選擇加密組件

經過兩個Hello報文后，雙方就明確了計算密鑰的初始材料和最終使用的加密算法。加密算法是通過協商加密組件獲知的。?
因為只使用AEAD加密機制，且徹底禁止了所有不安全的加密算法，TLS 1.3目前支持的加密組件只有以下五種：

以TLS_AES_128_CCM_SHA256為例，TLS表明該加密組件用于TLS協議，AES表明使用AES對稱加密算法，128表示密鑰長度為128位，CCM表明分組加密模式，SHA256是HKDF過程使用的哈希算法。?
協商加密組件時，雙方只需要傳遞相應的value傳遞即可。由客戶端傳遞一個所有自己支持的加密組件的列表，由服務器將最終選定的加密組件值返還給對方完成協商。?
TLS 1.2中定義了多達37種的加密組件，大量使用了MD5、RC4、3DES等被證明不安全或者效率低下的加密算法。?
TLS 1.3僅支持速度快安全性強的加密標準算法AES，以及08年才提出的對性能消耗極低的CHACHA20。使用CHACHA20進行AEAD運算時，CHACHA20本身不能提供完整性校驗的功能，因此使用POLY1305——一種同樣不耗費性能的MAC算法來提供完整性校驗的功能。這些算法，包括協議中隨著算法使用的分組加密模式CCM和GCM，目前都是理論上安全的算法，不容易被攻擊者破解。

如何得出最終密鑰——PSK密鑰協商機制

協商出來加密算法，下一步則是協商出加密密鑰，TLS 1.3支持DH、PSK兩種密鑰協商機制，也支持同時使用兩者進行密鑰協商。?
如果雙方持有未過有效期的PSK鍵值對，則可以使用PSK進行密鑰協商。雙方傳遞一個結構體PSK_entry。該結構體包括的內容有：PSK對應名字（PSK_name）、用該PSK對之前的握手報文進行的HMAC計算結果（ PSK_identity）。?
具體的實施過程如下：

• 客戶端在CH報文的pre_key_share擴展中傳遞一個PSK_entry的數組，包含所有自己持有的PSK信息。
• 服務端接收到該數組后，首先根據PSK_name選擇一個想要使用的PSK，再使用自己持有的該PSK值計算HMAC值，若與PSK_identity一致，則說明雙方持有的PSK一致，否則服務器報錯。
• 服務端將選定的PSK_entry結構體在Server Hello中的pre_key_share擴展中返還給客戶端。協商完成，得到初始密鑰PSK

如果使用了PSK，則客戶端可以向服務端發送early_data，客戶端會選擇發送的PSK_entry數組中的第一個PSK計算early_trffic_key，因此，服務端也必須選擇第一個PSK，如果服務端拒絕接受early data，則返回其他的PSK_entry，客戶端丟棄已發送的ED報文。?
使用PSK密鑰協商，已經對雙方的身份做了一定的認證，不得再使用公鑰證書的認證方式，即CV/CR/CT報文都不會再發送。

如何得出最終密鑰——DHE密鑰協商機制

使用DHE擴展首先需要選定DH參數，對于有限域DH來說是g和p的值，對于橢圓域DH是橢圓曲線和基點的值，同選定加密組件一樣，TLS 1.3定義了幾組gp值，雙方只需要協商想要使用的pg對即可。?
在TLS 1.2中，g和p的值由雙方自己生成。TLS 1.3則定義了幾組g、p對，雙方只需要選擇想要使用的DH組即可。使用確定的參數值保證了DH密鑰協商過程具有足夠的安全性。?
具體實施過程與PSK的實施過程類似，由客戶端生成一個列表包含所有自己支持的DH組，為每個組生成一個DH密鑰交換的參數，將其組名和參數值封裝在key_share擴展中，服務端選定DH組后，返回一個封裝好的key_share，雙方根據交換的公鑰參數和自己持有的私鑰參數計算出DH最終密鑰。

理論上，客戶端應該將所有與密鑰協商有關的擴展（pre_shared_key、shared_key）都發送給服務端，服務端選定哪一種，再將對應選定的擴展返還給客戶端，如果服務端同時使用兩種密鑰協商，則返還所有擴展，如果客戶端沒有提供足夠的密鑰擴展，服務端發送HRR報文要求客戶端重新發送CH。

使用密鑰協商結果計算實際使用密鑰

TLS 1.3最大的特點就是對于不同的報文使用多種不同的密鑰。?
在TLS 1.2中只使用了兩種密鑰，一個用于完整性校驗，一個用于報文加密，同一連接不同方向使用的加密密鑰不一樣。?
TLS 1.3因為使用AEAD機制，不再需要使用MAC_key來進行完整性校驗，同時由于其他各種用途的加密需要，TLS 1.3的實施過程還可能計算或者使用以下幾種key：?
- handshake_key?
- early_traffic_key?
- resumption_key?
- exporter_key（導出密鑰，用于用戶自定義的其他用途）

這些密鑰都是由之前協商的密鑰材料計算而出，區別在于HKDF的計算次數不同，HKDF計算使用的哈希值不同。以會話密鑰application_key為例，以整個握手階段的報文作為輸入，計算四次HKDF導出最終使用的密鑰。?
同時，當加密的報文達到一定長度后，雙方發送KU報文重新計算application_key。

post-authentication機制

ost-authentication機制方便用戶確認是否向服務端提供自己的身份信息。

TLS 1.3支持服務端在握手結束之后再對客戶端發起身份的校驗。?
CH報文中有一個擴展字段post_handshake_anth。如果客戶端發送了此字段，則允許服務端在握手階段結束后再發起Certificate Request，客戶端會在收到CR之后再發送CT、 CV報文給服務端進行身份認證。?
p

Part 4-record子協議

TLS發送的報文由record層處理：

分片：TLS將接收到的報文分為一個個小的record后，對每個record單獨進行加密后轉發?
TLS 1.3協議定義了一系列規則，大致有幾點：?
- 每一個record的長度有一定限制。?
- 使用不同密鑰的消息不能在一個record中。所有可能提示key即將變更的握手信息都必須單獨發送（如：KU/SH/FI）。?
- 對不同種類的報文有不同的處理方式：?
- HM（handshake message）：不能為空，不能在傳遞一連串的HM record時夾雜其他類型的信息。?
- alert：每個alert報文都必須完整發送，不得分片。?
- application data：對TLS協議不可見，所以沒有對應的處理規則。

加密解密：使用AEAD加密機制和協商出來的加密算法對消息報文進行加密 。
AEADEncrypted = AEAD-Encrypt(write_key（即加密密鑰）, nonce, plaintext)

關于隨機數的獲取：?
雙方維護一個64位的sequence number，連接建立和每一次密鑰變更時，sequence number置0，此后隨傳遞的字節數增加?
加密時將sequence擴充到write_iv（也是由write_key導出的一個初始向量）的長度，再與write_iv做異或計算得到nonce

最后將數據傳遞出去時，record層會在密文頭部附加一小段明文信息來標識解密后明文長度等信息。

對方的record層收到該消息后，通過逆過程解密密文后轉發給上層協議。

3. TLS 1.3允許TLS對消息報文填充來阻止攻擊者獲知傳送消息的長度等信息。

填充時在末尾附上八個字節整數倍的全為0的二進制數據，對方收到該消息后，解密后從末尾 開始去掉0，當搜索到第一個不全為0的八字節數據，則結束。

Part 5-alert子協議

alert層負責處理TLS連接過程中的各種異常情況，對每種情況發送一個alert報文，報文中附加一些錯誤處理需要的必要信息，TLS 1.3中定義了30種alert報文。?
舉例來講：alert層的close_notify報文標志發送方打算關閉TLS連接，不再使用該加密信道傳遞任何信息，bad_record_mac可能表示AEAD解密時完整性校驗失敗。

Part 6-總結

TLS 1.3使用了復雜的密鑰導出過程，增強了最終使用的密鑰的安全性。同時簡化了所使用的加密算法，廢棄了RC4、3DES、MD5、SHA1、AES-CBC等加密算法，刪除了壓縮、重協商等具有漏洞的機制，大大精簡了協議。?
因此，TLS 1.3如果能夠得到普及，網絡數據的傳遞將會變得更加安全、隱秘，TLS 1.3的推廣需要每一位開發者、運營者的認可和支持。?
目前TLS 1.3雖然還在草案階段，但是其基本原理和思想已經應用在了實際生活中，chrome等瀏覽器都已準備好了對其的支持，期待TLS 1.3正式成為一個協議規范的那一天。

附錄：參考讀物

以下讀物可以幫助讀者對TLS 1.3有一些更深的理解?
1.?寫的很好的一篇博文，介紹了TLS協議的歷史和核心思想?
2.?微信基于TLS?1.3較早期草案設計的mmtls協議概述?
3.?cloud flare公司對TLS?1.3的介紹博文合集（英文）?
4.?TLS?1.3草案合集，可以從這里檢索到最新版的TLS1.3草案（英文）?
5.?16年NDSS會議研究TLS?1.3的論文合集（英文）

總結

以上是生活随笔為你收集整理的TLS 1.3科普——新特性与协议实现的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。