本發(fā)明屬于網(wǎng)絡(luò)安全通信技術(shù)領(lǐng)域，具體涉及到一種基于鏡像流的ssl/tls協(xié)議明文數(shù)據(jù)采集方法。

背景技術(shù)：

ssl協(xié)議及其繼任者tls協(xié)議，是為網(wǎng)絡(luò)安全提供安全性及數(shù)據(jù)完整性的一種安全協(xié)議。ssl/tls協(xié)議位于tcp/ip協(xié)議和應(yīng)用層協(xié)議之間，可為各種應(yīng)用層協(xié)議提供安全性保證，例如ftp、telnet協(xié)議等，目前ssl/tls協(xié)議最廣泛的應(yīng)用是保護(hù)http協(xié)議安全。ssl/tls協(xié)議包括兩層：記錄層協(xié)議和握手協(xié)議。記錄協(xié)議為高層握手協(xié)議提供基本的安全服務(wù)，保證數(shù)據(jù)完整性，具體包括壓縮解壓縮、加解密、計(jì)算和校驗(yàn)mac等。握手層協(xié)議包括握手協(xié)議、密碼參數(shù)修改協(xié)議、告警協(xié)議和應(yīng)用數(shù)據(jù)協(xié)議，用于通信雙方認(rèn)證、協(xié)商加密算法和生成秘鑰等。

由ssl/tls協(xié)議保護(hù)的高層協(xié)議在客戶端與服務(wù)器之間傳輸?shù)臑槊芪臄?shù)據(jù)，并沒有明文出現(xiàn)，這為數(shù)據(jù)審計(jì)帶來了困難。需采取一些技術(shù)手段，將ssl/tls通信過程中密文數(shù)據(jù)解密為明文數(shù)據(jù)，再對相應(yīng)明文數(shù)據(jù)進(jìn)行解析審計(jì)。如圖1所示，現(xiàn)有技術(shù)中，通常在客戶端與服務(wù)器之間引入ssl/tls代理服務(wù)器，代理服務(wù)器串聯(lián)在客戶端與服務(wù)器之間，分別與客戶端、服務(wù)器建立兩條ssl/tls連接。由于ssl/tls代理服務(wù)器需獲得數(shù)據(jù)后，進(jìn)行解密獲得明文數(shù)據(jù)，再將明文數(shù)據(jù)加密發(fā)送至客戶端，額外的加密操作為系統(tǒng)帶來了負(fù)擔(dān)，導(dǎo)致系統(tǒng)響應(yīng)時間變長、吞吐率降低。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明的目的在于克服目前ssl/tls通信過程中將密文數(shù)據(jù)解密為明文數(shù)據(jù)時存在的上述缺陷，提出了一種基于鏡像流的ssl/tls協(xié)議明文數(shù)據(jù)采集方法，通過該方法可以不通過ssl/tls代理服務(wù)器，直接利用合法持有的服務(wù)器證書及私鑰對ssl/tls協(xié)議的密文數(shù)據(jù)進(jìn)行解析，從而直接獲得明文數(shù)據(jù)，減少了中間環(huán)節(jié)，提高了明文數(shù)據(jù)的獲取的效率。

為了實(shí)現(xiàn)上述目的，本發(fā)明提出了一種基于鏡像流的ssl/tls協(xié)議明文數(shù)據(jù)采集方法，所述方法包括：

步驟1)接收鏡像的ssl/tls數(shù)據(jù)包，對數(shù)據(jù)包中的記錄進(jìn)行提取，生成若干個完整記錄，放入記錄隊(duì)列；

步驟2)從記錄隊(duì)列里的記錄中提取若干個完整消息，放入消息隊(duì)列；

步驟3)對消息隊(duì)列中的消息進(jìn)行解析，獲取明文數(shù)據(jù)。

上述技術(shù)方案中，所述步驟1)具體包括：

步驟101)接收鏡像的ssl/tls數(shù)據(jù)包；

