高志偉， 耿金陽(yáng)

(石家莊鐵道大學(xué) 信息科學(xué)與技術(shù)學(xué)院，河北 石家莊 050043)

基于優(yōu)先級(jí)策略的TLS握手協(xié)議研究

高志偉， 耿金陽(yáng)

(石家莊鐵道大學(xué) 信息科學(xué)與技術(shù)學(xué)院，河北 石家莊 050043)

當(dāng)大量的用戶通過(guò)TLS協(xié)議訪問(wèn)服務(wù)器時(shí)，會(huì)帶來(lái)較大的負(fù)擔(dān)，同時(shí)瀏覽器進(jìn)程關(guān)閉時(shí)會(huì)清除用戶所保存下來(lái)的session信息，當(dāng)再次連接時(shí)，又需要完整的握手過(guò)程。對(duì)TLS協(xié)議進(jìn)行分析,在經(jīng)典握手協(xié)議的基礎(chǔ)上提出了服務(wù)器端session的緩存機(jī)制的改進(jìn)，提高了服務(wù)器的緩存利用率；并在客戶端實(shí)現(xiàn)了運(yùn)用cookie進(jìn)行會(huì)話重用。結(jié)合Java相關(guān)技術(shù)，對(duì)其TLS環(huán)境進(jìn)行配置，并在其上進(jìn)行了服務(wù)器端與客戶端的實(shí)驗(yàn)，然后對(duì)經(jīng)典TLS握手協(xié)議進(jìn)行效率測(cè)試。

TLS；session； 會(huì)話重用

0 引言

IE瀏覽器和服務(wù)器在傳輸?shù)倪^(guò)程中使用TLS(Transport layer Security)協(xié)議來(lái)保證敏感數(shù)據(jù)的安全性并且驗(yàn)證數(shù)據(jù)的準(zhǔn)確性，但是TLS協(xié)議也經(jīng)常為客戶端和服務(wù)器端帶來(lái)困擾。TLS中不正確的配置與證書(shū)警告是非常常見(jiàn)的，他們可以導(dǎo)致數(shù)據(jù)的泄露并且可能會(huì)引起其他的問(wèn)題。對(duì)于TLS協(xié)議使用者來(lái)說(shuō)，可能會(huì)面臨導(dǎo)致“會(huì)話欺騙”(session hijacking)的情況，并且TLS也帶來(lái)了相對(duì)較重的負(fù)擔(dān)。通過(guò)TLS建立連接的服務(wù)器站點(diǎn)當(dāng)然也會(huì)使用戶感到延遲。此外，占用用戶的資源，即使是很小的額外的用戶延遲，也會(huì)給網(wǎng)站帶來(lái)網(wǎng)絡(luò)擁堵，利用率降低，額外的開(kāi)銷(xiāo)等[1]。

在用戶和服務(wù)器開(kāi)始發(fā)送數(shù)據(jù)時(shí)，標(biāo)準(zhǔn)的TLS握手協(xié)議中需要通過(guò)兩次驗(yàn)證性對(duì)話，這將使網(wǎng)絡(luò)延時(shí)增加，進(jìn)而影響用戶體驗(yàn)并影響到TLS的應(yīng)用與推廣。此外，IE 瀏覽器還必須通過(guò)證書(shū)廢除協(xié)議來(lái)驗(yàn)證服務(wù)證書(shū)的有效性(比如:在線證書(shū)狀態(tài)查詢協(xié)議OCSP)[2]，這就又增加了等待時(shí)間。因此減少TLS握手等待時(shí)間是很關(guān)鍵的，這會(huì)使TLS得到更廣泛的使用并加強(qiáng)網(wǎng)絡(luò)的安全性。

