狀態(tài)機無關的TLS數(shù)據(jù)采集方法研究

閆 露，鄧浩江，陳 曉，葉曉舟

1(中國科學院 聲學研究所 國家網(wǎng)絡新媒體工程技術研究中心，北京 100190)2(中國科學院大學，北京 100190)

1 引 言

近年來，出現(xiàn)了越來越多來源于網(wǎng)絡內(nèi)部的攻擊，如內(nèi)部人員對網(wǎng)絡的濫用、信息泄露等.為監(jiān)督內(nèi)部用戶行為，規(guī)范網(wǎng)絡操作，保護內(nèi)網(wǎng)安全，網(wǎng)絡安全審計系統(tǒng)快速發(fā)展.作為系統(tǒng)中后續(xù)工作的數(shù)據(jù)來源，數(shù)據(jù)采集起著至關重要的作用.網(wǎng)絡上的數(shù)據(jù)大部分是以明文形式傳輸?shù)模@便于采集分析.隨著人們對數(shù)據(jù)安全需求的增強，安全協(xié)議得到了廣泛應用[1].通過安全協(xié)議保護的數(shù)據(jù)是以密文形式傳輸?shù)模@為數(shù)據(jù)采集帶來了新的挑戰(zhàn)，需要首先將其轉(zhuǎn)換為相應的明文數(shù)據(jù)[2].

傳輸層安全協(xié)議[3-5](Transport Layer Security，TLS)及其前任安全套接層協(xié)議[6](Secure Sockets Layer，SSL)是網(wǎng)絡上應用廣泛的安全協(xié)議，目前已成為傳輸層安全的事實標準.TLS協(xié)議是一個可選的安全層，位于TCP層和應用層之間，各種應用層協(xié)議可以透明的運行于TLS協(xié)議層之上，例如HTTP協(xié)議、FTP協(xié)議等.

TLS協(xié)議提供身份認證、數(shù)據(jù)加密和完整性校驗等安全特性.通常，由客戶端發(fā)起TLS連接，并通過服務器提供的基于PKI(Public Key Infrastructure)體系的數(shù)字證書[7]來驗證其身份.同樣的，在一些安全性需求較高的場景下，服務器可選擇認證客戶端的身份.此外，雙方需要通過握手協(xié)議協(xié)商安全參數(shù)[8]，進行密鑰交換，以此建立起安全的通道來保障通信的機密和可靠性.

由于TLS協(xié)議數(shù)據(jù)是密文傳輸?shù)模枰紫仍谖帐蛛A段解析數(shù)據(jù)包，通過一定技術手段獲取到密鑰信息后，才可以在數(shù)據(jù)傳輸階段對數(shù)據(jù)進行解密.為完成握手協(xié)商過程，客戶端和服務器需要維護正確的狀態(tài)機，狀態(tài)機主要描述了TLS消息數(shù)據(jù)包的發(fā)送順序，然而協(xié)議文檔并未規(guī)定一個嚴格的狀態(tài)機.許多學者研究了TLS協(xié)議客戶端和服務器的狀態(tài)機實現(xiàn)問題.文獻[9]關注安全協(xié)議的狀態(tài)機，并討論了從協(xié)議實現(xiàn)中學習出狀態(tài)機的可能性.文獻[10]則通過黑盒測試的方法學習了主流TLS協(xié)議庫的狀態(tài)機實現(xiàn)，并且指出對于TLS協(xié)議而言，正確的狀態(tài)機并不是唯一的.文獻[11]分析了TLS的狀態(tài)機實現(xiàn)，找出一些狀態(tài)機實現(xiàn)錯誤并分析了可能導致的攻擊.基于對協(xié)議規(guī)范和特性的不同理解，在實現(xiàn)過程中會存在多種正確的狀態(tài)機.對于數(shù)據(jù)采集器而言，理解客戶端與服務器實現(xiàn)的所有狀態(tài)機是較為困難的.