步驟102)從數(shù)據(jù)包中提取出第一條記錄，查看記錄緩存區(qū)是否有緩存記錄，若不存在緩存記錄，則直接計(jì)算接收的第一條記錄的長度；若記錄緩存區(qū)中存在緩存記錄，則將數(shù)據(jù)包拼接至緩存記錄后，計(jì)算出當(dāng)前緩存的第一條記錄的長度；

步驟103)將第一條記錄的長度和數(shù)據(jù)包長度進(jìn)行比較，若第一條記錄的長度加記錄頭長度等于數(shù)據(jù)包長度，轉(zhuǎn)入步驟104)；若第一條記錄的長度加記錄頭長度小于數(shù)據(jù)包長度，轉(zhuǎn)入步驟105)；若第一條記錄的長度加記錄頭長度大于數(shù)據(jù)包長度，轉(zhuǎn)入步驟106)；

步驟104)將該記錄放入記錄隊(duì)列；

步驟105)對數(shù)據(jù)包進(jìn)行拆分，循環(huán)提取單條完整的記錄放入記錄隊(duì)列，并將最后不完整的記錄放入記錄緩存區(qū)；

步驟106)將該記錄放入記錄緩存區(qū)；轉(zhuǎn)入步驟101)；

放入記錄緩存區(qū)的不完整記錄等待后續(xù)的數(shù)據(jù)包進(jìn)行拼接，然后再生成完整記錄。

上述技術(shù)方案中，所述步驟2)具體包括：

步驟201)從記錄隊(duì)列里取出一個記錄作為當(dāng)前記錄，

步驟202)查看當(dāng)前記錄的類型，若當(dāng)前記錄類型為應(yīng)用數(shù)據(jù)協(xié)議、改變密碼規(guī)范協(xié)議或告警消息，轉(zhuǎn)入步驟203)；若當(dāng)前記錄類型握手協(xié)議，轉(zhuǎn)入步驟204)；

步驟203)當(dāng)前記錄為單條完整的消息，放入消息隊(duì)列；

步驟204)查看消息緩存區(qū)是否有緩存消息，若不存在緩存消息，則直接計(jì)算當(dāng)前記錄中第一條消息的長度；若緩存中存在緩存消息，則將當(dāng)前記錄拼接至緩存消息后，計(jì)算出當(dāng)前緩存的第一條消息的長度；

步驟205)將計(jì)算的第一條消息的長度和當(dāng)前記錄長度進(jìn)行比較，若第一條消息的長度加消息頭長度等于當(dāng)前記錄長度，轉(zhuǎn)入步驟206)；若第一條消息的長度加消息頭長度小于當(dāng)前記錄長度，轉(zhuǎn)入步驟207)；若第一條消息的長度加消息頭長度大于當(dāng)前記錄長度，轉(zhuǎn)入步驟208)；

步驟206)當(dāng)前記錄為單條完整消息，放入消息隊(duì)列；

步驟207)當(dāng)前記錄內(nèi)含有多條消息，則對該記錄進(jìn)行拆分，循環(huán)提取若干條完整的消息放入消息隊(duì)列；并將最后不完整的消息放入消息緩存區(qū)；

步驟208)當(dāng)前記錄為一條不完整的消息，放入消息緩存區(qū)，轉(zhuǎn)入步驟201)；

放入消息緩存區(qū)的不完整消息等待后續(xù)的記錄進(jìn)行拼接，然后再生成完整消息。

上述技術(shù)方案中，所述步驟3)的具體實(shí)現(xiàn)過程為：

從消息隊(duì)列中取出一條消息，若消息類型為握手協(xié)議，則提取密碼規(guī)范和秘鑰信息；若消息類型為改變密碼協(xié)議規(guī)范，則接下來的記錄都會用新協(xié)商的密碼規(guī)范和秘鑰來保護(hù)；若消息類型為告警消息，則分析消息的嚴(yán)重性與告警描述；若消息類型為應(yīng)用數(shù)據(jù)協(xié)議，則利用提取的密碼規(guī)范和秘鑰對傳輸數(shù)據(jù)進(jìn)行解密，獲取明文數(shù)據(jù)。

