沈若愚 盧盛祺 趙運(yùn)磊

1(復(fù)旦大學(xué)軟件學(xué)院 上海 201203) 2(上海財(cái)經(jīng)大學(xué)信息管理與工程學(xué)院 上海 200433)

TLS1.3協(xié)議更新發(fā)展及其攻擊與防御研究

沈若愚1盧盛祺2趙運(yùn)磊1

1(復(fù)旦大學(xué)軟件學(xué)院 上海 201203)2(上海財(cái)經(jīng)大學(xué)信息管理與工程學(xué)院 上海 200433)

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

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

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

0 引 言

SSL/TLS協(xié)議是應(yīng)用范圍非常廣泛的密碼協(xié)議之一，其主要的目的是為網(wǎng)絡(luò)中通信的雙方建立一個(gè)安全的通信信道。而這個(gè)信道需要為通信雙方提供認(rèn)證、機(jī)密性和完整性。該協(xié)議也是實(shí)際應(yīng)用中的最復(fù)雜的密碼協(xié)議之一，擁有高度的復(fù)雜性，版本眾多，擴(kuò)展、變體、工作模式、參數(shù)算法協(xié)商復(fù)雜多變。

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

1 SSL/TLS協(xié)議簡介

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

1.1 SSL3.0-TLS1.3發(fā)展歷程

SSL/TLS的更新發(fā)展過程如表1所示。協(xié)議的具體內(nèi)容，詳見參考文獻(xiàn)[9-12]。RFC(Request For Comments)文檔是由互聯(lián)網(wǎng)工程任務(wù)組發(fā)布的一系列備忘錄，是用以記錄互聯(lián)網(wǎng)規(guī)范、協(xié)議及過程等的標(biāo)準(zhǔn)文件。

表1 SSL/TLS歷史版本

1.2 TLS1.3協(xié)議結(jié)構(gòu)

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

圖1 TLS協(xié)議所處位置

當(dāng)客戶端和服務(wù)器端雙方第一次建立連接時(shí)可通過握手協(xié)議協(xié)商協(xié)議版本，選擇密碼算法，認(rèn)證通信雙方，協(xié)商算法所需參數(shù)，且能防篡改。握手協(xié)議完成后，記錄協(xié)議用握手協(xié)議協(xié)商好的算法和參數(shù)對(duì)消息流進(jìn)行分塊加密。

1.2.1 握手協(xié)議

如圖2所示，握手協(xié)議有三個(gè)階段：

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

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

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

這三個(gè)階段完成后，便可進(jìn)行應(yīng)用層數(shù)據(jù)的傳輸，應(yīng)用層數(shù)據(jù)由流密鑰(traffic secret)加密后傳輸。

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

1.2.2 記錄協(xié)議

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

圖3 記錄協(xié)議流程

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

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

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

2 TLS1.3主要改變

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

2.1 握手層消息結(jié)構(gòu)的改變

從圖2握手協(xié)議的消息流可以看出，相較TLS1.2，握手協(xié)議的結(jié)構(gòu)發(fā)生了較大改變：移除“改變密碼規(guī)范”和“密鑰交換”消息；為通信雙方新增了幾個(gè)Hello擴(kuò)展消息且新增“請(qǐng)求重新握手”消息；“握手完成”消息對(duì)握手層的所有消息進(jìn)行哈希，進(jìn)一步保證了消息的完整性。握手協(xié)議從之前的四個(gè)交互步驟簡化為三個(gè)步驟。

2.2 算法的移除與更新

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

2.3 密鑰生成表

TLS握手協(xié)議協(xié)商生成一個(gè)或多個(gè)密鑰，如圖4所示，以這些密鑰作為輸入通過哈希密鑰推導(dǎo)提取函數(shù)和哈希密鑰推導(dǎo)擴(kuò)展函數(shù)推導(dǎo)出多個(gè)記錄層所需的密鑰。哈希密鑰推導(dǎo)提取函數(shù)按照箭頭方向從上接收參數(shù)做加鹽操作，從右邊接收因特網(wǎng)密鑰管理參數(shù)。密鑰擴(kuò)展函數(shù)有三個(gè)輸入值：密鑰、標(biāo)簽和握手消息。按照?qǐng)D4箭頭方向所示從上端接收參數(shù)作為第一個(gè)密鑰參數(shù)。