TLS協(xié)議在提供安全特性的同時，頻繁的密碼操作為客戶端和服務器帶來了較大的開銷.在握手階段，雙方需要通過公開密鑰算法進行身份認證和密鑰交換，其中服務器私鑰操作是非常費時的.此外，當雙方傳輸大量數(shù)據(jù)時，對數(shù)據(jù)進行加解密和完整性校驗的開銷也較大.同時，網(wǎng)絡上傳輸?shù)臄?shù)據(jù)量不斷增大，速度不斷增快，這都對數(shù)據(jù)采集的性能提出了更高的要求.

本文針對網(wǎng)絡安全審計系統(tǒng)中TLS協(xié)議采集的需求，基于多核網(wǎng)絡處理器平臺實現(xiàn)高效的數(shù)據(jù)采集，提出一種狀態(tài)機無關的數(shù)據(jù)采集方法，并針對私鑰查找操作進行優(yōu)化，提高系統(tǒng)性能.

2 數(shù)據(jù)采集系統(tǒng)架構

網(wǎng)絡安全審計系統(tǒng)可基于網(wǎng)絡進行數(shù)據(jù)的采集分析，數(shù)據(jù)采集器主要完成數(shù)據(jù)采集分析的工作，對網(wǎng)絡協(xié)議進行處理，識別用戶行為，提取關鍵信息，并封裝生成日志發(fā)送至數(shù)據(jù)中心.數(shù)據(jù)采集器可以旁路方式部署于網(wǎng)絡環(huán)境中，通過交換機鏡像流等[12]方式實時獲取到數(shù)據(jù)流并采集分析.在這種模式下，采集器不能夠?qū)?shù)據(jù)包進行修改，檢測到不規(guī)范的操作或者危險的命令時，只可以及時進行告警.旁路部署的優(yōu)勢在于對原有系統(tǒng)的影響小，數(shù)據(jù)采集器的故障并不會影響客戶端和服務器的連接.

由于TLS協(xié)議帶來的額外負載，以及高速增長的網(wǎng)絡帶寬，單個核心的處理速度已經(jīng)不能滿足采集分析TLS協(xié)議數(shù)據(jù)的需求.多核網(wǎng)絡處理器具有多核并行、功耗低、加速網(wǎng)絡數(shù)據(jù)包處理等特點，基于多核網(wǎng)絡處理器平臺來實現(xiàn)數(shù)據(jù)采集器具有明顯的性能優(yōu)勢.

TLS數(shù)據(jù)采集架構如圖1所示，邏輯是可以分為兩部分：控制平面和數(shù)據(jù)平面.控制平面完成采集策略和證書配置等管理功能.采集策略指明需要分析采集的數(shù)據(jù)流，證書配置使得采集器在旁路模式下可以使用服務器的證書私鑰.數(shù)據(jù)平面用于采集和分析數(shù)據(jù)，當數(shù)據(jù)采集器接收到網(wǎng)絡數(shù)據(jù)后，首先完成TCP/IP重組等功能，確認數(shù)據(jù)的完整和有效性之后提交給高層協(xié)議進行分析.

圖1 數(shù)據(jù)采集器系統(tǒng)架構Fig.1 System architecture

數(shù)據(jù)采集器基于異構系統(tǒng)實現(xiàn).由于Linux操作系統(tǒng)具有通用及靈活性的特點，數(shù)據(jù)采集器中控制平面的功能在Linux系統(tǒng)下實現(xiàn)，這可以降低開發(fā)和移植難度并且為管理功能的多樣性提供了基礎.SE(Simple Executive)系統(tǒng)下可以直接操作底層資源，并且避免了系統(tǒng)調(diào)用、中斷處理等開銷，可進行高效的網(wǎng)絡數(shù)據(jù)包處理，實現(xiàn)數(shù)據(jù)采集器中數(shù)據(jù)平面的功能.在數(shù)據(jù)處理時，同一個數(shù)據(jù)流的處理放在同一個處理核心上，這樣可以避免過多的核間通信開銷.Linux系統(tǒng)和SE系統(tǒng)可通過共享內(nèi)存或者消息等機制進行通信.

3 狀態(tài)機無關的TLS協(xié)議數(shù)據(jù)采集方法

3.1 狀態(tài)機實現(xiàn)問題

