TLS1.3協議更新發展及其攻擊與防御研究

沈若愚 盧盛祺 趙運磊

1(復旦大學軟件學院 上海 201203) 2(上海財經大學信息管理與工程學院 上海 200433)

TLS1.3協議更新發展及其攻擊與防御研究

沈若愚1盧盛祺2趙運磊1

1(復旦大學軟件學院 上海 201203)2(上海財經大學信息管理與工程學院 上海 200433)

SSL/TLS(Secure Sockets Layer /Transport Layer Security )協議旨在為網絡通信提供安全的信道，為通信雙方提供認證、機密性和完整性。由于協議的復雜及其設計和實現上的漏洞導致許多安全隱患，新版本TLS1.3的制定引起信息安全學術界和產業界廣泛的關注。概述TLS1.3的協議結構。在此基礎上，對TLS1.3幾個革新性的改變：密鑰編排表、PSK和0-RTT進行了系統性地分析與梳理。對近10年協議受到的攻擊按照協議的層次分類進行概述，提煉出每種攻擊的原理以及TLS1.3針對這些攻擊作出的應對措施。對TLS協議的未來發展作出預測并提出建議。

TLS1.3 SSL/TLS攻擊 0-RTT PSK 密鑰生成表

1(SchoolofSoftware,FudanUniversity,Shanghai201203,China)
2(SchoolofInformationManagementandEngineering,ShanghaiUniversityofFinaceandEconomics,Shanghai200433,China)

0 引 言

SSL/TLS協議是應用范圍非常廣泛的密碼協議之一，其主要的目的是為網絡中通信的雙方建立一個安全的通信信道。而這個信道需要為通信雙方提供認證、機密性和完整性。該協議也是實際應用中的最復雜的密碼協議之一，擁有高度的復雜性，版本眾多，擴展、變體、工作模式、參數算法協商復雜多變。

由于SSL/TLS本身的復雜性，版本更新的緩慢以及實現維護過程的不重視，協議的設計與實現過程存在許多漏洞。此外，因其保護數據安全的特殊性使得協議存在很大的攻擊價值，針對SSL/TLS出現的攻擊與日劇增：降級攻擊[1]、重協商攻擊[2]、Lucky Thirteen攻擊[3]、 POODLE攻擊[4]、BEAST攻擊[5]、 Heartbleed攻擊[6]、 時間差分攻擊[7]、因代碼實現問題產生的攻擊[8]等。這些攻擊造成的危害與影響面的廣泛為當下的網絡安全敲響一記警鐘。而TLS1.2版本的發布距今已有8年，從近10年針對協議的攻擊數量的增長來看，亟需重新制定TLS協議的1.3版本。TLS1.3協議的更新與發展過程值得信息安全學術界和產業界的廣泛關注。

1 SSL/TLS協議簡介

SSL起源于Netscape, SSL3.0[9]于1996年發布，對后續TLS的發展有著基本的指導作用。其確定了協議目標，整體的層次結構(主要由記錄協議和握手協議組成)以及消息流的順序。目前的最高版本為TLS1.2[10]。由于之前版本過于陳舊，存在許多的漏洞，協議遭受的攻擊越來越多，嚴重危及互聯網安全。互聯網工程任務組開始籌劃制定新的版本TLS1.3[11]。

1.1 SSL3.0-TLS1.3發展歷程

SSL/TLS的更新發展過程如表1所示。協議的具體內容，詳見參考文獻[9-12]。RFC(Request For Comments)文檔是由互聯網工程任務組發布的一系列備忘錄，是用以記錄互聯網規范、協議及過程等的標準文件。

表1 SSL/TLS歷史版本

1.2 TLS1.3協議結構

TLS1.3由三部分組成，握手協議、警告協議和記錄協議。如圖1灰色方框所示。其在TCP/IP協議中介于應用層協議和可靠的傳輸層協議之間，且獨立于應用層協議，因此可以置于很多不同的協議之下，如HTTP、FTP、SMTP、XMTP等。

圖1 TLS協議所處位置

當客戶端和服務器端雙方第一次建立連接時可通過握手協議協商協議版本，選擇密碼算法，認證通信雙方，協商算法所需參數，且能防篡改。握手協議完成后，記錄協議用握手協議協商好的算法和參數對消息流進行分塊加密。

1.2.1 握手協議

如圖2所示，握手協議有三個階段：

