《電子技術應用》
您所在的位置:首頁 > 通信與網絡 > 業界動態 > SSL VPN記錄層協議的分析與改進

SSL VPN記錄層協議的分析與改進

2008-07-14
作者:侯 賓, 呂玉琴, 葉德信

??? 摘 要: 基于SSL協議的VPN系統,具有簡便、輕量級、基于部署等優點,可以提供安全的遠程接入和端到網絡邊緣的加密通道,具有廣闊的應用前景。對SSL協議的記錄層協議" title="記錄層協議">記錄層協議和基于虛擬設備的SSL VPN的數據封裝和傳輸機制進行了分析,提出了一種可以更好地支持端到端" title="端到端">端到端多媒體通信" title="多媒體通信">多媒體通信等應用的記錄層協議及數據傳輸機制的改進方案。
??? 關鍵詞: SSL VPN? 多媒體通信? 記錄層協議

?

??? 安全套接層協議[1]SSL,常用于建立安全的Web或電子郵件連接。隨著SSL協議的完善和網絡應用的發展,SSL協議得到了更廣泛的應用。SSL VPN就是SSL協議最常見的擴展應用。
??? SSL VPN和傳統的Web、EMAIL等SSL協議應用有所不同,SSL不再用來建立專用的端到端的安全通道,而是建立通用的、端到網絡邊緣的安全隧道,即客戶端" title="客戶端">客戶端到SSL網關之間的VPN連接。這種基于SSL協議的VPN技術具有靈活、簡便、兼容現有網絡架構等優點,因此得到了越來越廣泛的應用。本文對SSL協議在VPN應用下的紀錄層協議進行分析,并提出一種改進方法,使之可以對不同的應用實施不同的安全策略,增強端到端的多媒體通信,如對VoIP應用的支持。
1 SSL VPN技術分析
??? 首先對SSL協議的結構特別是記錄層協議的結構進行分析,并對SSL VPN的應用架構和數據傳輸流程進行分析,進而闡明SSL VPN技術的應用優勢和缺陷。
1.1 SSL協議體系結構
??? SSL協議結構可分為以下幾個主要部分:SSL握手協議、SSL改變密碼規范協議、SSL告警協議和SSL記錄層協議等[2]。其中,SSL握手協議負責身份認證、建立連接;SSL改變密碼規范協議負責數據傳輸中的協商密碼算法規范;SSL告警協議負責相關狀態的警告等;SSL記錄層協議則負責數據傳輸過程中的數據封裝和信息標識。
??? SSL記錄層協議規定完整的SSL數據包具有三部分:記錄頭(record header)、數據載荷(加密過的)和數據校驗(MAC)。記錄頭是SSL記錄協議中最重要部分,負責對SSL協議版本、數據類型等信息進行標識,其結構如下[1]
??? Struct{
  ????? ContentType type;? ??//內容信息結構
????????? ProtocolVersion version;? //協議版本號信息
????????? Uint16 length;?? ??//數據長度信息
??? }RecordHeader;??? ???//記錄頭結構定義
??? 記錄頭對SSL協議版本、負載數據類型等信息進行說明,使得通信雙方可以對數據進行不同的處理。SSL記錄頭在傳統的SSL應用中非常重要,然而在VPN應用中,由于和SSL VPN應用的架構特點有關,記錄頭的作用被弱化了。
1.2 基于虛擬設備的SSL VPN應用架構
??? 目前常見的SSL VPN應用大多采用虛擬設備的架構方式。即通過軟件方式實現具有NDIS(Network Driver Interface Specification)接口和流接口的虛擬網卡,進行VPN隧道的路由和封裝過程[3],典型例子如OPENVPN等。
??? 基于NDIS接口的虛擬網卡,實際上是在正常的網絡處理流程中加入一個中間層,使之對上層應用表現為網卡,并提供虛擬網卡行為的NDIS接口,而對真實網卡則表現為上層應用,提供一個流接口,其結構如圖1所示。

?

?