國(guó)際上很多提案都通過(guò)減少握手驗(yàn)證數(shù)據(jù)傳輸回合的辦法達(dá)到了提高TLS性能的作用。較有代表性的如：Fast-track通過(guò)客戶端緩存長(zhǎng)效性參數(shù)減少了一個(gè)握手環(huán)節(jié)[3]；TLS False Start通過(guò)提前記錄安全算法套件信息減去一個(gè)回合[4]；最有效的Snap Start方案通過(guò)客戶端提前完成與服務(wù)器的完整握手并緩存靜態(tài)參數(shù)數(shù)據(jù)，使再次連接握手時(shí)免去了握手環(huán)節(jié)[5]；以及2011年由Lin-Shung Huang、Emily Stark、Dinesh Israni、Collin Jackson等人提出的perfetching and pervalidating提前取得證書(shū)及驗(yàn)證、TLS snap start、會(huì)話重用等機(jī)制[6]。RFC4507文檔中提出安全使傳輸層(TLS)服務(wù)器恢復(fù)會(huì)話不需要讓客戶端會(huì)話保持連接狀態(tài)的機(jī)制。TLS服務(wù)器封裝會(huì)話狀態(tài)變成“票據(jù)”并將其轉(zhuǎn)發(fā)給客戶端?？蛻舳丝梢噪S后使用所獲得的“票據(jù)”恢復(fù)會(huì)話[7]。

但是不論哪種方案都有各種各樣的附加代價(jià)，比如Fast-track、False需要客戶端提供緩存空間才能減少連接的時(shí)間，RFC4507中提出的機(jī)制需要大量占用服務(wù)器端的內(nèi)存才能保持連接狀態(tài),而且當(dāng)大量的用戶通過(guò)TLS協(xié)議訪問(wèn)服務(wù)器時(shí)，會(huì)帶來(lái)較大的負(fù)擔(dān)，以及瀏覽器進(jìn)程關(guān)閉時(shí)會(huì)清除用戶所保存下來(lái)的session信息，當(dāng)再次連接時(shí)，又需要完整的握手過(guò)程。這些問(wèn)題都有待技術(shù)人員的進(jìn)一步解決。

現(xiàn)從經(jīng)典握手協(xié)議過(guò)程入手，模擬會(huì)話重用過(guò)程，并根據(jù)現(xiàn)在研究現(xiàn)狀，分別從服務(wù)器端提出緩存機(jī)制的改進(jìn)，客戶端提出運(yùn)用cookie進(jìn)行會(huì)話重用的實(shí)現(xiàn)，對(duì)于服務(wù)器來(lái)說(shuō)，邏輯上擴(kuò)充了其緩存，并且提高了緩存利用率；客戶端來(lái)說(shuō)，減少了再次進(jìn)行完整握手過(guò)程的時(shí)間，提高了TLS在實(shí)際中使用的效率。

1 TLS經(jīng)典握手協(xié)議分析

完整TLS握手過(guò)程：完整的握手過(guò)程是之前沒(méi)有通信過(guò)的雙方建立TLS的過(guò)程，該過(guò)程也對(duì)絕大多數(shù)情況適用。圖1 給出了完整的握手過(guò)程消息流[6]。

TLS是用于在客戶端和服務(wù)器端之間對(duì)其通信進(jìn)行加密和認(rèn)證的協(xié)議。為了建立起一個(gè)安全可靠的連接，客戶端和服務(wù)器端都必須對(duì)對(duì)方身份進(jìn)行認(rèn)證(通過(guò)有Certificate Authority發(fā)布的證書(shū)來(lái)認(rèn)證)，然后才可以進(jìn)行握手過(guò)程。利用在握手過(guò)程商量好的ciper suite，客戶端和服務(wù)器端商量出密鑰用以保證握手過(guò)程后的數(shù)據(jù)通信的安全。

在web通信過(guò)程中，TLS保證了web服務(wù)器和web站點(diǎn)之間的http通信的隱私性和數(shù)據(jù)保密性。圖1顯示了一個(gè)完整的TLS握手過(guò)程，其中用了RSA加密算法，并且沒(méi)有客戶端的證書(shū)驗(yàn)證。ClientHello和ServerHello用于客戶端和服務(wù)器端之間進(jìn)行信息交換從而達(dá)成一個(gè)約定，約定的內(nèi)容包括：要用哪個(gè)版本的TLS以及用哪個(gè)cipter suite。這些初始信息也允許客戶端和服務(wù)器端進(jìn)行隨機(jī)數(shù)(從session key提取出來(lái))的交換?？蛻舳说碾S機(jī)數(shù)包括客戶端的時(shí)間信息。當(dāng)服務(wù)器端接收到ClientKeyExchange消息后，雙方都可以直接知道主密鑰(master key)，主密鑰接下來(lái)是用來(lái)加密數(shù)據(jù)的。ChangeCiperSpec消息表示另一方接下來(lái)發(fā)送的信息將會(huì)用商量好的ciper suite來(lái)加密。Finish信息包含著整個(gè)握手過(guò)程的哈希值，用來(lái)保證雙方在握手過(guò)程沒(méi)有被黑客攻擊篡改信息。經(jīng)歷二輪的來(lái)回通信，并且接收到加密的http的請(qǐng)求，客戶端才會(huì)發(fā)送第一個(gè)數(shù)據(jù)信息。交換的過(guò)程如圖2所示。