圖4 密鑰生成表

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

2.4 PSK

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

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

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

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

2.4.1 會(huì)話票據(jù)

在服務(wù)器給客戶端發(fā)送“握手完成”消息以后的任意時(shí)間里，服務(wù)器都可以給客戶端發(fā)送“會(huì)話票據(jù)”消息(如圖5灰色方框)。會(huì)話票據(jù)綁定了票據(jù)和會(huì)話恢復(fù)密鑰。會(huì)話票據(jù)(圖7)消息包含4個(gè)字段。后續(xù)握手協(xié)議中，客戶端可以在“預(yù)共享密鑰”消息中將密鑰名字(也即PSK ID)發(fā)送給服務(wù)器?？蛻舳瞬荒苤貜?fù)使用一個(gè)票據(jù)多次，且優(yōu)先使用最新的票據(jù)。

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

圖7 會(huì)話票據(jù)消息結(jié)構(gòu)

圖8 票據(jù)消息結(jié)構(gòu)

2.4.2 預(yù)共享密鑰

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

圖9 預(yù)共享秘鑰消息結(jié)構(gòu)

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

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

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

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

2.5 0-RTT

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

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

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

當(dāng)客戶端選擇PSK模式進(jìn)行認(rèn)證的時(shí)候，客戶端在發(fā)送“客戶端Hello”消息時(shí)必須發(fā)送“早期數(shù)據(jù)”、“預(yù)共享密鑰模式”和“預(yù)共享密鑰”消息?？蛻舳丝梢砸恢卑l(fā)送0-RTT應(yīng)用數(shù)據(jù)直到收到服務(wù)器的“握手完成”消息，這時(shí)客戶端需要發(fā)送“早期數(shù)據(jù)結(jié)束”預(yù)警警告。服務(wù)器收到客戶端的“早期數(shù)據(jù)”消息以后有三種表現(xiàn)形式:

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

2) 發(fā)送“請(qǐng)求重新握手”消息，讓客戶端重新發(fā)送Hello消息，該消息將不再包含“早期數(shù)據(jù)”消息。

3) 返回與之相應(yīng)的“早期數(shù)據(jù)”擴(kuò)展消息，接受0-RTT的早期數(shù)據(jù)。

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

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

3.1 針對(duì)握手層的攻擊

1) 降級(jí)攻擊

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

2) 重協(xié)商攻擊

其攻擊原理主要是因?yàn)橥ㄐ烹p方的身份不是和安全信道綁定的，因此攻擊者偽裝成客戶端與服務(wù)器進(jìn)行握手；建立了通信信道之后再將原客戶端要發(fā)送的握手信息接入這個(gè)安全信道中，完成再次握手，而通信雙方并不知情。

3) 防御措施

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

3.2 針對(duì)記錄層的攻擊

1) Lucky Thirteen攻擊

其攻擊原理是HMAC驗(yàn)證計(jì)算時(shí)，去掉填充信息之后消息的長度不同會(huì)導(dǎo)致計(jì)算時(shí)間上的區(qū)別。攻擊者對(duì)密文進(jìn)行針對(duì)性的修改之后，根據(jù)HMAC驗(yàn)證的處理時(shí)間長短可以獲取關(guān)于密文的信息。

2) POODLE攻擊

其攻擊原理主要是利用SSL3.0協(xié)議中 CBC 加密算法零值填充無規(guī)律且填充字符的完整性在解密時(shí)不能進(jìn)行驗(yàn)證的缺陷。

3) BEAST攻擊

主要利用CBC加密模式的鏈?zhǔn)浇Y(jié)構(gòu)，即除了第一條記錄之外，之后每條記錄進(jìn)行加密時(shí)的初始向量都是前一條記錄的最后一個(gè)加密塊。攻擊者通過某種方式夠獲取密文一個(gè)塊的信息，然后逐塊破解一段密文。