TLS協(xié)議是一個分層協(xié)議，包括底層的TLS記錄層協(xié)議和高層的TLS改變密碼規(guī)范協(xié)議、TLS告警協(xié)議、TLS握手協(xié)議.TLS記錄層協(xié)議為底層協(xié)議，為其他協(xié)議提供最基本的安全特性和封裝傳輸.TLS改變密碼規(guī)范協(xié)議用以通知數(shù)據(jù)接收方隨后的記錄都會用協(xié)商好的安全參數(shù)來進行保護.TLS告警協(xié)議用以通知對方連接信息，包括告警的嚴重性和告警描述.通信雙方通過TLS握手協(xié)議進行安全參數(shù)協(xié)商、身份認證、生成密鑰等.

如圖2所示，這是一個常見的TLS協(xié)議狀態(tài)機，然而在實際過程的實現(xiàn)時，情況遠沒有這么簡單.TLS協(xié)議提供多種密碼套件和擴展特性，很多特征都是通過單獨的文檔來定義的.TLS協(xié)議在實現(xiàn)過程中會存在多種正確的狀態(tài)機.此外，協(xié)議文檔是不斷更新的，當前一個不合法的數(shù)據(jù)包發(fā)送順序?qū)砜赡苁钦_的，也就會導致一個新的狀態(tài)機，這都使情況變得更加復雜.TLS false start[13，14]便是一個很好的例子，TLS協(xié)議文檔規(guī)定通信雙方在發(fā)送和驗證對方的Finished消息后才可以發(fā)送接下來的加密應用層消息.后來在實踐中有人員提出，當通信中的一方發(fā)送Finished消息后，可以不用等對方發(fā)送并驗證對方的Finished消息，便可以直接發(fā)送應用層消息，這樣可以減少TCP傳輸?shù)臅r延.因此在TLS數(shù)據(jù)采集過程中，若采集器維持自身的TLS狀態(tài)機，首先兼容客戶端與服務器所實現(xiàn)的所有狀態(tài)機是比較困難的，其次若根據(jù)狀態(tài)機來實現(xiàn)，未來的可擴展性也不強.對于該問題，我們提出了一種狀態(tài)機無關的TLS協(xié)議數(shù)據(jù)采集方法，具體而言，采集器不維持自身的狀態(tài)機，在處理數(shù)據(jù)時僅將關注的重點放在接收到的數(shù)據(jù)包上，而不是數(shù)據(jù)包的發(fā)送順序上.

圖2 TLS協(xié)議狀態(tài)機Fig.2 TLS state machine

3.2 狀態(tài)機無關的數(shù)據(jù)采集方法

該方法的總體思想在于數(shù)據(jù)采集器不維持TLS協(xié)議狀態(tài)機，在客戶端和服務器握手階段，對接收到的握手消息進行處理獲取會話信息，會話信息主要包括隨機數(shù)、加密套件、壓縮算法、預主秘密等，最終計算生成主秘密并擴展生成MAC密鑰、對稱加密算法密鑰、IV，隨后在數(shù)據(jù)傳輸階段，利用獲取的密鑰信息等將密文數(shù)據(jù)解密，并將解密后的數(shù)據(jù)提交至高層協(xié)議解析進行處理生成審計數(shù)據(jù).

TLS協(xié)議中，記錄是傳輸?shù)淖钚卧谶M一步解析處理數(shù)據(jù)之前，首先需要提取完整的記錄.協(xié)議規(guī)定，TLS記錄內(nèi)容長度不超過 2^14+2048 字節(jié)，而這一數(shù)字遠超出一般TCP的最大報文段長度(Maximum Segment Size，MSS)，因此較大的記錄會被分作多次TCP傳輸.此外，由于TCP傳輸?shù)奶匦砸约熬W(wǎng)絡環(huán)境較差等原因，不超過TCP最大報文長度的記錄也會被分作多次進行傳輸.另一方面，為了提高傳輸性能，將多個長度較小的記錄合并在一個TCP報文段的情況也會發(fā)生.因此TCP傳輸?shù)膱笪牟⒉蛔鳛門LS記錄的邊界，在經(jīng)過TCP重組后的數(shù)據(jù)雖然是完整有序的，仍需要從中提取生成完整的TLS記錄后再進行處理.TLS記錄的格式滿足以下格式：