圖1 標(biāo)準(zhǔn)TLS握手過(guò)程(用RSA密鑰交換但沒(méi)有客戶端的證書(shū)認(rèn)證) 圖2 TLS握手會(huì)話重用過(guò)程

TLS連接也允許恢復(fù)以前的會(huì)話。如果以前的會(huì)話(session)將要被恢復(fù)，服務(wù)器端會(huì)在ServerHello信息中提供一個(gè)會(huì)話id。為了恢復(fù)一個(gè)會(huì)話，客戶端首先要有以前保存的session id并且在恢復(fù)會(huì)話握手過(guò)程中將其放在ClientHello信息中。

服務(wù)器端可以通過(guò)會(huì)話id來(lái)判斷特殊的連接，會(huì)話id在ServerHello消息中有自己專門(mén)的字段?？蛻舳撕头?wù)器端在雙方都同意的情況可以進(jìn)行會(huì)話的重用?？蛻舳嗽谧约喊l(fā)送消息中存放會(huì)話id，表示他希望進(jìn)行會(huì)話重用，服務(wù)端通過(guò)在回復(fù)的ServerHello消息中存放同樣的會(huì)話id，表示他接受了客戶端的請(qǐng)求。然后客戶端和服務(wù)器端直接進(jìn)行Change CipherSpec和Finish消息的交換。(按照以前會(huì)話商量好的參數(shù)和密鑰)。

2 服務(wù)器端緩存機(jī)制基于優(yōu)先級(jí)策略的改進(jìn)方案

如果session按照100byte估算[6]。假設(shè)一臺(tái)服務(wù)器有4G內(nèi)存可用于應(yīng)用緩存，那么一天中該服務(wù)器最多能存儲(chǔ)的session數(shù)為4×10e8個(gè)。當(dāng)然，這是最壞的情況，因?yàn)檎Ｇ闆r中在一天中會(huì)有重用的會(huì)話。按照1 000次/s握手，每個(gè)session為100byte那么服務(wù)器Cache會(huì)以3 MB/min增加[8]。

在訪問(wèn)量較大的服務(wù)器上這會(huì)給服務(wù)器帶來(lái)更大的負(fù)擔(dān)，出于這一原因，在運(yùn)用時(shí)就必須要降低Session可緩存的時(shí)間。如亞馬遜網(wǎng)站將Session緩存的有效時(shí)間設(shè)定為2 min, mod_ssl中也默認(rèn)設(shè)定為5 min。因此有需要對(duì)服務(wù)器的緩存機(jī)制做出一定的改變，以提高服務(wù)器應(yīng)對(duì)大量客戶端的訪問(wèn)。

本節(jié)就這一問(wèn)題，利用操作系統(tǒng)中LRU置換算法對(duì)服務(wù)器緩存進(jìn)行維護(hù)操作，從而提高服務(wù)器的緩存利用率。

2.1 最近最久未使用置換算法(LRU)

操作系統(tǒng)中，虛擬存儲(chǔ)技術(shù)是目前普遍采用的存儲(chǔ)管理技術(shù)，它的意義就在于從邏輯上擴(kuò)充其容量。其中請(qǐng)求分頁(yè)存儲(chǔ)中新的頁(yè)面替換內(nèi)存中已有的頁(yè)面，如何挑選，則需要根據(jù)置換算法來(lái)確定。本文將請(qǐng)求分頁(yè)存儲(chǔ)管理中置換算法應(yīng)用到TLS握手協(xié)議中服務(wù)器端，將其置換的頁(yè)面變?yōu)閟ession，使其邏輯上擴(kuò)充緩存的容量，提高其緩存利用率。