??? 基于NDIS虛擬網卡的SSL VPN的工作流程如下:
??? (1) 客戶端通過真實網卡和VPN網關進行SSL協議握手,得到“虛擬”IP地址和會話密鑰等信息,這個虛擬IP地址,一般是VPN網關所在的內網地址。虛擬IP地址被賦給虛擬網卡,而系統路由表也會作相應改動,使得需要的IP包都發送到虛擬網卡。
??? (2) 當上層應用需要通過VPN傳輸數據時,數據先經過TCP/IP" title="TCP/IP">TCP/IP協議棧封裝成IP包,而這些IP包的源地址就是虛擬網卡的IP地址,目的地址則可能是VPN內網的應用服務器地址等,在此將其稱為“虛擬”IP包。這些虛擬IP包會根據路由表被送到虛擬網卡的NDIS接口。
??? (3) 虛擬網卡獲得虛擬IP包后將其進行數據加密,加密后的包體再通過流接口發給TCP/IP協議棧進行再封裝,封裝好的IP包具有真實的源(客戶端)地址信息和目的(VPN網關)地址信息,稱為“真實”IP包,真實IP包通過真實網卡發送到VPN網關。
??? (4) 與VPN網關連接的對外真實網卡收到真實IP包后,解包得到加密后的虛擬IP包,并發送到服務器的虛擬網卡的流接口,虛擬網卡將數據解密,發到內網接口網卡上,并將其作為正常IP包,轉發到相應的目的地址(應用服務器、客戶端或其他網關等)。
??? (5) 當VPN網關向客戶端發送數據,或者內網用戶或內網服務器通過網關向VPN用戶發送數據時,流程相似。
??? 可以看出,在以上工作流程中,VPN操作獨立于TCP/IP協議棧操作,而且VPN通道可以向所有的上層應用提供路由、認證和封裝服務,因此這種應用架構具有良好的層次特性和對網絡協議的兼容性。
2 典型VPN應用中的SSL記錄層協議分析
??? 采用虛擬設備形式的SSL VPN,其握手協議等和SSL協議的傳統應用并無很大不同,但是在記錄層協議和數據傳輸模式上是有所區別的。
??? (1)記錄頭的作用被弱化,甚至被取消。所有的數據被明確地打包為虛擬IP包,通過TCP/IP協議即可保證其路由和完整性等要求;VPN隧道只傳輸虛擬IP包,不需要再對負載類型進行識別,因此,傳統記錄頭中的type、length等信息都可以省略;此外,數據也不再需要TCP/IP之外的數據校驗。
??? (2)利用SSL的傳統加密傳輸應用必須通過TCP協議來進行,而在基于虛擬設備的SSL VPN應用中,無需特別機制來關注鏈路是否會超時。因此,大多數情況可用UDP協議傳輸以減少通信開銷,而丟包等情況則只要通過重發數據包等就可解決。
??? (3)即使客戶端需要訪問多個服務,也只需要開放一個網關端口即可。這使得采用虛擬設備的VPN網關很容易和防火墻等設備相配合(只需在防火墻上開放一個端口即可實現全部VPN功能)。這也是SSL VPN較其他VPN方案(如IPSec VPN)的優勢之一。
??? 可以看出,采用虛擬設備的SSL VPN,對傳統SSL協議的記錄層協議和數據傳輸模式進行了改進,這種改進符合VPN應用的特點,使得SSL協議能夠更有效地應用在VPN領域。無論與傳統的SSL應用方式相比,還是與IPSec等其他熱門VPN技術相比,基于虛擬設備的SSL VPN技術都有難以替代的優點。然而,隨著其應用的不斷發展,這種VPN應用也出現了一些不足:
??? 首先,SSL VPN提供了端到網絡邊緣的安全通道,但是在某些情況下,用戶無法將端到端的加密通道和端到網絡邊緣的安全接入方案相結合。
??? 其次,不同的應用可能要求不同的傳輸效率和安全性,而目前的SSL VPN提供的是通用安全服務,對上層數據一視同仁,不能對特殊應用進行特殊優化,例如:當用戶進行VoIP通信時,多媒體數據在要求安全性的同時,對實時性要求也較高。
??? 在下面的遠程接入例子中,SSL VPN對點對點的多媒體通信支持較差的特點就表現出來了。
??? 圖2所示是一個典型的SSL VPN的應用場景。用戶UserA、UserB和UserC通過VPN 網關(Gate1、Gate2和Gate3)建立SSL VPN遠程連接到自己的Intranet(即圖中的粗線部分),而圖中兩個Intranet具有互聯互通的關系(可設想為跨國公司在不同地域的分公司)。

?