ε=t|v|l|p

(1)

其中，ε為一條記錄，t為一個字節(jié)的內(nèi)容類型，v為兩個字節(jié)的協(xié)議版本，l為兩個字節(jié)的內(nèi)容長度，p為具體的內(nèi)容.

算法1.TLS Record Reconstruct

1：procedure Reconstructing(fi，bufc)

2：bufc←Empty，lbc←0，j←1

5： whileltemp>0 do

6：lbc←calc_len(bufc)

7： iflbc+ltemp>5 then

9： iflbc+ltemp>5+rcdlentthen

? TLS record reconstruct OK

11.bufc←Empty

13.ltemp←ltemp-(rcdlent+5-lbc)

14. else

16.ltemp← 0

17. end if

18： else

20：ltemp← 0

21： end if

22： end while

23：j←j+1

24： end for

25：end procedure

算法1描述了具體流程，在記錄提取過程中，充分考慮多種傳輸情況，實用性好.另一方面，為提高處理效率，需要減少內(nèi)存拷貝的次數(shù).如果底層提交的數(shù)據(jù)僅僅是記錄的一部分，則對該部分數(shù)據(jù)進行拷貝緩存，待后續(xù)拼接生成完整的記錄后再處理，而如果底層提交的數(shù)據(jù)中已經(jīng)包含完整的記錄，則不需要對數(shù)據(jù)進行拷貝緩存，可直接進行處理以減少內(nèi)存拷貝帶來的開銷.

在TLS握手階段，客戶端和服務器會傳輸多個握手消息以進行協(xié)商，數(shù)據(jù)采集器需針對消息進行處理.消息是封裝在記錄中的，一個記錄中可能包含單個或者多個握手消息，首先需要提取出完整的單個消息后再進行接下來的處理，這一過程與提出完整記錄類型，在此不再贅述.

消息處理 的目的在于獲取會話信息，生成密鑰.在握手消息中，Hello Request消息用以通知客戶端在何時的時候開始進行握手協(xié)商，Certificate Request消息和客戶端Certificate消息用以認證客戶端，這些消息與會話信息并沒有太多關系.當服務器證書無法供客戶端進行密鑰交換時，服務器發(fā)送Server Key Exchange消息用以提供密鑰交換的參數(shù)，在這種密鑰交換方式下，僅僅為數(shù)據(jù)采集器配置服務器證書和私鑰是不足以計算出預主秘密的，因此數(shù)據(jù)采集器需要其他方式來獲取預主秘密，本文暫不討論這種情況.對于其他握手消息，數(shù)據(jù)采集器進行差異化的處理以獲取會話信息，如算法2所示.

算法2.TLS Handshake Message

1：procedure processing(hdmsg)

2：type←hdmsg[1]

3： switch (type)

4： case 1： ?Client Hello

5：vsc，rdc，IDc← calc(hdmsg)

6：dealwithExtensions

7： case 2 ： ? Server Hello

8： ifSessionResume

9：rds，IDs← calc(hdmsg)

10：getcipher_suite，comm，master_secretfromcache

11：key_block← calc(master_secret，rdc，rds)

12： else

13：vss，rds，IDs，cipher_suite，comm← calc(hdmsg)

14： end if

15：dealwithExtensions

16： case 4 ： ? New Session Ticket

17：updatesessiontickets

18： case 11： ? Certificate

19： ifmessagefromserver

20：pubkey.der← calc(hdmsg)

21：keypri← find(pubkey.der)

22： end if

23： case 16： ? Client Key Exchange

24：p_master_secret← calc(keypri，hdmsg)

25：master_secret← calc(p_master_secret，rdc，rds)

26：key_block← calc(master_secret，rdc，rds)

27：savesessioninfo

28： case 20 ： ? Finished

29：verifydata← calc(allhandshakemessage)

30：compareverifydataandhdmsg

31： default ： ? Other Handshake Message

32：donothingnow

33： end switch

34：end procedure

