[發(fā)明專利]一種基于SSL/TLS協(xié)議的流量快速轉(zhuǎn)發(fā)方法及系統(tǒng)

有效

• 申請?zhí)枺?/td>: 201910324087.0
• 申請日: 2019-04-22
• 公開（公告）號: CN111835688B
• 公開（公告）日: 2021-07-30
• 發(fā)明（設(shè)計）人: 宋磊;李傳宏;閆露;郭志川;韓陸超;劉磊
• 申請（專利權(quán)）人: 中國科學(xué)院聲學(xué)研究所;北京中科視云科技有限公司
• 主分類號: H04L29/06
• 分類號: H04L29/06;H04L12/727;H04L12/729;H04L9/08
• 代理公司: 北京方安思達(dá)知識產(chǎn)權(quán)代理有限公司 11472
• 代理人: 陳琳琳;楊青

本發(fā)明屬于網(wǎng)絡(luò)信息安全技術(shù)領(lǐng)域，具體涉及一種基于SSL/TLS協(xié)議的流量快速轉(zhuǎn)發(fā)方法，該方法包括：接收由客戶端發(fā)送的客戶端問候消息，并對其進(jìn)行修改，同時記錄客戶端隨機(jī)數(shù)；轉(zhuǎn)發(fā)修改后的客戶端問候消息至服務(wù)端；根據(jù)修改后的客戶端問候消息，獲得服務(wù)端問候消息；發(fā)送服務(wù)端問候消息至數(shù)據(jù)采集器，記錄服務(wù)端問候消息中的協(xié)議版本信息和加密套件信息，以及服務(wù)端隨機(jī)數(shù)；客戶端、數(shù)據(jù)采集器、服務(wù)端經(jīng)過相互認(rèn)證，三者相互之間建立SSL/TLS協(xié)議連接；根據(jù)支持SSL/TLS流量快速轉(zhuǎn)發(fā)的判斷準(zhǔn)則，判斷當(dāng)前連接是否支持快速轉(zhuǎn)發(fā)；該方法大大提升采集系統(tǒng)的性能，降低采集系統(tǒng)的傳輸時延。

技術(shù)領(lǐng)域

本發(fā)明屬于網(wǎng)絡(luò)信息安全技術(shù)領(lǐng)域，具體涉及一種基于SSL/TLS協(xié)議的流量快速轉(zhuǎn)發(fā)方法。

背景技術(shù)

SSL/TLS協(xié)議，即安全套接層/傳輸層安全協(xié)議(Secure Socket Layer/TransportLayer Security，SSL/TLS協(xié)議)，是目前應(yīng)用最廣泛的安全通信協(xié)議，運(yùn)行在可靠的傳輸層協(xié)議之上、各種應(yīng)用層協(xié)議之下，通過在客戶端和服務(wù)端之間建立安全的連接，防止通信雙方的消息被竊聽、篡改和偽造，從而為互聯(lián)網(wǎng)上的數(shù)據(jù)通信提供保密性、完整性、隱私性以及認(rèn)證等安全服務(wù)。SSL/TLS是分層協(xié)議，其包括：底層的記錄層協(xié)議、上層的改變加密說明協(xié)議、告警協(xié)議和握手協(xié)議。SSL/TLS協(xié)議的流程可分為兩個階段：SSL/TLS連接建立階段和數(shù)據(jù)傳輸階段?？蛻舳撕头?wù)端通過握手消息完成SSL/TLS連接的建立，隨后以密文形式安全傳輸應(yīng)用層數(shù)據(jù)。密文數(shù)據(jù)的傳輸依靠下層可靠的傳輸層協(xié)議。

SSL/TLS協(xié)議的廣泛使用，極大的滿足了用戶對于網(wǎng)絡(luò)通信安全的需求，但是，也帶來了一些問題。由于采用了SSL/TLS協(xié)議，所傳輸?shù)膽?yīng)用層數(shù)據(jù)均被加密，這給網(wǎng)絡(luò)監(jiān)管、流量審計帶來了極大的難題。針對這些難題，網(wǎng)絡(luò)數(shù)據(jù)的明文采集技術(shù)應(yīng)運(yùn)而生。作為合法中間人的明文采集系統(tǒng)串行接入至傳統(tǒng)的客戶端和服務(wù)端之間，在SSL/TLS連接建立階段，通過修改客戶端和服務(wù)端的握手消息，分別與客戶端和服務(wù)端建立一條SSL/TLS連接。兩條SSL/TLS連接擁有相同的密鑰，具體包括對稱密鑰和消息認(rèn)證碼密鑰。明文采集系統(tǒng)擁有兩條連接的所有密鑰，因此可以對客戶端和服務(wù)端所傳輸?shù)拿芪臄?shù)據(jù)進(jìn)行解密，從而達(dá)到采集明文數(shù)據(jù)的目的。

針對需要進(jìn)行密文數(shù)據(jù)審計的情形，現(xiàn)有的解決方案分為三種：第一種，如圖1所示，數(shù)據(jù)采集器作為TLS代理服務(wù)器串行接入客戶端和服務(wù)端之間，其分別與客戶端和服務(wù)端建立TLS連接，兩條TLS連接相互獨(dú)立。數(shù)據(jù)采集器獲取密文數(shù)據(jù)后，將密文數(shù)據(jù)解密，提取明文后，再將數(shù)據(jù)加密，發(fā)送到對端。該方案易于實現(xiàn)，但是，其也存在問題：數(shù)據(jù)采集器獲取到數(shù)據(jù)后，需要將數(shù)據(jù)解密成明文，再加密成密文發(fā)送到對端，這明顯會增加傳輸時延，降低TLS吞吐率。

第二種解決方案，如圖2所示，數(shù)據(jù)采集器不串接在客戶端和服務(wù)端之間，而是直接采集通信雙方的密文數(shù)據(jù)。數(shù)據(jù)采集器被服務(wù)端信任，并持有服務(wù)端的私鑰，因此，可以通過通信雙方的握手消息獲取預(yù)主密鑰，計算出通信雙方的共享密鑰，從而實現(xiàn)對雙方傳輸?shù)拿芪臄?shù)據(jù)進(jìn)行解密獲取明文。該方法實現(xiàn)簡單，但是，該方法必須掌握服務(wù)端的私鑰，導(dǎo)致該方案適用性受限。

第三種解決方案，如下圖3所示，基于中間人原理的明文采集方法。數(shù)據(jù)采集器作為合法中間人，串接在客戶端和服務(wù)端之間，在SSL握手階段通過修改通信雙方的握手消息，分別與客戶端和服務(wù)端建立一條連接，兩條連接具有相同的密鑰，且采集器持有該密鑰，從而可以實現(xiàn)對通信雙方密文數(shù)據(jù)的解密。該方案不需要對密文數(shù)據(jù)解密后再加密，因此，在相應(yīng)時間和吞吐率上有較中間人代理的方案有明顯的優(yōu)勢，但是，該方案也有存在問題：在需要對密文中的數(shù)據(jù)做內(nèi)容審計時，例如需要進(jìn)行協(xié)議解析或者對明文數(shù)據(jù)進(jìn)行修改等操作時，該方案則無能為力。

發(fā)明內(nèi)容