1) 密鑰交換：選擇協議版本和密碼算法，協商算法所需參數，為明文傳輸。

2) 服務器參數：建立其他的握手協議參數，如是否需要認證客戶端，消息由握手層流密鑰(handshake traffic secret)加密傳輸。

3) 認證：認證通信雙方(客戶端認證可選), 并保證握手消息的完整性，消息由握手層流密鑰加密傳輸。

這三個階段完成后，便可進行應用層數據的傳輸，應用層數據由流密鑰(traffic secret)加密后傳輸。

注： +：上一消息的擴展消息；*：可選發送；{}：用握手層流密鑰加密；[]：用流密鑰加密圖2 TLS握手協議消息流

1.2.2 記錄協議

記錄協議位于握手協議下層，發送方從高層接受任意長度的非空數據，對其進行合并或分塊處理，然后利用帶有輔助數據的認證加密AEAD(authenticated encryption with associated data)進行加密傳輸。接收方接收數據后對其進行解密和驗證，重組后再傳送給高層用戶。記錄協議得到要發送的消息之后，進行如圖3所示的兩個步驟的處理。

圖3 記錄協議流程

分片：把上層數據分片或合并成易于處理的數據分組，大小不超過214字節。記錄協議的數據類型有三種：握手消息，應用數據，警告消息。警告消息的級別有兩種：一種是預警錯誤，用來指示連接的正常有序關閉或者0-RTT早期數據發送結束，對通信過程沒有影響；一種是致命錯誤，用來指示連接的非正常關閉，收到這類警告消息后通信雙方應立即中斷會話，不再收發消息。注意:對記錄層消息進行分片處理時不能對警告消息進行分塊處理。此外，握手消息和警告消息的消息長度不能為0，應用數據的消息長度可以為0，用來防范針對流量分析的攻擊。

載荷保護：將明文數據通過AEAD認證加密算法加密為密文，密文數據的長度略大于明文數據長度。明文數據結構由消息片段，數據類型和任意長度的填充0值這三個部分組成，作為AEAD的一個輸入值計算得到加密內容。TLS密文數據結構包括四個部分：數據類型、協議版本、消息長度和加密內容。其中數據類型字段一直都被設置為應用數據，真實的數據類型可以從明文的數據類型獲取，該字段是為了兼容之前版本而存在。協議版本與明文消息的協議版本功能一模一樣，一直被設置為0x0301(TLS1.0)，真實的協議版本可以從客戶端和服務器端的Hello消息獲取。因此，TLS密文中的數據類型和協議版本這兩個字段在后續版本中可能會被除去。

0值填充主要是為發送方隱藏真實數據長度而設計。接收方解密密文后，從后往前讀取數據，直到遇到非0的值，即明文的數據類型這一字段。

2 TLS1.3主要改變

TLS1.3從2014年4月17日起開始更新，至今更新到TLS1.3 Draft18[13]版本。本節將深入梳理并討論TLS1.3相對于TLS1.2的幾個革新性的改變。

2.1 握手層消息結構的改變

從圖2握手協議的消息流可以看出，相較TLS1.2，握手協議的結構發生了較大改變：移除“改變密碼規范”和“密鑰交換”消息；為通信雙方新增了幾個Hello擴展消息且新增“請求重新握手”消息；“握手完成”消息對握手層的所有消息進行哈希，進一步保證了消息的完整性。握手協議從之前的四個交互步驟簡化為三個步驟。

2.2 算法的移除與更新

計算機的軟硬件各方面性能都得到了極大的提升，計算速度以驚人的速度在增長，攻擊方法也一直在涌現。因此，之前認為安全的算法于近期及將來都不能確保數據安全，亟需選擇可靠性、安全性更高的算法來替換易被攻擊的算法。TLS1.3移除的算法主要有: DH、RC4、記錄層壓縮算法、重協商、一些不安全的利用率不高的橢圓曲線算法，以及哈希算法(如MD5、SHA-1、SHA-224等)。新引入的算法有：AEAD算法, 以及從RFC4492 (ECC Cipher Suites for TLS)中引入CFRG曲線和簽名算法等。

2.3 密鑰生成表

TLS握手協議協商生成一個或多個密鑰，如圖4所示，以這些密鑰作為輸入通過哈希密鑰推導提取函數和哈希密鑰推導擴展函數推導出多個記錄層所需的密鑰。哈希密鑰推導提取函數按照箭頭方向從上接收參數做加鹽操作，從右邊接收因特網密鑰管理參數。密鑰擴展函數有三個輸入值：密鑰、標簽和握手消息。按照圖4箭頭方向所示從上端接收參數作為第一個密鑰參數。