??? 在這個場景中,假設UserA要和UserC進行VoIP通話,這時雙方的數據通路是從UserA加密,再到Gate1解密,再明文經過Intranet傳輸(兩個Intranet之間可能是專線或IPSec VPN),之后再到Gate3被加密,最后到UserC被解密,反之亦然。可以看出,在這個場景中,多媒體數據沒有端到端的安全保障,卻進行了多次不必要的加解密操作,從而降低了數據傳輸的實時性。如果用戶有端到端的安全需求,還需要在SSL VPN之上,額外建立安全通道,造成安全通道的嵌套,而單獨的端到端安全通道又無法完成經過Intranet的路由和服務查詢等功能。如果UserB也參與通信,計算能力較低的手持終端和帶寬較窄的無線網絡將使得問題更加嚴重。
??? 因此,為了更好地支持VoIP等點對點多媒體通信,需要對SSL VPN的數據傳輸機制和記錄層協議(數據格式和處理流程)進行改進。
3 SSL記錄層協議和數據處理流程的改進
??? 選擇SSL記錄層協議進行改進主要是由于SSL協議處在傳輸層,因此具有支持對上層應用進行識別和分析的可能性。而且SSL記錄層協議中規定的記錄頭結構,也可以在VPN應用中進行有效的利用。
??? 通過對SSL協議和VPN應用場景的分析,可以進行如下改進策略:(1)改進記錄頭結構,加入上層應用的相關信息,例如:可以將應用程序在客戶端VPN服務中進行注冊,當不同的應用調用VPN服務時,可為數據打上不同的記錄頭。(2)對于端到端加密的數據,VPN網關進行識別并將數據直接轉發到目的地址,從而做到數據在原客戶端加密而在目的客戶端解密。即對SSL記錄頭格式和VPN數據的處理流程進行改進。
3.1 記錄頭格式的改進
??? 首先,將SSL的記錄頭加在客戶端虛擬網卡的加密IP包之后;然后,對SSL記錄頭數據結構中的內容作適當刪減,以減少數據冗余,并加入路由等需要的信息,修改后的記錄頭具有如下結構:
??? 記錄頭結構(精簡后):
???????? Struct{
  ?????????? ProtocolVersion version;? ?//協議信息
  ?????????? VPNStruct vpn;???//VPN處理信息
???????? }RecordHeader;
??? 加入VPN路由信息結構:
 ?????? Struct{
???????? Uint16 SourceIP;?????? //源“虛擬”IP地址
???????? Uint16 Destination IP;????? //目標IP地址
???????? Uint16 SoucePort;?????? //源“虛擬”端口
???????? Uint16 Desination Port;????? //目的端口
???????? ApplicaitonInfomation appinfo;? //應用信息
 ??? } VPNStruct
??? 其中,應用信息ApplicaitonInfomation為如下枚舉類型:
??? Enum{
?????? Default(0);??? ?//默認類型
?????? VPNtype(1);?? //普通VPN類型
?????? P2Ptype(2);??? //多媒體通信、點對點類型
?????? (255);??//保留
??? } ApplicaitonInfomation
??? VPNStruct記錄了數據的地址信息,并且在appinfo字段表明了承載的應用類型,指示沿途的出入網關應當采取的不同處理方式。
3.2 VPN數據處理流程的改進
??? 記錄頭的改進,使系統對于數據的處理可以根據應用數據的不同而有所區別:客戶端虛擬設備會在加密完虛擬IP包后,加入明文記錄頭。當進行正常通信時,VPN網關得到數據包后,根據appinfo字段提示,會選擇將數據解密并正常轉發,反之亦然。
??? 而進行多媒體通信時,客戶端之間首先進行端對端的握手流程。會話密鑰商定后,數據發送方的虛擬設備將數據加密(采用端到端的會話密鑰),加入明文記錄頭,以對此數據流性質進行描述。當VPN網關獲得虛擬IP包時,可以通過明文記錄頭對數據進行識別。當發現數據類型為端到端加密類型(P2Ptype)時,VPN網關將數據打入TCP/IP協議棧、按P2Ptype中的源地址、目的地址進行重新封裝和轉發,整體流程如圖3所示。

?