在此需要注意的是，TLS協(xié)議中定義了許多的擴展項，有些擴展項是與會話信息緊密相關的，在處理握手消息時需要對這些擴展項進行相應的處理.例如，Extended Master Secret擴展項[15]，該擴展項定義了另外一種相對更加安全的主秘密的計算方式，若忽略該擴展項則會計算出錯誤的主秘密，以至于后續(xù)無法正確解密數(shù)據(jù).

一旦收到改變密碼規(guī)范協(xié)議消息，數(shù)據(jù)采集器便可以知道在該方向上接下來的消息將會用協(xié)商好的密鑰和安全參數(shù)進行保護.

告警協(xié)議對于會話信息的獲取并沒有太大作用.告警協(xié)議對雙方通信狀態(tài)進行報告，在網(wǎng)絡安全審計系統(tǒng)中，對于一類有意義的錯誤信息，可將其作為重要的錯誤日志進行存儲.

通過以上的處理，數(shù)據(jù)采集器已經(jīng)可以獲取到相應的加密算法等安全參數(shù)，計算出用于數(shù)據(jù)傳輸階段的MAC密鑰、對稱加密算法密鑰、IV.在數(shù)據(jù)傳輸階段，便可以對相應的加密數(shù)據(jù)進行解密、驗證完整性、解壓縮等.解密后的數(shù)據(jù)可提供給高層協(xié)議模塊進行進一步的解析，生成審計日志發(fā)送至數(shù)據(jù)中心.

在消息處理過程中，一種常見的證書配置方式是為每個IP配置一個服務器私鑰，例如Wireshark便采用這種方式.這種證書配置方法適用于每個服務器IP只有一個證書私鑰對或者抽取一些特定的數(shù)據(jù)流后進行配置.但是服務器的IP和證書私鑰并不總是一一對應的，同一個服務器IP下很可能會有多個證書私鑰對.數(shù)據(jù)采集器需要實時對數(shù)據(jù)流進行采集分析，當后端服務器每個IP下?lián)碛卸鄠€證書私鑰對時，便沒有辦法通過IP來查找私鑰.而證書和私鑰卻肯定是一一對應的關系，因此在數(shù)據(jù)采集時，選擇通過證書來查找相應的私鑰，而不是IP.

通常的私鑰查找算法我們稱之為PCS(Private Key Certificate Search).控制層面完成服務器的證書和私鑰配置，生成一個哈希表，以供后續(xù)查找.證書和私鑰都有其特定的文件格式，通常配置的證書為PEM格式，而在TLS通信過程中服務器Certificate消息中的證書為DER格式.若在配置時，服務器證書依然選擇以PEM格式進行計算關鍵詞并存儲至哈希表，那么在數(shù)據(jù)平面進行證書查找時，每個數(shù)據(jù)流的Certificate消息提取證書后都需要進行相應的格式轉(zhuǎn)換才能進行查找，這顯然是不高效的.因此，控制層面在進行配置時，首先將證書轉(zhuǎn)化為DER格式再進行接下來的處理.

算法3.PCS algorithm

1：procedure processing(hdmsg)

2： control plane：

3： ifCertificateConfigurationthen

4：keyt←Empty，i← 1

5： forpubkey.pemido

6：pubkey.deri←p2d(pubkey.pemi)

7：hashk←Hash(pubkey.deri)

8：keyt←add(hashk，prikey.pemi)

9：i←i+1

10： end for

11： end if

12： data plane：find(pubkey.der)

13：hashk←Hash(pubkey.deri)

14：prikey.pem←lookup(hashk，keyt)

15：keypri←P2X(prikey.pem)

16：end procedure