圖4 密鑰生成表

由于不同的密碼方案存在不同的安全性限制，需要為不同的密碼算法設置各自的密鑰更新時間限度。可結合握手層的“密鑰更新”消息告知通信雙方及時更新密鑰。

2.4 PSK

PSK預共享密鑰交換模式主要是為了簡化頻繁通信的雙方握手協議的認證過程：如圖5所示，共享有效“會話票據”(見2.4.1)的通信雙方不用發送“證書”和“證書認證”消息。第一次握手時，客戶端和服務器端建立通信，共享會話票據。連接斷開后，客戶端再次與服務器建立通信時可以通過PSK進行認證，只有真實的通信雙方才能解密會話票據得到票據，知道相應的會話恢復密鑰，后續才能導出加密應用數據的流密鑰。如圖6所示，后續握手階段，客戶端通過“預共享密鑰模式”消息告訴服務器其選擇的密鑰交換模式，通過“預共享密鑰”告知服務器PSK IDs，這兩個消息必須發送。客戶端可以選擇給服務器發送“密鑰共享”消息，讓服務器選擇是否接受會話恢復，若不接受，可回退進行完整的握手協議。

圖5 PSK消息流(第一次握手)

如果使用PSK模式，客戶端必須發送“預共享密鑰模式”(見2.4.2)消息。預共享密鑰交互模式有兩種：(EC)DHE-PSK和純PSK模式。前一種模式在減少數據傳輸時延的同時還可以保證前向安全，而后一種模式則不能保證。

注：+：上一消息的擴展消息；*：可選發送；{}：用握手流密鑰加密；[]：用流密鑰加密圖6 PSK消息流(第二次握手)

2.4.1 會話票據

在服務器給客戶端發送“握手完成”消息以后的任意時間里，服務器都可以給客戶端發送“會話票據”消息(如圖5灰色方框)。會話票據綁定了票據和會話恢復密鑰。會話票據(圖7)消息包含4個字段。后續握手協議中，客戶端可以在“預共享密鑰”消息中將密鑰名字(也即PSK ID)發送給服務器。客戶端不能重復使用一個票據多次，且優先使用最新的票據。

為了加強安全性，為票據設置了一個32比特的生命周期，最長時長為7天。票據生命加值是一個隨機生成的32比特的數值。由于會話票據是加密傳輸，而預共享秘鑰是明文傳輸，客戶端可利用這個加值來混淆PSK ID的真實票據時長。票據(圖8)由服務器創建，其本身一個用于數據庫查詢的關鍵字或者是一串密文，只有服務器自身才能查詢或解密PSK ID恢復之前的會話狀態。包含四個字段，密鑰名字也即“預共享密鑰”消息中的PSK ID，方便服務器根據ID快速地找到自己簽發過的票據；加密狀態字段主要用來存儲第一次握手的狀態信息；MAC值防止票據被攻擊者篡改；IV用作計算MAC值和加密狀態的初始向量輸入。文獻[14]提供了票據的構成方案和安全性分析。

圖7 會話票據消息結構

圖8 票據消息結構

2.4.2 預共享密鑰

“預共享密鑰”擴展消息(圖9)用來發送PSK的ID值。客戶端給服務器端發送一個IDs序列，服務器端從中選取一個ID返回給客戶端，如果沒有合適的值，則發送一個警告消息。如果與“早期數據”消息一起發送，將同時開啟0-RTT交互模式。

圖9 預共享秘鑰消息結構

IDs(客戶端)：客戶端提供給服務器端進行選擇的一列ID值。

ID(服務器端)：服務器端從客戶端提供的IDs中選取的一個ID值。

混淆票據時長：客戶端收到會話票據的時間加上會話票據的票據生命加值字段。由于預共享密鑰是明文傳輸，所以這一策略隱藏了真實的票據時長。

