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

高志偉， 耿金陽

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

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

高志偉， 耿金陽

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

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

TLS；session； 會話重用

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2 原包修改

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

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

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

SessionId修改：

(1)修改類屬性為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類SSLSessionContextImpl中，從外部無權(quán)限對類中的cache對象進(jìn)行操作，在權(quán)衡對封裝安全性的考慮之后采用Java反射機(jī)制獲取SessionCache、以及SessionHostPortCache對象屬性，對服務(wù)器緩存進(jìn)行操作。

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

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

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

具體操作如下：

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

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

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

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

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

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

3.1 SSLsession分析

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

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

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

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

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

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

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

3.3 Java證書庫

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

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

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

3.4 Java平臺下的會話重用

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

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

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

4.1 安裝環(huán)境

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

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

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

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

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

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

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

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

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

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

5 結(jié)語

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

[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é)任編輯 車軒玉)

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