上述技術(shù)方案中，所述握手協(xié)議包括：clienthello、serverhello、severcertificate、serverhellodone、clientkeyexange、newsessionticket和finished,所述提取密碼規(guī)范和秘鑰信息的具體步驟為：

步驟301)若握手協(xié)議類型為clienthello，則記錄客戶端隨機(jī)數(shù)、session_id和session_ticket；

步驟302)若握手協(xié)議類型為serverhello，則判斷是否發(fā)生會話重用，若發(fā)生會話重用，則從緩存會話信息中提取主秘鑰和加密算法規(guī)范，并生成密碼參數(shù)；若沒有發(fā)生會話重用，則記錄協(xié)議版本、服務(wù)端隨機(jī)數(shù)、sesseion_id、加密套件和壓縮算法；

步驟303)若握手協(xié)議類型為severcertificate，則提取服務(wù)器公鑰，查找匹配證書獲取服務(wù)器私鑰；

步驟304)若握手協(xié)議類型為serverhellodone，則此時服務(wù)端已經(jīng)完成秘鑰交換消息；

步驟305)若握手協(xié)議類型為clientkeyexange，則利用服務(wù)器解密預(yù)主秘鑰，計(jì)算主秘鑰，并生成安全參數(shù)；若該會話為新回話，則將會話信息進(jìn)行緩存；

步驟306)若握手協(xié)議類型為newsessionticket，若此時沒有發(fā)生會話重用，則填入緩存的會話信息中session_tiket項(xiàng)，若發(fā)生會話重用，則將緩存的會話信息中session_tieket項(xiàng)進(jìn)行更新；

步驟307)若握手協(xié)議類型為finished，則驗(yàn)證相應(yīng)方向的全部握手?jǐn)?shù)據(jù)，待兩方均驗(yàn)證通過后，即可開始應(yīng)用數(shù)據(jù)傳輸。

上述技術(shù)方案中，所述步驟3)還包括：獲取明文數(shù)據(jù)后，對明文數(shù)據(jù)進(jìn)行解析，生成審計(jì)日志并進(jìn)行存儲。

與現(xiàn)有技術(shù)相比，本發(fā)明的優(yōu)勢在于：

1、本發(fā)明的方法根據(jù)ssl/tls協(xié)議的封裝格式，將數(shù)據(jù)包拼接成完成記錄、進(jìn)一步提取完整的單個消息之后再處理，對服務(wù)器是否將多個消息合成一個記錄或者將單個消息封裝到多個記錄之中沒有要求，且可以靈活選擇加入需要解析的新消息，可擴(kuò)展性好；

2、本發(fā)明的方法對交換機(jī)鏡像數(shù)據(jù)進(jìn)行處理獲取明文數(shù)據(jù)，與傳統(tǒng)的引入代理服務(wù)器方式相比，不干涉系統(tǒng)原有業(yè)務(wù)，不影響系統(tǒng)性能。

附圖說明

圖1為現(xiàn)有的ssl/tls協(xié)議明文數(shù)據(jù)采集系統(tǒng)示意圖；

圖2為本發(fā)明的基于鏡像流的ssl/tls協(xié)議明文數(shù)據(jù)采集方法的流程圖；

圖3為本發(fā)明一個實(shí)施例的基于鏡像流的ssl/tls協(xié)議明文數(shù)據(jù)采集系統(tǒng)示意圖。

具體實(shí)施方式

下面結(jié)合附圖和優(yōu)選實(shí)施例對本發(fā)明進(jìn)行詳細(xì)說明。

如圖2所示，一種基于鏡像流的ssl/tls協(xié)議明文數(shù)據(jù)采集方法，所述方法包括：