最佳置換算法的和先進(jìn)先出置換算法在頁(yè)面置換算法中是兩種極端的算法。最佳置換算法是一種理想化的算法，必然具有最好的性能，但在現(xiàn)實(shí)中并不能實(shí)現(xiàn)。而先進(jìn)先出置換算法則是最容易實(shí)現(xiàn)的一種算法，但是它在性能上也是最差的，在實(shí)際中也很少使用。最近最久未使用(LRU)置換算法無(wú)論在性能上還是在實(shí)現(xiàn)上都介于這兩種算法之間。LRU置換算法所根據(jù)的原理是：當(dāng)頁(yè)面(本文為session)調(diào)入內(nèi)存后，由于無(wú)法預(yù)測(cè)頁(yè)面將來(lái)的使用情況，只能把“最近的過(guò)去”作為“最近的將來(lái)”的近似。因此，LRU置換算法將最近最久未使用的頁(yè)面(session)予以淘汰。

本文中LRU算法的實(shí)現(xiàn)，可利用一個(gè)特殊的隊(duì)列來(lái)保存當(dāng)前的保存了的各個(gè)會(huì)話的id。當(dāng)客戶端進(jìn)程進(jìn)行會(huì)話重用時(shí)，該會(huì)話id從隊(duì)列中提出，并將它放入對(duì)首。因此，隊(duì)首始終是最近進(jìn)行會(huì)話重用的會(huì)話id，而隊(duì)尾則是最近最久未進(jìn)行會(huì)話重用的會(huì)話id。

2.2 原包修改

JSSE(Java Secure Socket Extengsion)是Java中用來(lái)支持SSL與TLS安全通信的API包。它能夠提供數(shù)據(jù)加密、證書(shū)身份驗(yàn)證等。在引用JSSE時(shí)，可以設(shè)置相關(guān)的屬性，包括：系統(tǒng)屬性以及安全屬性。它屏蔽了細(xì)節(jié)，并且調(diào)用API進(jìn)行互相認(rèn)證，還在Socket上的傳輸?shù)臄?shù)據(jù)進(jìn)行加密。

由于緩存操作中需要對(duì)session對(duì)象、sessionId對(duì)象進(jìn)行操作，而原Java的jsse.jar包的類(lèi)庫(kù)中對(duì)于底層服務(wù)對(duì)象都是禁止訪問(wèn)的，因此需要對(duì)該包中的類(lèi)進(jìn)行部分修改。

此處主要修改jsse.jar包中的SessionId類(lèi)、SSLSessionImpl類(lèi)中部分代碼。如下：

SessionId修改：

(1)修改類(lèi)屬性為public。

(2)加入構(gòu)造函數(shù)。

public SessionId(byte abyte0[])

{ sessionId = abyte0;

}

(3)加入ID設(shè)置方法。

public void SetSessionId(byte abyte0[])

{

sessionId = abyte0;

}

SSLSessionImpl修改：修改getSessionId屬性為public。

由于session緩存記錄位于jsse.jar包的final類(lèi)SSLSessionContextImpl中，從外部無(wú)權(quán)限對(duì)類(lèi)中的cache對(duì)象進(jìn)行操作，在權(quán)衡對(duì)封裝安全性的考慮之后采用Java反射機(jī)制獲取SessionCache、以及SessionHostPortCache對(duì)象屬性，對(duì)服務(wù)器緩存進(jìn)行操作。

2.3 優(yōu)先調(diào)度算法的實(shí)現(xiàn)

圖3 優(yōu)先調(diào)度算法流程圖

本節(jié)對(duì)服務(wù)端的cache中對(duì)session進(jìn)行優(yōu)先級(jí)的設(shè)置，當(dāng)最近調(diào)用該session后，該session的優(yōu)先級(jí)提高。所以，從cache中最先刪除的肯定是最近這段時(shí)間沒(méi)有調(diào)用過(guò)的session(即：操作系統(tǒng)中最近最久未使用算法(LRU))。流程圖見(jiàn)圖3。

具體操作如下：

(1)從Cache對(duì)象獲取所需刪除的低優(yōu)先級(jí)session將其從SessionCache、SessionHostPortCache 中刪除，以減少服務(wù)器緩存。

(2)byte[] id=sslSock.getSession().getId();這是用來(lái)判斷是否已記錄標(biāo)志，若沒(méi)有則添加如列表，若有則將其刪除并重新加該入隊(duì)列，提高其優(yōu)先級(jí)。

(3)用count記錄緩存session數(shù)量，當(dāng)超過(guò)某一值時(shí)創(chuàng)建MyCache實(shí)例清理優(yōu)先級(jí)低的幾個(gè)session緩存。