盡管PCS算法已經(jīng)針對證書格式進行了優(yōu)化，然而在實踐中發(fā)現(xiàn)，這種算法的效率并不是十分理想.在數(shù)據(jù)平面使用服務器私鑰時，首先需要將私鑰文件轉(zhuǎn)換為特定的封裝結構，這一操作影響了系統(tǒng)的性能，因此我們提出了一種更高效的結構化私鑰信息緩存算法，簡稱PKES (Private Key Encapsulation Structure caching algorithm).算法的優(yōu)點在于減少了私鑰的轉(zhuǎn)換次數(shù).該算法在每個數(shù)據(jù)處理核上建立一個哈希表，用于存儲證書和對應的私鑰封裝結構.每個數(shù)據(jù)處理核都需要存儲一份的原因在于，私鑰的封裝結構若希望能夠被多個核共同使用，則必須進行加鎖，否則會造成數(shù)據(jù)的同步錯誤.而加解鎖操作會影響多核的處理效率，因此在每個數(shù)據(jù)核上都存儲一份，以空間來換取更高的效率.私鑰的轉(zhuǎn)換與哈希表的加入并不是在證書私鑰對配置時便在每個數(shù)據(jù)核生成一份，而是流驅(qū)動的.控制層面更新證書私鑰對配置時，僅更新相應的標志位.當在數(shù)據(jù)處理時，遇到證書消息后，首先查看標志位，若發(fā)現(xiàn)控制層面進行了更新操作，則將舊哈希表中的數(shù)據(jù)刪除，再進行相應的私鑰查找、轉(zhuǎn)換與哈希表的加入.后續(xù)，當在同個數(shù)據(jù)核上遇到相同的證書時，便可以直接查找使用相應的私鑰封裝結構.這樣的優(yōu)勢在于配置的證書私鑰對可能在下一次配置更新前并不會被用到，也就不用進行相應的轉(zhuǎn)換.此外，同一個證書對應的連接很可能會被調(diào)度到某些特定的數(shù)據(jù)核上，而不是在所有的數(shù)據(jù)核都會出現(xiàn)，在數(shù)據(jù)核上遇到證書后再進行操作，可以避免一些無用的轉(zhuǎn)換，節(jié)省時間和空間.

算法4.PKES algorithm

1：procedure processing(hdmsg)

2： control plane ：

3： ifCertificateConfigurationthen

4：keyt←Empty，i← 1

5： forpubkey.pemido

6：pubkey.deri← p2d(pubkey.pemi)

7：hashk← Hash(pubkey.deri)

8：keyt← add(hashk，prikey.pemi)

9：i←i+ 1

10： end for

11.flag← 1

12： end if

13： data plane：find(pubkey.der)

14： ifflag= 1 then

15： forj←1：totalworknumdo

16：flagd[j] ←1

17： end for

18： end if

19：n←tempworknum

20： ifflagd[n] = 1 then

21：keyd[n] ←empty

22：flagd[n] ← 0

23： end if

24：hashk← Hash(pubkey.deri)

25：keypri←lookup(hashk，keyd[n])

26： ifkeypri=NULLthen

27：prikey.pem← lookup(hashk，keyt)

28：keypri← P 2X(prikey.pem)

29：keyd[n] ←add(hashk，keypri)

30： end if

31：end procedure

1Cavium.OCTEON II CN66XX Multi-Core MIP S64 Processors.http://www.cavium.com/OCTEON-II_CN66XX.html.

為評估算法性能，首先定義如下屬性：

M：數(shù)據(jù)采集器配置的證書和私鑰對的數(shù)目.

N：數(shù)據(jù)采集器用作數(shù)據(jù)處理的處理核心的數(shù)目.

Fc：一段時間內(nèi)總的新建連接數(shù)量.

Fcd：該段時間內(nèi)的新建連接種類.其中，在通信過程中所使用的證書相同的連接定義為同一類連接.

Ot：私鑰轉(zhuǎn)換為特定封裝結構的次數(shù).

那么，在PCS算法中，需要在處理每一個連接時都將私鑰轉(zhuǎn)換為封裝結構，即：

Ot=Fc

(2)

而在PKES算法中：

(3)