步驟1)接收鏡像的ssl/tls數(shù)據(jù)包，對數(shù)據(jù)包中的記錄進(jìn)行提取，生成若干個完整記錄，放入記錄隊(duì)列；具體包括：

步驟101)接收鏡像的ssl/tls數(shù)據(jù)包；

步驟102)從數(shù)據(jù)包中提取出第一條記錄，查看記錄緩存區(qū)是否有緩存記錄，若不存在緩存記錄，則直接計(jì)算接收的第一條記錄的長度；若記錄緩存區(qū)中存在緩存記錄，則將數(shù)據(jù)包拼接至緩存記錄后，計(jì)算出當(dāng)前緩存的第一條記錄的長度；

ssl/tls協(xié)議記錄封裝格式如表1所示，其中記錄頭共5字節(jié)：

表1

步驟103)將第一條記錄的長度和數(shù)據(jù)包長度進(jìn)行比較，若第一條記錄的長度加記錄頭長度等于數(shù)據(jù)包長度，轉(zhuǎn)入步驟104)；若第一條記錄的長度加記錄頭長度小于數(shù)據(jù)包長度，轉(zhuǎn)入步驟105)；若第一條記錄的長度加記錄頭長度大于數(shù)據(jù)包長度，轉(zhuǎn)入步驟106)；

步驟104)將該記錄放入記錄隊(duì)列；

放入記錄隊(duì)列中的記錄為完整記錄。

步驟105)對數(shù)據(jù)包進(jìn)行拆分，循環(huán)提取單條完整的記錄放入記錄隊(duì)列，并將最后不完整的記錄放入記錄緩存區(qū)；

步驟106)將該記錄放入記錄緩存區(qū)；轉(zhuǎn)入步驟101)；

放入記錄緩存區(qū)的不完整記錄等待后續(xù)的數(shù)據(jù)包進(jìn)行拼接，然后再生成完整記錄。

步驟2)從記錄隊(duì)列里的記錄中提取若干個完整消息，放入消息隊(duì)列；

由于ssl/tls協(xié)議記錄不作為消息的邊界，因此在提取出完整記錄后，需進(jìn)一步提取完整消息，所述步驟2)具體包括：

步驟201)從記錄隊(duì)列里取出一個記錄作為當(dāng)前記錄，

步驟202)查看當(dāng)前記錄的類型，若當(dāng)前記錄類型為應(yīng)用數(shù)據(jù)協(xié)議、改變密碼規(guī)范協(xié)議或告警消息，轉(zhuǎn)入步驟203)；若當(dāng)前記錄類型握手協(xié)議，轉(zhuǎn)入步驟204)；

ssl/tls記錄握手消息格式如表2所示，其中消息頭共4字節(jié)：

表2

步驟203)當(dāng)前記錄為單條完整的消息，放入消息隊(duì)列；

步驟204)查看消息緩存區(qū)是否有緩存消息，若不存在緩存消息，則直接計(jì)算當(dāng)前記錄中第一條消息的長度；若緩存中存在緩存消息，則將當(dāng)前記錄拼接至緩存消息后，計(jì)算出當(dāng)前緩存的第一條消息的長度；

步驟205)將計(jì)算的第一條消息的長度和當(dāng)前記錄長度進(jìn)行比較，若第一條消息的長度加消息頭長度等于當(dāng)前記錄長度，轉(zhuǎn)入步驟206)；若第一條消息的長度加消息頭長度小于當(dāng)前記錄長度，轉(zhuǎn)入步驟207)；若第一條消息的長度加消息頭長度大于當(dāng)前記錄長度，轉(zhuǎn)入步驟208)；

步驟206)當(dāng)前記錄為單條完整消息，放入消息隊(duì)列；

步驟207)當(dāng)前記錄內(nèi)含有多條消息，則對該記錄進(jìn)行拆分，循環(huán)提取若干條完整的消息放入消息隊(duì)列；并將最后不完整的消息放入消息緩存區(qū)；

