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).