在PCS算法中，數(shù)據(jù)采集器所需要進行的私鑰的轉(zhuǎn)換次數(shù)是與新建連接的數(shù)量成正比的.新建連接數(shù)量不斷增多，私鑰轉(zhuǎn)換操作的累積時間開銷不斷增長.而在PKES算法中，數(shù)據(jù)采集器所需要進行的私鑰的轉(zhuǎn)換次數(shù)與連接類型的數(shù)量直接相關，而不是新建連接的總數(shù)量.轉(zhuǎn)換是流驅(qū)動的，所進行的私鑰的轉(zhuǎn)換次數(shù)一定不會超過新建連接的數(shù)量.并且其最大次數(shù)是可以預估的，它受限于所配置的證書私鑰對數(shù)目和數(shù)據(jù)處理核心數(shù)目.所配置的證書私鑰對數(shù)目與后端服務器的數(shù)目和配置相關，這并不會太大，而處理核心的數(shù)目受物理平臺的限制.因此，服務器的數(shù)量，服務器配置的證書數(shù)量終歸有限，在新建連接數(shù)量較多時，新建連接類型的數(shù)量卻并不會一直增長，而是有一個上限.PKES算法僅需要犧牲較小的內(nèi)存空間，便可以減少轉(zhuǎn)換次數(shù)，取得更高的效率.

3.3 方法分析

狀態(tài)機無關的TLS數(shù)據(jù)采集方法具有很強的可擴展性和可維護性.我們可以很清楚的知道有多少握手消息，有多少擴展項，而且均有詳細的文檔對這些消息和擴展項進行描述.但是協(xié)議卻沒有規(guī)定一個嚴格的狀態(tài)機，在實現(xiàn)這些規(guī)范時，會有許多不同的狀態(tài)機存在.如果數(shù)據(jù)采集器在分析TLS數(shù)據(jù)流時維護一個TLS狀態(tài)機，那么當客戶端和服務器發(fā)送消息數(shù)據(jù)包的順序不符合數(shù)據(jù)采集器的狀態(tài)機時，那么工作便沒有辦法繼續(xù)，后續(xù)的維護工作也會十分繁瑣，而數(shù)據(jù)采集器維持的狀態(tài)機也必將越來越復雜.而狀態(tài)機無關的TLS數(shù)據(jù)采集方法將關注的重點放在消息本身，而不是消息的發(fā)送順序.對于數(shù)據(jù)采集器而言，需要關注消息的類型，如果消息當前不能識別，雖然不能被處理，只要這些消息對會話信息沒有影響，則數(shù)據(jù)采集器可以繼續(xù)正確解密數(shù)據(jù).后續(xù)的維護工作也只需要加入對相應消息的處理，而不需要修改復雜的邏輯.

4 實驗與分析

在本節(jié)中，進行一系列實驗，用以驗證所提出多核數(shù)據(jù)采集框架以及狀態(tài)機無關的TLS數(shù)據(jù)采集方法.數(shù)據(jù)采集器以Cavium OCTEON CN6645多核網(wǎng)絡處理器1為平臺實現(xiàn)，該平臺有10個處理核心，主頻為1200MHz，配備8G內(nèi)存以及2MB的L2級緩存.實驗中，TLS客戶端和服務器分別運行在兩臺Dell服務器上，系統(tǒng)通過交換機鏡像流獲取到雙方通信數(shù)據(jù).實驗測試了系統(tǒng)的性能，并比較了PKES和PCS兩種算法.

4.1 每秒新建連接數(shù)

每秒新建連接數(shù)(Connection Per Second，CPS)直接反映系統(tǒng)新建連接的時間，對于TLS協(xié)議而言，在TCP連接建立之上，雙方需要經(jīng)歷一個握手協(xié)商階段才可以建立TLS連接.握手消息的處理速度直接影響系統(tǒng)的CPS性能，在握手階段，最耗時的操作在于服務器對于預主秘密的解密，這涉及公開密鑰算法的私鑰操作.在本實驗中，服務器分別配置密鑰長度為1024位的RSA證書和2048位RSA證書，同時為數(shù)據(jù)采集器配置相應的證書和私鑰對.首先，我們測試了在不同數(shù)據(jù)處理核心數(shù)目下，系統(tǒng)的CPS性能，結果如圖3所示.