??? VPN對數據的處理和原有流程的區別在于:(1)入口VPN(圖2中的Gate 1)并不將虛擬IP包解密、轉發,而是將其和記錄頭作為應用負載進行封裝后轉發。(2)出口VPN(圖2中的Gate 2),并不對數據進行再加密,而只是封裝轉發。(3)在軟件實現上,如果內網用戶希望得到端到端的安全通道,也必須采用虛擬設備機制,處理機制和上述過程相同。
3.3 改進性能分析
?? ?在安全性方面,改進后的應用架構兼顧了SSLVPN在遠程接入功能上的靈活性和安全性,并且提供了更加高效的端對端安全服務,既可以支持正常的VPN應用,也可以更好地支持端到端的多媒體通信應用。此外,由于專門的端對端安全協議無法提供遠程接入功能,因此,當多媒體通信的服務器(如SIP注冊服務器等)架設在內網時,將無法提供用戶的安全注冊、查詢功能,而本文方案則可以提供安全的注冊、查詢服務。
??? 在傳輸處理效率上,改進方案減少了不必要的數據加解密開銷,減輕了網關服務器負擔,也減少了數據處理的時間。本文方案增加了對記錄頭的識別和對網關進行TCP/IP協議再封裝過程,但這些流程都是線形的讀寫操作,與對稱加解密流程的數據置換、疊加等處理相比要簡單得多,因此開銷也小得多。此外,系統還支持對多媒體數據采用單獨加密算法的特性,例如對于普通數據進行3DES加密,對多媒體數據采用更快速的RC4加密。這樣使得系統對多媒體數據的傳輸、處理效率更高。
??? 在對現有軟硬件環境的兼容上,改進方案保持了SSL VPN的優勢:兼容性好、實現簡單。首先不需要對應用程序、TCP/IP協議棧和硬件設備做任何改動,改動僅局限在SSL控制邏輯和虛擬設備驅動程序上;其次,本文方案可部署在現有絕大多數的網絡當中,只要開放相應的防火墻端口即可實現全部應用。
??? 綜上所述,本文結合基于虛擬設備實現的SSL VPN應用的具體特點,通過對SSL記錄頭結構和VPN數據處理流程的改進,可以在保持SSL VPN安全性好、輕量級、兼容性好等傳統優勢的前提下,進一步提高SSL VPN的應用范圍和靈活性,特別是對多媒體通信的安全性和實時性具有更好的支持。
參考文獻
[1] ?RFC2246: The TLS protocol version 1.0[s]. IETF,1999.
[2] ?RESCORLA E. SSL與TLS.北京:中國電力出版社,2002.
[3] ?蔣勵,張新.支持多媒體業務的VPN網絡[J]. 西安郵電學院學報, 2002,7(1).
[4] ?韓衛,薛健,白靈. 一種基于安全隧道技術的SSL VPN及其性能分析. 科學技術與工程[J], 2005,5(12).
[5] ?易光華,傅光軒,胡艷. 一種基于SSL的VPN的研究與實現[J]. 貴州大學學報:自然科學版,2006,23(2).
[6] ?陳愛和,徐敬東, 劉曉欣,等.支持多路負載平衡的SSL VPN系統的設計與實現[J]. 計算機工程與設計, 2006,27(21).

本站內容除特別聲明的原創文章之外,轉載內容只為傳遞更多信息,并不代表本網站贊同其觀點。轉載的所有的文章、圖片、音/視頻文件等資料的版權歸版權所有權人所有。本站采用的非本站原創文章及圖片等內容無法一一聯系確認版權者。如涉及作品內容、版權和其它問題,請及時通過電子郵件或電話通知我們,以便迅速采取適當措施,避免給雙方造成不必要的經濟損失。聯系電話:010-82306118;郵箱:[email protected]
主站蜘蛛池模板: 久久精品视频免费播放 | 91精品国产91久久久久久 | 香蕉tv亚洲专区在线观看 | 国产日韩欧美一区二区 | 国产美女野外做爰 | 成人α片 | 一本久 | 亚洲免费在线视频播放 | 日韩中文字幕视频 | 黄色三级视频在线 | 伊人情人综合网 | 成人午夜天 | 日本强不卡在线观看 | 日本成人在线免费观看 | 六月丁香婷婷天天在线 | free性欧美嫩交 | 免费观看一级成人毛片 | 国产一区二区久久精品 | 成人a毛片视频免费看 | 欧美一区二区三区精品影视 | 欧美日韩视频一区二区 | 久热久操 | 日韩欧美国产精品第一页不卡 | 成人欧美 | dvd8090cnm欧美大片 | 精品视自拍视频在线观看 | 国产特黄特色一级特色大片 | 国产午夜久久影院 | 六月成人网 | 日本亚欧乱色视频在线网站 | 色综合精品| 国产精品黄页网站在线播放免费 | 成人毛片网 | 国产亚洲午夜精品a一区二区 | 成人免费观看网欧美片 | 欧美在线一区二区三区精品 | 精品一区二区三区在线观看 | 欧美xxxxxxxx| 成人三级在线播放线观看 | 亚洲成人在线播放视频 | 日韩高清成人毛片不卡 |