綁定值：綁定值利用HMAC算法建立了一個PSK和當前的握手消息的綁定。在服務器接收客戶端PSK認證之前，首先要驗證這個綁定值。如果這個值不存在或者驗證失敗，服務器必須終止會話，這個認證過程主要是為了防止中間人攻擊。握手消息從“客戶端Hello消息”開始到“預共享密鑰的”ID字段為止，但不包含綁定值本身。例如：客戶端發送一個Hello1消息, 綁定值的HMAC計算將只包含這個Hello1消息；如果客戶端發送一個Hello1消息，服務器回了一個“請求重新握手”消息，客戶端再發送一個Hello2消息， 綁定值的HMAC計算將包含：Hello1 + 請求重新握手 + Hello2。

2.5 0-RTT

TLS1.3 支持“0-RTT(RoundTripTime)” 模式，客戶端在發送“客戶端Hello”等消息時可一并發送應用層的數據，因此減少了握手延遲。0-RTT模式必須和PSK模式一起使用，0-RTT數據由PSK導出的早期流密鑰加密傳輸。0-RTT的消息交互過程如圖10所示。

注：+：上一個消息的擴展消息；*：消息可選發送；():用客戶端早期流密鑰加密；{}：用握手層流密鑰加密；[]：用流密鑰加密圖10 0-RTT握手協議消息流

這種模式沒有完整版的TLS握手協議安全：1) 0-RTT數據不能保證前向安全，因為是用PSK導出的早期流密鑰加密; 2) 不能保證不受重放攻擊，除非服務器采取協議外的防范措施。因此，各方針對0-RTT的討論較為激烈。反對方認為：1) 0-RTT存在上述兩個威脅，影響協議的安全性；2) 1-RTT模式已經能滿足要求，沒必要引入隱患；3) 協議的實現者不一定精通密碼學知識，盲目相信標準文檔的安全性，且為了追求效率使用0-RTT，忽略了需要采取協議外的安全策略這一需求。支持方則堅持：1) 可以為了效率，對安全性做出適當讓步，且谷歌公司已經在使用這一方案且效果良好；2) 不宜直接反對并廢除這一機制，應該給通信雙方選擇的權利；3) 可以把0-RTT模式作為一個擴展文檔，與TLS1.3標準文檔區分，需要使用的時候即可作為擴展包添加使用。

當客戶端選擇PSK模式進行認證的時候，客戶端在發送“客戶端Hello”消息時必須發送“早期數據”、“預共享密鑰模式”和“預共享密鑰”消息。客戶端可以一直發送0-RTT應用數據直到收到服務器的“握手完成”消息，這時客戶端需要發送“早期數據結束”預警警告。服務器收到客戶端的“早期數據”消息以后有三種表現形式:

1) 忽略這個消息，不做任何應答，也即回歸正常的1-RTT握手。

2) 發送“請求重新握手”消息，讓客戶端重新發送Hello消息，該消息將不再包含“早期數據”消息。

3) 返回與之相應的“早期數據”擴展消息，接受0-RTT的早期數據。

3 SSL/TLS攻擊以及TLS1.3防御措施

今年來，隨著互聯網的使用越加廣泛和方便，越來越多的數據和信息通過互聯網進行傳輸。與此同時針對SSL/TLS協議的攻擊方法與日俱增，安全問題也逐漸浮出水面。本節主要從協議的兩層結構以及代碼實現這三個方面對近幾年出現的攻擊進行分類概述，并討論TLS1.3針對這些攻擊做出的改進方式。

3.1 針對握手層的攻擊

1) 降級攻擊

降級攻擊包括針對協議版本和針對密碼中可用加密方式的回滾攻擊。由于TLS1.2及之前的握手協議中通信雙方以明文傳輸的方式協商密碼算法，中間人攻擊者可能通過冒充通信的某一方，誘使另一方修改密碼算法列表，將協議版本或加密算法降低到不安全的卻仍被雙方都支持的版本，使得雙方通信時使用安全性較低的協議版本和較弱的加密算法。

2) 重協商攻擊

其攻擊原理主要是因為通信雙方的身份不是和安全信道綁定的，因此攻擊者偽裝成客戶端與服務器進行握手；建立了通信信道之后再將原客戶端要發送的握手信息接入這個安全信道中，完成再次握手，而通信雙方并不知情。

3) 防御措施

針對降級攻擊，TLS1.3移除了許多不安全的算法，并且在服務器Hello消息的隨機數字段中內嵌一個降級攻擊保護機制。另外，在握手結束消息中對整個握手協議消息流內容進行哈希計算出消息認證碼，防止消息被中間人篡改。針對重協商攻擊，TLS1.3移除了重協商這一功能。

3.2 針對記錄層的攻擊