(4)服務(wù)器線程中加入一個(gè)集合列表用于存儲(chǔ)緩存中對(duì)應(yīng)的session的ID，并以優(yōu)先調(diào)度算法對(duì)緩存進(jìn)行控制。

3 利用客戶存儲(chǔ)實(shí)現(xiàn)會(huì)話重用

雖然在TLS安全連接時(shí)可以進(jìn)行會(huì)話重用，但是服務(wù)器與瀏覽器的會(huì)話重用存在問(wèn)題，當(dāng)瀏覽器進(jìn)程關(guān)閉時(shí)都會(huì)清除前邊用戶所保存下來(lái)的Session信息，當(dāng)再次啟動(dòng)瀏覽器進(jìn)程，連接HTTPS服務(wù)器端時(shí)又需要再次進(jìn)行完整的握手連接。Session resume機(jī)制也就沒(méi)有發(fā)揮它的作用，嚴(yán)重的影響了HTTPS安全連接方式的使用與發(fā)展。所以本小節(jié)對(duì)此提出問(wèn)題，并在Java平臺(tái)進(jìn)行模擬實(shí)驗(yàn)，下邊對(duì)Java平臺(tái)中的類(lèi)進(jìn)行分析。

3.1 SSLsession分析

SSLSession是Java平臺(tái)中進(jìn)行會(huì)話重用重要的類(lèi)，SSLSession由SSLSessionImpl類(lèi)實(shí)現(xiàn)，其內(nèi)容包括SSL連接的可緩存內(nèi)容sessionContext參數(shù)、creationTime、lastUsedTime等。其中證書(shū)鏈及證書(shū)參數(shù)只是對(duì)對(duì)象的引用并非SSLsession中含有證書(shū)實(shí)體。

在JSSE類(lèi)庫(kù)中，服務(wù)器在底層代碼中建立ServerContext，負(fù)責(zé)每次連接時(shí)SSLSession的存取操作。當(dāng)完整握手驗(yàn)證完成時(shí)將SSLSession存入設(shè)定好的Cache對(duì)象中，并完成標(biāo)志符inValid、isTimeOut的維護(hù)。如果客戶端請(qǐng)求進(jìn)行會(huì)話重用，服務(wù)器則負(fù)責(zé)驗(yàn)證SSLSession的有效性，若有效則從Cache對(duì)象中取出SSLSession讀取其中的信息用于開(kāi)始連接握手。每個(gè)SSLSession的默認(rèn)有效時(shí)間為0X15180就是24 h。

在客戶端，瀏覽器在完成一次完整TLS連接握手之后會(huì)將sessionId以Cookie的形式緩存下來(lái)。如果瀏覽器在不重啟的前提下就能使用該緩存進(jìn)程會(huì)話重用。

3.2 實(shí)現(xiàn)SSLsession長(zhǎng)久可用

在正常HTTPS連接時(shí)，瀏覽器會(huì)在TLS完整握手完成時(shí)對(duì)sessionId進(jìn)行緩存，由此直到瀏覽器進(jìn)程結(jié)束這段時(shí)間內(nèi)都能夠?qū)崿F(xiàn)session resume。為了廣泛的實(shí)現(xiàn)session resume在對(duì)安全要求不是特別嚴(yán)格的環(huán)境(比如可排除session緩存數(shù)據(jù)被盜取使用的可能性)下可以對(duì)其在Java平臺(tái)下進(jìn)行實(shí)現(xiàn)：

由服務(wù)器端維護(hù)一個(gè)sessionId表，記錄每次完成完整TLS握手時(shí)的客戶方信息，再有新連接請(qǐng)求時(shí)遍歷sessionId表讀取sessionId用于創(chuàng)建ClientHello進(jìn)行握手。

由客戶端程序維持一個(gè)全局變量hostName用于記錄當(dāng)前客戶名。在SSLSessionContextImpl類(lèi)中完成對(duì)session的緩存及讀取操作，以hostName作為Key保存sessionId。然后在handshaker類(lèi)中對(duì)內(nèi)部類(lèi)clientHello的構(gòu)造函數(shù)進(jìn)行修改，使其在建立連接請(qǐng)求前查找中sessionId記錄。

3.3 Java證書(shū)庫(kù)

圖4 KeyStore結(jié)構(gòu)