步驟208)當(dāng)前記錄為一條不完整的消息，放入消息緩存區(qū)，轉(zhuǎn)入步驟201)；

放入消息緩存區(qū)的不完整消息等待后續(xù)的記錄進(jìn)行拼接，然后再生成完整消息。

步驟3)對消息隊(duì)列中的消息進(jìn)行解析，獲取明文數(shù)據(jù)；

從消息隊(duì)列中取出一條消息，若消息類型為握手協(xié)議，則提取密碼規(guī)范和秘鑰 信息；若消息類型為改變密碼協(xié)議規(guī)范，則接下來的記錄都會用新協(xié)商的密碼規(guī)范和秘鑰來保護(hù)；若消息類型為告警消息，則分析消息的嚴(yán)重性與告警描述；若消息類型為應(yīng)用數(shù)據(jù)協(xié)議，則利用提取的密碼規(guī)范和秘鑰對傳輸數(shù)據(jù)進(jìn)行解密，獲取明文數(shù)據(jù)。

所述握手協(xié)議包括：clienthello、serverhello、severcertificate、serverhellodone、clientkeyexange、newsessionticket和finished,所述提取密碼規(guī)范和秘鑰信息的具體步驟為：

步驟301)若握手協(xié)議類型為clienthello，則記錄客戶端隨機(jī)數(shù)、session_id和session_ticket；

步驟302)若握手協(xié)議類型為serverhello，則判斷是否發(fā)生會話重用，若發(fā)生會話重用，則從緩存會話信息中提取主秘鑰和加密算法規(guī)范，并生成密碼參數(shù)；若沒有發(fā)生會話重用，則記錄協(xié)議版本、服務(wù)端隨機(jī)數(shù)、sesseion_id、加密套件和壓縮算法；

步驟303)若握手協(xié)議類型為severcertificate，則提取服務(wù)器公鑰，查找匹配證書獲取服務(wù)器私鑰；

步驟304)若握手協(xié)議類型為serverhellodone，則此時服務(wù)端已經(jīng)完成秘鑰交換消息；

步驟305)若握手協(xié)議類型為clientkeyexange，則利用服務(wù)器解密預(yù)主秘鑰，計(jì)算主秘鑰，并生成安全參數(shù)；若該會話為新回話，則將會話信息進(jìn)行緩存；

步驟306)若握手協(xié)議類型為newsessionticket，若此時沒有發(fā)生會話重用，則填入緩存的會話信息中session_tiket項(xiàng)，若發(fā)生會話重用，則將緩存的會話信息中session_tieket項(xiàng)進(jìn)行更新；

步驟307)若握手協(xié)議類型為finished，則驗(yàn)證相應(yīng)方向的全部握手?jǐn)?shù)據(jù)，待兩方均驗(yàn)證通過后，即可開始應(yīng)用數(shù)據(jù)傳輸。

在該實(shí)施例中，所述明文數(shù)據(jù)為http數(shù)據(jù)，將明文數(shù)據(jù)進(jìn)行解析，獲取url等等字段生成審計(jì)日志并保存，以供審計(jì)人員后續(xù)進(jìn)行審計(jì)。

如圖3所示，通過本發(fā)明的方法，客戶端與服務(wù)器建立ssl/tls連接，采集裝置利用交換機(jī)鏡像獲取客戶端與服務(wù)器之間交互數(shù)據(jù)，采集裝置合法持有服務(wù)器證書與私鑰。

最后所應(yīng)該說明的是，以上實(shí)施例僅用以說明本發(fā)明的技術(shù)方案而非限制，盡管參照實(shí)施例對本發(fā)明進(jìn)行了詳細(xì)說明，本領(lǐng)域的技術(shù)人員應(yīng)當(dāng)理解，可以對本發(fā)明的技術(shù)方案進(jìn)行修改或同等替換，都不脫離本發(fā)明技術(shù)方案的精神和范圍，其均 應(yīng)涵蓋在本發(fā)明的權(quán)利要求范圍當(dāng)中。