1) Lucky Thirteen攻擊

其攻擊原理是HMAC驗證計算時，去掉填充信息之后消息的長度不同會導致計算時間上的區別。攻擊者對密文進行針對性的修改之后，根據HMAC驗證的處理時間長短可以獲取關于密文的信息。

2) POODLE攻擊

其攻擊原理主要是利用SSL3.0協議中 CBC 加密算法零值填充無規律且填充字符的完整性在解密時不能進行驗證的缺陷。

3) BEAST攻擊

主要利用CBC加密模式的鏈式結構，即除了第一條記錄之外，之后每條記錄進行加密時的初始向量都是前一條記錄的最后一個加密塊。攻擊者通過某種方式夠獲取密文一個塊的信息，然后逐塊破解一段密文。

4) 防御措施

TLS1.3采用的AEAD算法可以避免Lucky Thirteen攻擊。TLS1.3不允許將版本回退到SSL3.0，且將密文分組鏈接(CBC)加密模式更換為計數器模式(CTR)，避免了后兩種攻擊。

3.3 代碼實現方面的攻擊

在實現TLS協議的時候，應用程序接口設計得較差，且由于標準文檔存在部分令人混淆的設置和選項，開發者通常會誤用、誤解相關參數和選項的使用以及返回值，造成程序實現錯誤。

1) Heartbleed攻擊

主要是程序員在調用memcpy()函數時沒有對緩沖區邊界進行檢查而造成的信息泄露。

2) 防御措施

TLS1.3在附錄B中增加了許多代碼實現方面的注意事項，如：偽隨機數生成器的選取，握手協議某些字段需要留意的特殊取值，如何預防計時攻擊等。TLS1.3主要涉及協議標準的設計，代碼的實現主要還是依靠工程師，雙方都需引起重視。比如，為TLS庫提供模糊測試和敵手測試，設計一個簡潔穩定的錯誤匯報機制等。

3.4 其他攻擊手段

1) 時間差分攻擊

針對對稱算法和非對稱算法都有計時攻擊。其本質是通過觀察不同數據的加解密時間差實現密鑰破解。

2) 公鑰證書驗證缺失[15]

另一個常見的攻擊來源是公鑰證書及其信任鏈驗證的缺失(尤其是基于移動終端的SSL/TTL實現)。

3) 防御措施

TLS1.3采用AEAD算法，該算法會對待加密的明文進行填充，隱藏真實數據長度，混淆了加解密過程與時間的關聯性。此外，TLS1.3豐富了證書鏈表這一部分的說明。

4 TLS1.3發展趨勢

TLS1.3目前一直處于更新狀態，還有許多工作未完成，專家學者正從多方面對協議的制定進行激烈的討論：小到算法的選取、參數長度的范圍確定，大到新機制的引入、協議安全性證明。

縱觀當前討論熱點可總結出以下幾個發展趨勢：1) 密碼算法的選取、移除與更新；2) 密碼算法密鑰的長度以及相關參數范圍的設置(最大值，最小值)；3) 0-RTT和PSK模式的進一步優化；4) TLS協議擴展文件的更新；5) 商討、解決TLS 1.3 draft文檔中的open issues；6) 握手層協議安全性證明[16]以及安全性分析[17]這一方向的研究較難，但非常重要。

實際應用中，協議的安全與否主要由兩個方面決定：協議的設計與實現。目前針對協議設計的討論眾多，但代碼實現的安全性部分的考慮欠缺。本文作者希望互聯網工程任務組在制定新的標準的同時可以為協議的代碼實現人員提供一份說明文檔，詳盡說明協議實現過程中可能會遇到的問題。比如，提供一份詳細的消息狀態圖和協議應用程序編程接口。標注標準文檔中安全性較弱的部分。除了對協議的結構的安全性分析與證明，也希望相關學者以及互聯網開發人員重視協議代碼安全實現這一方面的工作。

5 結 語

近年來，互聯網安全性問題頻發，SSL/TLS的安全性研究引起廣泛關注。本文從跟進TLS協議新版本的制定出發，對TLS1.3幾個革新性的改變：密鑰編排表、PSK和0-RTT進行了分析與梳理，詳細地描繪了協議的結構以及握手層消息的交互過程。同時對近十年協議受到的攻擊按照協議的層次分類進行概述，提煉出每種攻擊的原理以及TLS1.3針對這些攻擊做出的應對措施。最后對TLS協議的更新發展趨勢進行總結和預測。伴隨著TLS1.3的制訂，預計未來5年將迎來TLS研究的新機遇期。在未來的研究中將繼續關注新的密碼協議的設計、安全性建模與分析、安全實現和形式化驗證、新型漏洞和攻擊發展等。