客戶端會(huì)話重用是用Java模擬的，而Java的證書(shū)庫(kù)與瀏覽器有一定的區(qū)別。相對(duì)于Java有自己的證書(shū)體系，在試驗(yàn)中需要將各個(gè)證書(shū)提取封裝成為KeyStore對(duì)象結(jié)構(gòu)來(lái)使用(如圖4)。為了結(jié)合其他實(shí)驗(yàn)項(xiàng)目，需要將pfx格式證書(shū)或cer轉(zhuǎn)換成為統(tǒng)一的Java中KeyStore標(biāo)準(zhǔn)的證書(shū)文件。

首先需要將一個(gè)證書(shū)中的Certificate對(duì)象及密鑰對(duì)象提取出來(lái)，然后再用KeyStore結(jié)構(gòu)將Certificate對(duì)象、私鑰、證書(shū)鏈都設(shè)定在一個(gè)證書(shū)實(shí)例中獲取KeyStore。

3.4 Java平臺(tái)下的會(huì)話重用

支持TLS/SSL協(xié)議的瀏覽器都能在啟用Cookie和瀏覽器進(jìn)程不重啟的前提下與HTTPS服務(wù)器借助Cookie緩存完成會(huì)話重用。本實(shí)驗(yàn)已通過(guò)實(shí)驗(yàn)Firefox與中國(guó)工商銀行服務(wù)器進(jìn)行連接，分析了其過(guò)程中傳輸?shù)腍TTP報(bào)文，了解清楚該瀏覽器與服務(wù)器完成會(huì)話重用的實(shí)現(xiàn)過(guò)程，并用Java程序模擬發(fā)送數(shù)據(jù)，與服務(wù)器實(shí)現(xiàn)會(huì)話重用。

在Java模擬實(shí)驗(yàn)中，https連接過(guò)程，客戶端在第一次完成驗(yàn)證之后讀取服務(wù)器響應(yīng)信息中的Set-Cookie字段并保存。在第二次連接時(shí)讀取該數(shù)據(jù)，寫(xiě)入到http的GET請(qǐng)求中，發(fā)送到服務(wù)器端，完成有效會(huì)話的重用。

4 實(shí)驗(yàn)測(cè)試

4.1 安裝環(huán)境

(1)配置org.bouncycastle算法庫(kù)。在NetBeans的項(xiàng)目中，在項(xiàng)目“庫(kù)”文件中增加bcmail-jdk16-1.44.jar與bcprov-jdk16-145.jar文件。

(2)在使用的過(guò)程中，因受到出口限制，密鑰長(zhǎng)度不能滿足實(shí)驗(yàn)的需求。這是因?yàn)閟un發(fā)布的權(quán)限文件做了相應(yīng)限制，我們可以在sun的官方網(wǎng)站找到替換文件來(lái)減少相關(guān)限制。

圖5 服務(wù)器緩存對(duì)象調(diào)度算法執(zhí)行情況

(3)BC provider添加：找到Java根目錄下Javajdk1.7.0jrelibsecurity中的Java.security用記事本打開(kāi)，在security.provider處的末尾添加security.provider.8 =org.bouncycastle. jce.provider.BouncyCastleProvider。

4.2 實(shí)驗(yàn)結(jié)果

將LRU置換算法對(duì)其服務(wù)端進(jìn)行改進(jìn)之后，其服務(wù)器端刪除的session的順序如圖5所示。

實(shí)驗(yàn)結(jié)果：將LRU置換算法加入到服務(wù)器端后，session從緩存中被刪除的時(shí)間，是嚴(yán)格按照最近被調(diào)用的時(shí)間遞增的順序來(lái)進(jìn)行刪除的，因?yàn)橐獎(jiǎng)h除的肯定是最近未被調(diào)用的，即：最近調(diào)用時(shí)間最早的一個(gè)，然后依次刪除其他最近調(diào)用時(shí)間較早的session，所以實(shí)驗(yàn)結(jié)果是嚴(yán)格按照最近被調(diào)用時(shí)間遞增是完全符合邏輯，也是符合LRU置換算法的表現(xiàn)。

利用客戶存儲(chǔ)實(shí)現(xiàn)會(huì)話重用的實(shí)驗(yàn)結(jié)果如表1所示。

表1 實(shí)驗(yàn)連接耗時(shí) ms