由圖3可以看出，隨著數(shù)據(jù)處理核心數(shù)目的增加，系統(tǒng)CPS性能線性增長.在新建連接時，使用2048位RSA證書比1024位的RSA證書時解密預主秘密速度要慢許多，CPS性能也就差很多.但在相同密鑰算法下，密鑰長度增加對于TLS連接而言更加安全.總的來說，TLS協(xié)議服務器需要在性能和安全性之間做出一個平衡，研究更高效的新的加密算法也是提供TLS協(xié)議執(zhí)行性能的有效途徑之一.

PCS算法和PKES算法區(qū)別在于對私鑰的操作，主要影響握手消息的處理、系統(tǒng)新建連接的時間.我們分別測試了使用PCS算法和PKES算法下系統(tǒng)的CPS性能，測試結果如圖4所示.相比PCS算法，PKES算法取得了很大的系統(tǒng)性能提升，當證書密鑰長度為1024位時，系統(tǒng)CPS增長了130%，當證書密鑰長度為2048位時，系統(tǒng)CPS增長了50%.對于不同長度的密鑰，將私鑰轉(zhuǎn)換為封裝結構的時間不同，因此PKES算法對系統(tǒng)性能提升程度也不相同.

圖3 系統(tǒng)CPS性能Fig.3 CPS measured from experiment圖4 PCS算法和PKES算法性能對比Fig.4 CPS performance comparison

在這個實驗中，我們分別為數(shù)據(jù)采集器配置了一對證書和私鑰，使用6個核心來進行數(shù)據(jù)處理.使用PCS算法時，每當新建一個連接，都需要為這個連接對私鑰進行相應的封裝結構轉(zhuǎn)換，累積時間開銷較大.而在使用PKES算法時，私鑰的轉(zhuǎn)換次數(shù)為6.私鑰封裝結構的存儲減少了所需要的轉(zhuǎn)換次數(shù)，節(jié)約了握手消息的處理時間，增加了系統(tǒng)的CPS性能.

4.2 吞 吐

當TLS雙方握手協(xié)商完成后連接建立，便可以進行數(shù)據(jù)的傳輸.在進行吞吐性能測試時，雙方傳輸?shù)臄?shù)據(jù)量較大，此時握手階段的開銷則相對較小，此時主要考慮對稱密鑰算法和哈希算法.在本次實驗中，我們使用AES256_SHA算法組合.數(shù)據(jù)采集器使用6個處理核心進行數(shù)據(jù)的采集，吞吐可穩(wěn)定達到2500Mbps，而我們作為對比測試的一款成熟產(chǎn)品只能達到240Mbs.圖5顯示了在不同處理核心數(shù)目下系統(tǒng)的性能，隨著處理核心數(shù)目的增加，吞吐性能的增長并不是完全線性，出現(xiàn)這一現(xiàn)象的原因在于大量的數(shù)據(jù)處理造成了不同處理核對緩存的競爭.

圖5 吞吐率測試結果Fig.5 Throughput of the collector system

5 總 結

本文首先討論了數(shù)據(jù)采集器的部署模式，提出了多核網(wǎng)絡處理器平臺下的數(shù)據(jù)采集架構.數(shù)據(jù)采集系統(tǒng)主要由控制平面和數(shù)據(jù)平面兩部分構成，控制平面運行于通用Linux系統(tǒng)，數(shù)據(jù)平面運行于SE系統(tǒng)，充分利用平臺的優(yōu)勢，兼具性能與靈活性.

在TLS協(xié)議實現(xiàn)過程中，客戶端與服務器實現(xiàn)的狀態(tài)機多種多樣，我們提出了一種狀態(tài)機無關的數(shù)據(jù)采集方法，達到更好的兼容性，并支持協(xié)議的靈活變化和擴展.此外，為減少私鑰轉(zhuǎn)換為對應封裝結構的時間開銷，提出了一種結構化私鑰信息緩存算法(PKES)算法，算法犧牲了少量的內(nèi)存空間換取到更高的性能.實驗表明，與常規(guī)私鑰查找算法PCS相比，PKES大大提高了系統(tǒng)CPS性能，當證書為1024位RSA密鑰時，系統(tǒng)CPS增長了130%，當證書為2048位RSA密鑰時，系統(tǒng)CPS增長了50%.系統(tǒng)性能較高，吞吐率可達2500Mbps.