[1] Wagner D, Schneier B. Analysis of the ssl 3[J]. Proceedings of the Second Unix Workshop on Electronic Commerce, 1996, 28(28):29-40.

[2] Giesen F, Kohlar F, Stebila D. On the security of TLS renegotiation[C]//Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security. ACM, 2013: 387-398.

[3] Fardan N J A, Paterson K G. Lucky Thirteen: Breaking the TLS and DTLS Record Protocols[C]// IEEE Symposium on Security and Privacy. IEEE Computer Society, 2013:526-540.

[4] M?ller B, Duong T, Kotowicz K. This POODLE bites: exploiting the SSL 3.0 fallback[OL]. 2014. https://www.openssl.org/～bodo/ssl-poodle.pdf.

[5] Duong T, Rizzo J. Here Come The ⊕ Ninjas[J]. Unpublished Manuscript, 2011.

[6] 強小輝, 陳波, 陳國凱,等. OpenSSLHeartBleed漏洞分析及檢測技術研究[J]. 計算機工程與應用, 2016, 52(9):88-95.

[7] Brumley D, Dan B. Remote timing attacks are practical[J]. Computer Networks, 2005, 48(5):701-716.

[8] Georgiev M, Iyengar S, Jana S, et al. The most dangerous code in the world: validating SSL certificates in non-browser software[C]// Proceedings of the 2012 ACM conference on Computer and communications security. ACM, 2012:38-49.

[9] Freier A, Karlton P, Kocher P. The SSL 3.0 Protocol[Z]. November 1996.

[10] Allen C, Dierks T. The TLS protocol version 1.0[Z]. 1999.

[11] Dierks T, Rescorla E. The Transport Layer Security(TLS) Protocol Version 1.1[R]. RFC 4346 , DOI 10.17487/RFC4346 , April 2006.

[12] Dierks T, Rescorla E. The Transport Layer Security(TLS) Protocol Version 1.2[R]. RFC 5246 , DOI 10.17487/RFC5246 , August 2008.

[13] Rescorla E. The Transport Layer Security (TLS) Protocol Version 1.3[R]. draft-ietf-tls-tls13-18, 2016.

[14] Salowey J. Transport Layer Security (TLS) Session Resumption without Server-Side State[Z]. Transport, 2006.

[15] Clark J, Oorschot P C V. SoK: SSL and HTTPS: Revisiting Past Challenges and Evaluating Certificate Trust Model Enhancements[C]// Security and Privacy. IEEE, 2013:511-525.

[16] Bhargavan K, Fournet C, Kohlweiss M, et al. Proving the TLS Handshake Secure (as it is)[J]. Lecture Notes in Computer Science, 2014, 8617:235-255.

[17] Dowling B, Fischlin M, Nther F, et al. A Cryptographic Analysis of the TLS 1.3 Handshake Protocol Candidates[C]// The, ACM Sigsac Conference. ACM, 2015:1197-1210.

THEDEVELOPMENTSOFTLS1.3ANDITSATTACKANDDEFENSE

Shen Ruoyu1Lu Shengqi2Zhao Yunlei1

Secure Sockets Layer/Transport Layer Security (SSL/TLS) is intended to provide a secure channel for network communications, providing authentication, confidentiality and integrity. Due to the complexity and loopholes in the design and implementation of protocol leading to many security risks, the development of the new version of TLS1.3 caused widespread concern in the information security academia and industry. We outlined the protocol structure of TLS1.3. On this basis, several innovative changes of TLS1.3 were systematically analysed and combed, such as key schedule, PSK and 0-RTT. We reviewed the attacks

by the protocols for the last 10 years, and extracted the principle of each attack and TLS1.3 response to these attacks. And we made some predictions about the future development of TLS and make some recommendations.

TLS1.3 SSL/TLS attack 0-RTT PSK Key schedule

2017-02-20。國家自然科學基金項目(61472084)；上海市科委項目(16DZ1100200)。沈若愚，碩士生，主研領域：密碼與信息安全。盧盛祺，博士生。趙運磊，教授。

TP3

A

10.3969/j.issn.1000-386x.2017.11.049