表1中分了5組進(jìn)行實(shí)驗(yàn)，分別為連接次數(shù)為5,15,30,50,100次，表中數(shù)據(jù)可看出連接中第一次的時(shí)間正常情況下比后邊會(huì)話重用平均耗時(shí)的時(shí)間要長(zhǎng)，其中第二組實(shí)驗(yàn)會(huì)話重用平均耗時(shí)要比第一次耗時(shí)要多，這是由于兩方面原因造成，第一是由網(wǎng)絡(luò)不穩(wěn)定原因造成的，其中最長(zhǎng)耗時(shí)為8 380 ms；第二是由于進(jìn)行的連接次數(shù)較少，造成數(shù)據(jù)并不是很穩(wěn)定，但如第1、2、4、5組都是正常的。而且連接次數(shù)越多，中位數(shù)卻趨于穩(wěn)定，并且是要比第一次耗時(shí)要少的，對(duì)于突發(fā)的網(wǎng)絡(luò)不穩(wěn)定原因造成的延遲，中位數(shù)比會(huì)話重用平均耗時(shí)可能更體現(xiàn)會(huì)話重用的實(shí)際效果，除了第一組實(shí)驗(yàn)中中位數(shù)都比第一次連接耗時(shí)相等外，其他組實(shí)驗(yàn)都是比第一次要少。

5 結(jié)語(yǔ)

TLS握手協(xié)議在連接過(guò)程所帶來(lái)的用戶延遲，使網(wǎng)站和用戶不愿意使用TLS。緩存后的握手協(xié)議可以去除證書(shū)的驗(yàn)證所用的時(shí)間，減少延遲。本文結(jié)合Java安全措施的相關(guān)內(nèi)容，分別在服務(wù)器端提出緩存機(jī)制的改進(jìn)，提高了服務(wù)器的緩存利用率；并在客戶端實(shí)現(xiàn)了運(yùn)用cookie進(jìn)行會(huì)話重用，減少TLS握手過(guò)程中所需要的時(shí)間。

[1]Souders S. WPO-Web performance optimization[EB/OL〗.2010-5-7[2013-5-1].http://www.stevesouders.com /blog/2010/05/07/wpo-web-performance-optimization/.

[2]Myers M,Ankney R,Malpani A.X.509 Internet public key infrastructure online certicate status protocol - OCSP[EB/OL].1999-5-1[2013-5-1].http://www.ietf.org/rfc/rfc2560.txt.

[3]Shacham H,Boneh D. Fast-track session establishment for TLS[C]//Proceedings of the Network and Distributed System Security Symposium (NDSS).San Diego, California,[s.n.],2002.

[4]Langley A, Modadugu N, Moeller B. Transport layer security (TLS) false start[EB/OL]. 2010-12-4[2013-5-1]. http://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00.

[5]Langley A. Transport Layer Security (TLS) Snap Start[EB/OL]. 2010-11-2[2013-5-1].https://www.imp erialviolet.org/binary/draft-agl-tls-snapstart-00.html.

[6]Emily Stark ,Huang Linshung , Dinesh.The case for prefetching and prevalidating TLS server certificates[C]//proceedings of Usenix Security.Washington, DC, USA,USENIX Association,2010.

[7]Salowey J,Zhou H,Eronen P,et al.Transport layer security (TLS) session resumption without server-side state[EB/OL].2006-5-1[2013-5-1].http://wenku.baidu.com/view/6e00ae778e9951e79b892771.html.

[8]Hovav Shacham,Dan Boneh Eric,Rescorlahovav.Client side caching for TLS[J]. ACM Transactions on Information and System Security (TISSEC) , 2004,7 (4): 553-575.

(責(zé)任編輯 車(chē)軒玉)

Priority-based Policy Research on TLS Handshake Protocol

Gao Zhiwei, Geng Jinyang

(School of Information Science and Technology, Shijiazhuang Tiedao University,Shijiazhuang 050043,China)

When a lot of users access the server via TLS protocol, a greater burden is generated, and when the browser is closed, the session information about users will be cleared, and if connected again, it has to complete the full TLS handshake again. The TLS protocol is analyzed based on the classic handshake protocol, and an improved method of caching mechanism of the server-side session is designed which improves the server’s cache utilization, and session resume is carried out by cookie in the client-side .Combined with Java related technologies, TLS environment is configured, experiments are conducted on server-side and client-side, and the efficiency of the TLS handshake protocol is tested.

TLS；session；session resuming

10.13319/j.cnki.sjztddxxbzrb.2014.03.15

2013-06-06

高志偉 男 1972年出生 副教授

TP311

A

2095-0373(2014)03-0069-06