4) 防御措施

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

3.3 代碼實(shí)現(xiàn)方面的攻擊

在實(shí)現(xiàn)TLS協(xié)議的時(shí)候，應(yīng)用程序接口設(shè)計(jì)得較差，且由于標(biāo)準(zhǔn)文檔存在部分令人混淆的設(shè)置和選項(xiàng)，開發(fā)者通常會(huì)誤用、誤解相關(guān)參數(shù)和選項(xiàng)的使用以及返回值，造成程序?qū)崿F(xiàn)錯(cuò)誤。

1) Heartbleed攻擊

主要是程序員在調(diào)用memcpy()函數(shù)時(shí)沒有對(duì)緩沖區(qū)邊界進(jìn)行檢查而造成的信息泄露。

2) 防御措施

TLS1.3在附錄B中增加了許多代碼實(shí)現(xiàn)方面的注意事項(xiàng)，如：偽隨機(jī)數(shù)生成器的選取，握手協(xié)議某些字段需要留意的特殊取值，如何預(yù)防計(jì)時(shí)攻擊等。TLS1.3主要涉及協(xié)議標(biāo)準(zhǔn)的設(shè)計(jì)，代碼的實(shí)現(xiàn)主要還是依靠工程師，雙方都需引起重視。比如，為TLS庫提供模糊測(cè)試和敵手測(cè)試，設(shè)計(jì)一個(gè)簡潔穩(wěn)定的錯(cuò)誤匯報(bào)機(jī)制等。

3.4 其他攻擊手段

1) 時(shí)間差分攻擊

針對(duì)對(duì)稱算法和非對(duì)稱算法都有計(jì)時(shí)攻擊。其本質(zhì)是通過觀察不同數(shù)據(jù)的加解密時(shí)間差實(shí)現(xiàn)密鑰破解。

2) 公鑰證書驗(yàn)證缺失[15]

另一個(gè)常見的攻擊來源是公鑰證書及其信任鏈驗(yàn)證的缺失(尤其是基于移動(dòng)終端的SSL/TTL實(shí)現(xiàn))。

3) 防御措施

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

4 TLS1.3發(fā)展趨勢(shì)

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

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

實(shí)際應(yīng)用中，協(xié)議的安全與否主要由兩個(gè)方面決定：協(xié)議的設(shè)計(jì)與實(shí)現(xiàn)。目前針對(duì)協(xié)議設(shè)計(jì)的討論眾多，但代碼實(shí)現(xiàn)的安全性部分的考慮欠缺。本文作者希望互聯(lián)網(wǎng)工程任務(wù)組在制定新的標(biāo)準(zhǔn)的同時(shí)可以為協(xié)議的代碼實(shí)現(xiàn)人員提供一份說明文檔，詳盡說明協(xié)議實(shí)現(xiàn)過程中可能會(huì)遇到的問題。比如，提供一份詳細(xì)的消息狀態(tài)圖和協(xié)議應(yīng)用程序編程接口。標(biāo)注標(biāo)準(zhǔn)文檔中安全性較弱的部分。除了對(duì)協(xié)議的結(jié)構(gòu)的安全性分析與證明，也希望相關(guān)學(xué)者以及互聯(lián)網(wǎng)開發(fā)人員重視協(xié)議代碼安全實(shí)現(xiàn)這一方面的工作。

5 結(jié) 語

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

[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] 強(qiáng)小輝, 陳波, 陳國凱,等. OpenSSLHeartBleed漏洞分析及檢測(cè)技術(shù)研究[J]. 計(jì)算機(jī)工程與應(yīng)用, 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。國家自然科學(xué)基金項(xiàng)目(61472084)；上海市科委項(xiàng)目(16DZ1100200)。沈若愚，碩士生，主研領(lǐng)域：密碼與信息安全。盧盛祺，博士生。趙運(yùn)磊，教授。

TP3

A

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