VPN的基本素质：

　　1．方便的安装和自动的操作管理。VPN的安装和管理应当像Hub一样简单，它们应当无需人工配置或对设备的维护。

　　2．动态连接。VPN通过网络进行的再发送应当方便且高效，这主要决定于用户和机构应用的需要。此外，由于必须对动态路由选择做出判定，因而，它们应当具有必要的优化带宽的智能性，因为IP网络的静态配置不能满足企业连续处理连通性改变的需要。

　　3．安全性。VPN必须提供全面的安全性，以确保公共网上重要数据的安全传输。除了封装和加密之外，所有携带安装和维护信息进入控制路径的数据都必须得到保护。VPN也必须是开放并且是适应于标准的，以便保证将来验证和网络安全技术的实施。

　　怎样选择合适的VPN

　　VPN市场的产品和服务增长迅速。与此相对应，许多VPN厂商在定义和配置VPN的标准上也加入了竞争。IPSec作为一个数据封装协议，定义了验证和加密的过程。虽然IETF为IPSec定义了一个主要的管理协议，但许多厂商也正在其VPN产品中迅速地实施IPSec标准及其相关的安全机制。

　　目前，VPN产品主要分为软件和硬件两类：

　　软VPN价格低、性能略差

　　基于软件的产品其范围从单一的IPSec实施到加入现有路由器、网关和防火墙中的各种数据封装产品。通常，软件产品的价格都低于硬件产品价格，但是它们在性能、全面的安全性和干扰检测、可靠性以及易于安装和管理等很多方面都存在弱点。

　　硬VPN也非十全十美

　　由于这些原因，基于硬件的VPN设备常常就是一个更好的选择。它们将加密/解密置于高速的硬件中，更好地防止了非法入侵，它们的操作也更为简单。不过，这种硬件方案非常昂贵，其价格范围从3500美元到1万美元或更高。硬件方案也有缺陷：

　　1．操作困难。简单性是它固有的特性，但VPN的硬件加密机也给操作带来了大量的额外开销。VPN的安装通常需要熟练的技术专家来对其进行配置、寻址以及完成其它的必需设置。另外，提供新的服务、负载均衡和其它的管理需要，也加重了操作的负担。

　　2．布局的不变性。今天的产品仅仅适合于点到点的连接，它们不能在高度动态的网络上很好地进行连接，因为它们没有添加智能的路由器，因而就造成了费用和系统复杂性的增加。

　　3．有限的安全管理。虽然多数硬件产品支持通过VPN进行数据传输的 IPSec验证、完整性和加密技术，但是它们很容易受到黑客的攻击，例如对设置和完成VPN连接管理的重要控制协议的电子欺骗。

特点与趋势

　　1、VPN产品的市场需求将迅速增加。“十五”期间我国将对信息产业新增投入巨大，信息化(尤其是政府信息化)将在未来五年成为VPN产品市场发展的“助推器”。

　　2、更多的IT厂商将投入生产VPN产品。VPN产品是高投入、高回报的网络安全产品，赛迪顾问预计，到2005年，进入中国VPN产品市场的厂商数量在100～200家左右。

　　3、产品的安全性和保密性将日趋完善。目前，许多在安全性和保密性方面要求较高的行业(如军队等)，对VPN产品的选择和应用非常谨慎，因为目前的VPN产品还不能完全满足其安全、高效、稳定地传输数据和信息的需要。所以，对于未来VPN产品的发展，应用先进的技术，增强产品的功能将成为满足用户进一步需求的一个重要因素。

　　4、厂商的服务质量将会有实质性的提高

　　VPN产品作为一类特殊的通过加密手段传输数据、信息的网络安全产品，服务质量的高低直接影响了用户的购买行为。VPN产品大规模的应用必须是以VPN厂商提供高质量的服务为前提的。因此，在VPN产品大量应用的前提下，厂商为用户提供的服务在质量上必将会有实质性的提高。

　　SSL VPN：远程安全接入必备

　　目前，SSL VPN技术在网络安全领域发展很快。

　　据Infonetics研究公司报告，今年第二季度全球VPN和防火墙软硬件收入7.225亿美元，比第一季度下滑1%。但全球SSL VPN收入比第一季度增长10%，明年第二季度将增长92%，分析师预测，2003～2007年年收入将增长467%。到2007年SSL VPN的市场份额将扩大到13%。

　　如何安全地随时随地访问企业资源

　　　当前信息化企业巨大的数据库和强大的应用，已经是企业竞争力的重要部分。企业的应用更加多样，包括CRM、ERP、OA和各种行业应用系统。而企业网的外延也不断扩大，其用户不仅是企业内部的管理者和员工，也包括了企业外部的合作伙伴，甚至包括企业的客户，如供应链管理系统、人力资源外包、客户服务系统和企业电子商务系统。

　　企业管理层最关注的问题之一就是，如何更有效率地使用这些投资巨大的信息系统，让商业流程永不中断？如何增加企业网络的接入访问，使得企业的员工，合作伙伴和客户可以在任何时间、任何地点、使用任何设备访问企业信息资源和应用。

　　SSL VPN解决方案是实现企业远程接入的最佳方法之一。不仅实现成本低，而且还可以确保用户随时随地通过任何接入设备（只要可以浏览互联网）接入企业信息网。SSL VPN是平衡访问自由度和安全性的出色解决方案，“无客户端软件”的技术使其易于使用和维护。

　　　SSL VPN为何难以普及

　　影响SSL VPN投入使用的因素主要有以下两点：

　　一是服务器端的部署和技术支持维护问题。SSL VPN的使用非常方便，但是在服务器端的部署和支持维护是否便捷省时至关重要，企业应该予以充分考虑。

　　二是客户端的安全问题。虽然SSL VPN产品无需在客户端进行任何的设置，但是在确保整体应用的安全方面，如何判断和管理客户端的安全性十分重要。SSL VPN面临的接入用户非常复杂，用户采用的设备甚至可能是路边的信息亭，或使用的接入网络是WLAN。为了避免用户使用的接入设备成为攻击的跳板，除了采用强身份认证以外，引入设备安全扫描将实现最大的安全性。

　　目前SSL VPN应用在国内尚未走向普及。原因有很多，其中主要是国内企业的信息化应用程度问题。SSL VPN解决方案可以实现的访问应用主要有：电子邮件、PIM（个人信息管理）、内部网资源、CRM/ERP等企业核应用。目前，国内企业的信息化程度不高，虽然这些应用都已投入使用，但不是所有的应用都会开放给远程接入。而且，有些信息化程度高的企业大多实施了IPSec VPN解决方案，对其的信任程度也较高。用户接受SSL VPN解决方案，并投入实际使用还需要一定的过程。

SSL VPN的认证方式

SSL VPN的认证方式有很多种，这个问题也是大部分客户在做SSL VPN选型的时候重点考察的一项。

在我所接触的SSL VPN的产品中，各家公司对这个问题的处理方式和重视程度也不是很一样。客户在选型的时候也有不同的喜好，大家的希望就是能和自有现有系统能够完美结合，这个都是各个客户最乐见的。

其实客户的现有的认证系统是多种多样的，所以这个就给 SSL VPN厂家出了不少的难题。如果让用户接受本厂家现有的认证系统对客户来讲又是一个问题，势必使得采购了新的系统后所有的使用者就得新记住一组用户名和密码，还不仅仅是这个问题，新的认证使用可能会使得客户的整个系统中互通性成了问题。

单点登陆是一个重要的问题，这个就对后来上的系统提出了较高的要求。特别是SSL VPN这种第三方通用产品要求能够兼容大部分的认证系统。这是一个矛盾。

讲讲目前我所见到的大部分的SSL VPN 的认证方式:

1,最常见的方式就是建立本地数据库的模式，这种模式其实就是另立一套单独的系统；

2，兼容 MS  Active Directory 的认证方式，这种方式其实就是

3，兼容LDAP

4，兼容RADIUS

5，数字证书，

6，USB KEY数字证书

7,手机短信认证，这是一种中国特色的认证方式，但是具体的ssl vpn 产品采用此认证方式我还没有见到；

8，灵牌认证，比如，RSA令牌，active card令牌等等。

关于USB KEY的方式，最近十客户讨论的最多的一种方式。从CA的角度来看，通常将USB KEY分为两种：支持RSA算法的和不支持RSA算法的。两者均可以存放数字证书的私钥等相关信息，其中对于自带算法的KEY，它可以自行产生密钥对，而且与私钥有关的运算，比如签名运算和加密运算均在KEY内进行，不会占用CPU的资源，私钥始终保留在KEY里面，也无法取出；而后者则无法自行生成密钥对，只是作为证书的存储设备，但成本相应较低，市场的接受程度相对要高一些。为此，如果用户对安全性的要求较高或者进行电子政务方面的应用，可以选择前者，对于通常的商务应用，则用户可以根据自己的需要进行综合性考虑。目前，常用的USB KEY存储空间的规格主要包括16K、32K、64K等，都可以满足一般的CA应用，但是随着CA应用的增多和复杂，较大容量的USB KEY可能会更能满足要求。

但是最近又传出来一种声音，就是usb 本省并不安全。事实上，无论是政府机关或市企业，都越来越小心这种安装通用串行总线(USB)。英国国防部更担心这类既轻巧又精密的高科技装置，能够直接插入计算机的USB端口存取资料，不必密码便可以进入系统，窃取机密。<Phoenixtv.com>随着USB KEY的容量不断扩大，这种危险将会显现。企业在选择这种认证方式的会重点考虑这个问题。

SSL VPN Basics

By combining SSL-enabled Web brow- sers with a secure gateway to terminate connections and provide policy enforcement and access control, so-called SSL VPNs provide access to Web-based, legacy client/server, and terminal applications from anywhere-home PCs, hotel business centers, Internet cafes, or a business partner’s LAN-without an IPSec VPN client. It’s one of those ideas that make you say "Why didn’t I think of that?"

The companies that did think of it are now working very hard to turn that idea into market share. Regardless of which brand wins the biggest piece of the pie graph, here’s why the idea is a good one:

First and foremost, SSL is everywhere there’s a Web browser. The result is millions and millions of preinstalled clients ready for use. This introduces remote access to a broader user population than is typically feasible with IPSec VPNs.

"Smaller companies don’t have the resources to support IPSec clients," says Jason Matlof, vice president of marketing and business development at Neoteris, maker of an SSL remote access appliance. "Larger companies have the budgets to support 10 or 20 percent of elite users with IPSec."

"The real catalyst in this market is addressing constituencies that haven’t been addressable," he says. "Eighty to 90 percent of users and business partners can get controlled access to certain resources without compromising security."

Second, SSL isn’t a brand new technology that must win over skeptics. Its public key encryption system has been poked and prodded by security experts. Banks, governments, and major retailers entrust billions of dollars in transactions to it. Invented by Netscape, SSL has graduated into an IETF standard under the moniker of Transport Layer Security (TLS). Thus, the move to remote access is merely a new application of a well-established technology, not a new technology seeking a useful application.

Third, SSL remote access enjoys the supreme advantage that all new products have: the ability to attack an incumbent’s weaknesses. In this case, the incumbent is the IPSec VPN, and SSL marketing literature invariably aims its spear at IPSec’s jugular-the client.

CLIENTS? WE DON’T NEED NO STINKING CLIENTS

The IPSec VPN client has three strikes against it. First, the client restricts users to a single machine, which isn’t as flexible as browser-based remote access. "You can go from mobile phone to a Wi-Fi connection to your corporate broadband connection very easily with SSL," says Jude O’Reilley, senior product marketing manager at Aventail, an SSL remote access vendor.

"With IPSec, each one of those networks requires work from the IT staff," says O’Reilley. "Every new network causes pain for IPSec managers."

Second, the IPSec client software can be difficult to manage. "IPSec clients modify the network drivers and the network stack, and if you don’t have tight control over the OS on those machines, it’s going to get complex," says David Thompson, senior research analyst for technology research services at the META Group (www.metagroup.com). "IPSec works well on company laptops, but for home machines there are conflicts and support calls, and that’s universal for all the IPSec vendors."

Thompson says those conflicts and support calls mean added costs for IPSec remote access. "The main cost difference between SSL and IPSec is the support of the client software required for IPSec connections," he says.

Peter Ridgley, principal network engineer for information management solutions provider Iron Mountain (www.ironmountain.com), supports both an SSL remote access solution from Neoteris and an IPSec VPN. He says the Neoteris product has been easier to manage.

"Neoteris doesn’t need much babysitting, just occasional code upgrades and compliance reviews. We use Nortel Contivity for IPSec remote access and it’s stable, but it requires more maintenance." That maintenance includes help desk costs, software upgrades, and new user adds, he notes.

The third strike is end-user complexity. "SSL is fabulous from a corporate standpoint because you don’t have to teach people a new procedure," says Yankee Group (www.yankeegroup.com) analyst Eric Ogren. "Everybody knows how to use a browser."

DOWNSIDES OF THE BROWSER

An irony of SSL VPNs is that their greatest asset-browser-based access-is also their most problematic feature. The freedom and mobility of the browser means that your users can run applications and access network resources from just about anywhere-a partner site, an airport kiosk, an Internet cafe, even a friend’s house.

While that freedom may boost productivity, it also exposes your network to an unlimited number of computers whose security state is unknown (and in some cases unknowable). Your network may experience increased risk from viruses, Trojans, and other malicious code, such as keystroke loggers.

Browser-based access has other complications as well. Default user authentication is limited to a username and password, which is notoriously insecure. In addition, most SSL solutions also require an ActiveX or Java download to provide the most complete access, but remote machines may not allow those applets to run, thus denying access. Finally, browsers may cache documents or screens at the remote machine, potentially exposing sensitive information. Users who forget to log out of browser sessions also present the same risk.

Savvy vendors are addressing these issues, but their methods complicate the original simplicity of the solution. These complications don’t invalidate SSL remote access-even with extras such as tokens or digital certificates, SSL may still be easier and less costly than IPSec VPNs. (For a comparison of SSL and IPSec, see the table.) However, it’s important to know that nothing is as simple as marketing literature would have you believe. Thus, we’ve detailed the top four concerns regarding SSL here:

1. Users will access corporate resourc-es from untrusted (and untrustworthy) computers. IT administrators know it’s difficult enough securing the PCs under their control. Machines outside their control should be treated with suspicion. In August 2003, for example, The New York Times reported a story about a man who had installed keystroke logging software on Internet terminals at Kinko’s copy stores around New York City. According to the report, the man harvested personal information on 450 people who had used the kiosks. The crime was only uncovered when one of the victims actually saw his computer being controlled by a remote user.

   IPSec VPNs don’t suffer from this level of exposure because it’s common practice to install anti-virus signatures, personal firewalls, and policy enforcement programs from companies such as Zone Labs, Sygate, and InfoExpress along with the client. Not so for SSL remote access.

   "It’s a bit of a nightmare from a security perspective," says META’s Thompson. "SSL vendors are struggling with authorization with different endpoints. You may trust the user but not the computer, and it’s hard to figure that out if you don’t have a client."

   Several SSL vendors, such as Aventail, Neoteris, and Netilla, support personal firewalls. This is a good step, but there’s no guarantee that users will be coming from a machine that has a firewall or anti-virus software installed. In such cases, many vendors will limit application access.

   "We can detect a personal firewall and make a policy decision based on that," says Aventail’s O’Reilley. Aventail also plans to roll out a security feature it calls Desktop Watermarking, in which a specific machine, such as an employee’s home PC with anti-virus software and a personal firewall, is identified and registered by the SSL remote access server.

   "A watermark is a combination of factors," says O’Reilley. "It will combine an encrypted cookie with an MD5 checksum done on a section of the hard drive that’s unlikely to change, and maybe a digital certificate."

   The idea is that watermarked PCs will be given deeper access to network resources than other machines. "We’ll provide control to let an IT person say if a user comes from a corporate laptop, he gets everything," says O’Reilley. "When he’s accessing from an airport kiosk, he gets an internal home page. You can tailor access based on the environment and what you’ve done to protect that environment."

   Other vendors are also devising methods for restricting access based on the condition of the remote machine. Many support digital certificates that identify a trusted computer; others will scan the computer. For instance, Nokia’s Secure Access System, an SSL remote access appliance, employs a client integrity scan. This scan checks the user’s device for anti-virus software, a personal firewall, and open ports that may indicate the presence of a Trojan. Once the appliance establishes a trust level, it adjusts access privileges accordingly.

2. Strong user authentication requires add-ons. If you’re investigating SSL remote access as a low-cost alternative to IPSec VPNs, be aware that while the sticker price for such a solution may be agreeable, add-ons are going to up your costs.

   A case in point is user authentication. The default method is via a username and password, but while this might be adequate for remote e-mail, experts say it’s not enough for other resources.

   "If you offer SSL access into deep-end applications, a higher form of authentication is called for," says Yankee’s Ogren. "A token is the obvious first choice, and a biometric is the obvious last choice," he notes.

   SSL vendors also agree that in many cases, usernames and passwords aren’t sufficient. "Most of our customers require some form of two-factor authentication," says Reggie Best, president and CEO of Netilla. "Generally it’s tokens, but some are using smart-card solutions."

   These solutions will add to both your equipment and support costs, and should be considered carefully. Dual-factor authentication also puts more of a burden on end users, who have to be trained to use the token or the smart card and then remember to keep it with them (along with any additional devices, such as a USB-connectable card reader).

   While other SSL vendors support dual-factor authentication, Rainbow Technologies (www.rainbow.com) goes a step further by offering authentication hardware as part of its remote access package. Rainbow’s NetSwift iGate appliance, which provides SSL-based access to Web and client/server applications, also includes 100 USB keys and management software in its starting price.

3. Remote machines may block applets required for sophisticated SSL remote access. While it’s true that browser-based remote access is "clientless" in the sense that the browser (the de facto client) is preinstalled, many SSL VPNs rely on downloadable applets to provide access to sophisticated applications.

   For instance, Neoteris, Aventail, and Netilla, among others, offer a form of SSL "tunneling" that mimics an IPSec VPN and lets users run "fat client" applications such as ACT and Microsoft Outlook. However, the tunneling feature requires an applet, usually ActiveX, to be downloaded to the remote machine.

   The catch is that many of the systems employed for remote access (such as airport kiosks) may not allow those applets to install, thus locking out the user.

   Craig Lockwood, CIO and corporate client manager at Fujitsu, uses Aventail’s SSL VPN service for 4,000 employees. He says his users have experienced just this problem with SSL remote access, particularly when Fujitsu consultants go to customer sites.

   "Very few clients allow us to download the tunneling applet," he says. "It shuts you out of access to file servers." However, he does note that client customers haven’t had a problem with Fujitsu consultants using SSL remote access for e-mail and Oracle applications. "Most do allow you to come in through the browser where there’s nothing installed," he says.

   Vendors admit that the tunneling feature begins to move away from SSL’s main benefit of anywhere access from any machine.

   "This is for a corporate-supplied PC," says Netilla’s Best. "Most organizations wouldn’t allow tunneling from a kiosk."

4. Sensitive information may remain on the remote machine. When it comes to SSL, the caching function employed by browsers to improve performance can also become a potential breach of security or confidentiality, especially if users are working with sensitive applications and documents at publicly accessible terminals. A simple click of the "back" arrow may reveal information-e-mails, application screen shots, and so on-that corporations would rather keep to themselves.

   "That’s a very real issue," says Aventail’s O’Reilley. "The dark side of Web-based access is you never know where that user is. There could be inadvertent disclosure of information."

   Both Aventail and Neoteris address this issue through an administrator-defined option to render content in a non-cacheable format, in effect turning off the caching function at the endpoint. "We also block auto-completion, such as asking a user to save a password on the machine," says O’Reilley.

   Neoteris and Whale Communications (www.whalecommunications.com) go even further. Their platforms include file scrubbers, which are executable applets that are downloaded to a remote machine to wipe out temporary files stored by the browser.

   Again, however, this function is at the mercy of the remote machine. "If the end-user machine has a lock on executable code, this scrubber won’t work," says Neoteris’s Matlof. "Every vendor has this problem." However, he notes that the platform can be configured to kill a user’s session if the executable isn’t allowed to run.

   Netilla also plans to offer a solution to cached files, but as of press time, the company couldn’t provide significant details.

   Forgetful users may also expose information by not logging off at the end of a work session, leaving a live connection into your application for the next person who comes along.

   Vendors such as Neoteris and SafeWeb (www.safewebinc.com) have addressed this issue by allowing administrators to time out idle sessions. Whale also lets administrators force users to periodically reauthenticate, ensuring that the person at the remote machine is a legitimate user.

   LEADERS: TODAY AND TOMORROW

   As of August 2003, 17 vendors were offering some form of SSL remote access. That’s a ridiculous number for a new market that has yet to generate significant revenues. A report from market analyst In-Stat (www.instat.com) pegs the entire SSL remote access market at just $21 million for 2002.

   And yet, both little-known start-ups and brand-name vendors are aiming for a slice of that revenue pie. That’s because the SSL VPN market is demonstrating startling growth. According to In-Stat, SafeWeb shipped 13 units in the first half of 2002, but nearly quadrupled that figure in the second half of the year, shipping 51 units. Neoteris boasts even more impressive figures: 270 units shipped in the second half of 2002, compared to 73 for the first half.

   With so many vendors competing for your business, how do you choose? Conventional wisdom dictates picking a name you’ve heard of. In this case, however, that’s no guarantee of a good choice. That’s because despite the presence of some heavyweight players, the current SSL VPN market leaders are young guns Neoteris and Aventail.

   Each company offers strong access capabilities for a full range of applications, including Web-enabled, client/server, and terminal applications. Aventail was the first to market the concept of SSL VPNs in 1996, which it offered as a managed service. Aventail now also sells standalone SSL appliances, and the company expects the majority of its revenue to come from the appliances rather than the service offering.

   Neoteris has made strong headway with its own SSL appliance, the Instant Virtual Extranet (IVE). Neoteris’s strong points include an excellent range of application access, good remote user security, and ease of use. "In half an hour, we were up and running with Neoteris," says Iron Mountain’s Ridgley. He purchased an IVE for day extenders and telecommuters.

   Two other start-ups, Netilla and SafeWeb, are hot on the heels of the leaders. Both companies offer SSL VPN appliances with a full range of application access and important features for endpoint security. However, they’ll have to work hard to distinguish themselves from the top guns, whether through innovation, partnerships, or pricing.

   SafeWeb is working hard in this direction. In 2002, it joined NetScreen Technologies’s Global Security Alliance, which means NetScreen will recommend the SafeWeb product to customers looking for an SSL VPN solution. SafeWeb also touts its use of regular expressions in its management console, which allows for very granular access control.

   Then there are incumbents Nortel Networks and Check Point. Surprisingly, analysts aren’t bullish on their offerings. "Nortel and Check Point have announced product, but it’s weak," says META’s Thompson. He cites a lack of advanced access features, particularly for non-Web-enabled applications, as the main drawback. But as the market heats up, you can expect more competitive offerings from these players.

   Other established vendors have also moved into the market. In June 2003, Nokia launched the Secure Access System SSL VPN. The product’s range of application access isn’t quite as deep as the current market leaders, but the appliance has a strong focus on access control and remote device security. Nokia also combines high brand awareness with a global sales channel that the start-ups can only envy.

   F5 Networks (www.f5.com), best known for its load balancing solutions, entered the running with its acquisition of uRoam, a start-up that produces the FirePass appliance. Though an established company with a good reputation, F5 isn’t known as a security player. "They say it’s an evolution of their focus on security," says Thompson. Now the job is to convince customers.

   Last but not least is Cisco Systems. The 900-pound gorilla of the networking and security industry plans to offer SSL remote access on its Catalyst 3000, allowing administrators to provision and manage both browser-based and IPSec remote access from one platform.

   "Our role is to be technology-agnostic," says Pete Davis, product line manager for VPNs at Cisco. "SSL grows the market for remote access. Companies that never looked at remote access are looking into it."

   As of press time, Cisco declined to share significant details, but the company expects to make a product announcement in early October 2003. Even without details, the effect of Cisco entering the market is sure to be felt in at least one area, warns Thompson. "It will be difficult to get late-round funding after Cisco makes its move," he says.

   Other vendors of note include Whale and OpenReach. As noted, Whale’s product, the e-Gap Remote Access Appliance, includes very strong features for endpoint security. Whale’s appliance architecture also features the unique "air gap." The product consists of an external Internet-facing server and an internal LAN-facing server. These servers are bridged by a solid-state switch that can only connect to one server at a time, making it impossible for a remote attacker to access the internal server.

   OpenReach is a VPN service provider. Primarily known for IPSec and Multiprotocol Label Switching (MPLS) VPNs, the company now offers SSL remote access as well. It’s a sensible move that should satisfy present customers who want increased access options, but it remains to be seen how much market share the company will gain in a tightly contested market.

   Just how tightly contested the market is was first made known this summer 2003, when a company called Aspelle became the first casualty of the SSL VPN market. Aspelle, which offered a software-based product that featured strong integration with Microsoft, gave every impression of being a strong competitor. However, the company closed its doors in late August after it was unable to secure new funding. Analysts expect that the market will be further whittled by closures and acquisitions.

   SSL AND IPSEC: PEACEFUL COEXISTENCE?

   However the SSL VPN market shapes out, don’t expect it to obliterate IPSec remote access.

   "There’s a core area where IPSec makes sense: the dedicated telecommuter, the road warrior," says META’s Thompson. "Most large organizations aren’t going to displace IPSec anytime soon. If you’ve got the client out there, you’ve done the hard work."

   Others agree. "IPSec VPN is the connectivity method of choice for high-value desktops where you want to authenticate the machine as well as the person," says Yankee’s Ogren. "These smaller numbers are a little more manageable."

   SSL VPNs are generally expected to be deployed to users who can benefit from remote access, but wouldn’t necessarily have been issued an IPSec VPN. "If you have a highly mobile workforce without laptops, SSL makes sense," says Thompson. "If people need to traverse a firewall, SSL makes sense."

   The upshot is that SSL and IPSec are going to coexist, and it will be up to network professionals to manage the tradeoffs.

   Andrew Conry-Murray, contributing editor, can be reached at aconrymurray@yahoo.com.

Reviews: SSL VPNs

But most of these companies still rely on IP security or Point-to-Point Tunneling VPNs to ensure secure access to internal resources. Sure, these protocols keep out prying eyes, but these setups have some inherent problems: Typically, VPNs struggle with NAT (network address translation) traversal, access control for traffic in the tunnel and client management.

As an alternative, you should consider Secure Sockets Layer VPNs. SSL VPNs eliminate nearly all the problems associated with IPsec and PPTP VPNs. The term SSL VPN is a bit of a misnomer, however. A VPN typically establishes the remote client as a node on the protected network; an SSL VPN extends secure access to protected resources for remote users.

Other pluses: Users connect to the network over the Web; with the browser as the client, everything the user needs is readily available. And SSL over Port 443 is allowed nearly everywhere, so there is little chance your remote users won’t be able to access corporate resources.

However, like everything else in life, you get what you pay for. According to our estimates, the average per-user price of an SSL VPN is more than the $40 to $75 per user you’d pay for a traditional VPN setup. But for those companies with slightly deeper pockets, the increase in mobility and the decrease in support and maintenance costs make these products worth considering.

We invited 14 vendors to participate in our tests of SSL VPNs: Array Networks, Aspelle, Aventail Corp., Citrix Systems, F5 Networks, Neoteris, Netilla Networks, Nokia, Novell, Nortel Networks, PortWise, Rainbow Technologies, SafeWeb and Whale Communications. However, Novell declined, saying the test crossed too many products lines (this has never been a problem before). Aspelle never confirmed its participation, and Citrix said it couldn’t spare hardware. F5 begged off, saying it had just completed the acquisition of URoam and was between product launches. Netilla also claimed to be between product revisions, and Rainbow just wasn’t a fit for our tests. Still, we ended up with an excellent list of contenders.

We awarded Neoteris Access Series 5000 our Editor’s Choice because it provides a full-featured product with a wealth of configuration options, good authentication and access-control features, and sound application support. Note that NetScreen Technologies has just announced plans to acquire Neoteris. It will be interesting to see how the product develops under NetScreen’s stewardship.

An SSL VPN Setup
We wanted to test products that provide secure access to Web and non-Web applications over SSL. In addition, the product had to support 500 concurrent users with varying access and application needs, and support up-to-date browsers, specifically Netscape Navigator and Internet Explorer.

Because many of the applications your remote users need to access are not Web-enabled, client support on remote desktops can be dicey, and networking problems often pop up. Among the applications that are not Web-enabled are those using common mail protocols, including SMTP, POP3 and MAPI, and remote shell programs, such as telnet and VNC, which also are unencrypted. With a typical VPN, you can deny external access to those applications or use some encryption technology to protect the traffic passing over untrusted networks.

With non-Web applications, you need a client program, or have to download and execute an ActiveX control or Java applet on the remote user’s computer that redirects network traffic from its intended destination to the SSL VPN gateway. The client application is a local proxy server that accepts connections on a local host address on the remote user’s computer and proxies the traffic over the SSL VPN through the SSL VPN gateway to the destination server. ActiveX or Java applet support is required, along with the permissions in the browser to run them. Java support typically requires a minimum version of JRE. For company-owned computers, that’s not a problem, but access from a public kiosk is likely to be spotty at best.

Features List click to enlarge

The next hurdle is getting the remote user application to talk to the local host proxy. You don’t want users to have to reconfigure the destination servers in applications. The most common method for setting up the application to talk to the proxy listener is to use DNS to resolve host names to the local host proxy address. There are two ways to do that. You can let the SSL VPN client application modify the local hosts file dynamically so that host names resolve to a local host address. This works fine, but the user needs to have administrative privileges to write to that file.

The other gotcha is that if the proxy listener or computer crashes, the local host file may not be restored, and this can bring about host name resolution problems. Only the products from SafeWeb and Whale restored the host file to its original condition when we powered the computer off and then on again.

The second method, which is preferable to modifying the host file, is to use existing DNS servers to resolve host names to local host addresses. This requires a split DNS configuration where an external DNS server contains records for the external host and an internal DNS server contains records for the internal hosts.

We expected the products to support our existing Active Directory and RSA ACE/Server for authentication, and there were few surprises. Authentication against AD was accomplished through Microsoft’s NTLM (NT LanMan) or via LDAP. Authentication against ACE/Server using SecureID tokens was through a native ACE client or RADIUS. Surprisingly, only Whale Communications e-Gap Remote Access was able to pull user group membership when authenticating against our domain using NTLM. Every other product used LDAP against AD. We also were surprised to discover that Array Networks’ Array SP supports only RADIUS authentication to gather groups. This meant we had to modify the RADIUS configuration and use clear-text PAP (Password Authentication Protocol). This is a bad strategy: PAP authentication is vulnerable to brute-force attacks if the attacker can sniff the RADIUS authentication process. The only decent option when using RADIUS is to restrict use to one-time passwords.

Once the user achieves a secure connection, he or she should be bound by access restrictions. All the products provided basic functionality using authentication and group memberships. But access control is about granularity, and only the Nokia Secure Access System provided granular access controls. Its access controls could be based on predefined variables, such as source or destination IP address, URL, user name or group membership, time of day, and other items relating to the session. In addition, through a client-integrity scan, which searches for files and processes on the user system, the system sets variables based on local configuration. For example, if a user doesn’t have a virus scanner, he or she may not be allowed to upload files to a file server. That’s the kind of granular access control you want to enforce on remote users so that you can protect internal resources. However, there is a balance between access controls and complexity. Building ACLs (access-control lists) is hard, and it is easy to mistakenly deny access–or even worse, allow it.

The User Experience

The portal pages provided by the products we tested offer more than predefined links. The products from Neoteris, Nokia and Nortel have a wealth of configurable options so you can customize the portals. You may want to give a group of users access only to some internal links while another group is allowed to create its own links to internal resources. Customization is key. You should be able to manage all the portal options from the administrative console; this is the case for the portals from Neoteris, Nokia and Nortel.

However, because data is cached on the local computer, it may not be cleared when the user session ends or when the browser closes. You don’t want internal data cached on a public system or an unprotected laptop. And not all applications have the "HTTP no cache" directives properly defined. At the very least, you should enable no-cache options on the SSL VPN gateway. Application wipers, which in the products we tested were ActiveX controls, provide cleanup options that can remove data and cookies from a remote system. But they offer limited value if they cannot be configured to remove cached content from specific locations. Whale Communications provides such functionality.

A final item on cache control: Some products–including Whale’s–can be configured to deny access to the remote user if the application wiper cannot be installed. Either the browser doesn’t support the plug-in, or the user doesn’t have rights to run the plug-in.

The Neoteris Access Series 5000 runs on the company’s Instant Virtual Extranet (IVE) platform. The IVE is well-designed and offers a wealth of configurable features from network installation to user browser control. Both the administrative console and user browser experience are well-thought-out and highly configurable. Both let administrators customize the protections and features available to end users. The IVE has extensive user and group definitions that go far beyond those offered by the other products we tested. By leveraging back-end systems for authentication and group membership data, the IVE integrates easily with your current setup. The IVE also has easy-to-configure portal and access controls. However, the Neoteris product stumbles a bit in the areas of logging and troubleshooting. Details are plentiful, but the tools are difficult to use. Events weren’t always logged during our tests, and we couldn’t filter events for viewing. Your best bet is to send log files to syslog and learn to use grep and regular expressions. IVE also lacks a robust access-control system like those found in Nokia’s NSAS and Nortel’s Alteon products.

The IVE uses authentication-server objects to define both authentication methods and group membership. Setting up authentication for NTLM and SecureID was a snap. We pointed the IVE to our internal Active Directory server, and we were done. For the ACE/Server used with SecureID, we imported the ACE/Server configuration file. Simple. The next step was to map groups defined on external servers to groups defined on the IVE. We wanted our group members to have the same access to specific resources when they were remote, so we knew what access controls we needed to assign.

Neoteris did something unique with the IVE regarding group mapping. We were able to authenticate users to one server, while pulling group information from another server. As long as all our user names were defined the same way on multiple back ends, we could use our existing group definitions regardless of where users authenticated. For example, our ACE/Server user names matched those names listed in AD. When we authenticated users to the IVE using SecureID against the ACE/Server, we could then pull group membership from AD using the user names.

Next, we had several options when assigning a user to a group. We could base the group assignment on a group match against a directory attribute. Because we were using Active Directory, we used the "memberof" attribute of the user record based on the user name. Next, we assigned a mapping between the group returned from the directory and a local Authorization Group. We entered in the fully qualified distinguished name that would have been returned from the directory and mapped it to one of our internal groups. We could have mapped multiple "memberof" results to a single Authorization Group as well as define multiple mappings with the first match being put into effect.

Alternatively, we could have mapped users to a default group, in our case "Users," in the event the lookup failed. The other option was to map individual users to groups manually, and finally, we could map all users to one group. We chose the latter option during initial testing of the authentication servers, and then later used directory lookups.

Access controls and portal configuration are defined in the Authorization Group tabs. There are a host of options available in the Authorization Group. The authentication servers are selected automatically based on the group mappings, but authorization can be restricted to source IP address or specific browser types (based on the browser-supplied "User-Agent" string). A rudimentary host checker can be used to see if specific registry settings are set or if applications are running.

Each user group can have a different set of applications available, or it can inherit applications and settings from the "Users" group. Unfortunately, the applications have to be defined separately for each group, a task we found cumbersome. A user’s group membership determines which links are available without your having to add links to each page manually. Additionally, we could configure cookie and credential persistence between logins, as well as allow users to enter arbitrary URLs, which point to internal resources and control Java applet network connections.

ACLs are based on a default open or default closed stance. Default open means all connections are allowed except those that are denied. Default closed means all connections are denied except those that are explicitly allowed. We chose the latter because it is a more secure approach. For Web access control, we needed to specify an access-control entry that defined the protocol, HTTP or HTTPS, the host name and the path. Wildcards "*" for any and "?" for one character are available to simplify URI building. Each type of access needs to be explicitly defined. For example, to allow OWA (Outlook Web Access) connections we defined two access-control rules that allowed access to our Exchange server, but only to the /exchange/*, /exchweb/* and /public/* directories. With the access-control entry, we could also have a bookmark or URL link on the portal page, automatically defined on the users page. For OWA, we needed only one link, which pointed to our Exchange server /exchange/* URI. ACLs for Windows and NFS file sharing are similarly defined.

Although there are many access-control functions in the IVE, we would have liked more granularity in the access-control entries, similar to what is offered by Nokia and Aventail. For example, we would have liked to grant access based on group membership and the client’s source IP address, time of day, authentication method or the status of the local machine.

Non-32-bit application control is similar to Web access controls with a few notable exceptions. Terminal sessions via telnet or SSH were launched using a Java terminal applet, which tunneled the traffic over SSL to the IVE. Other applications are passed through a local port redirector, called a Secure Application Manager (SAM), that listens on a local host address and port. Neoteris has both an ActiveX and a Java-based SAM. In order for the application to connect to the SAM, the application must resolve the host name to the local host address. If you are running split DNS, you can have your external DNS resolve host names to the local host address. Otherwise, the host file must be modified on the local computer. Neoteris’ ActiveX SAM, called Windows SAM or W-SAM, is unique because it can capture DNS resolution requests without having to modify the host file. That means local users don’t need to have local administrator rights when using W-SAM. The type of SAM used is selectable by the administrator. It would be nice if you could choose the redirector based on browser type. It’s a small thing, perhaps, but it makes supporting any browser easier.

The IVE portal can be locked down by the administrator so the user can’t do much beyond what is configured or the features can be enabled to give the user more access, provided the resources pass the ACL. For example, users may be allowed to enter arbitrary URL, Windows UNC for file shares or even add tunneled applications as needed, and those changes can be added as bookmarks. The only aspect we didn’t like is that file-sharing windows are opened in the same display pane.

Although the IVE didn’t do everything we wanted, it has many features you won’t find in other products.

Access Series 3.3, Neoteris, (408) 962-8200. www.neoteris.com

Nokia is a relative newcomer in the SSL VPN space, but it’s off to a fast start: The NSAS 1.0 release we tested demonstrated far superior features compared with the older product lines from several other vendors. First, the NSAS is downright simple to configure. While waiting for licenses, we spent a little over an hour configuring the access controls–a task that took us a day or several days with other products. The kicker is that our initial configuration worked as we expected. NSAS has an advanced access-control system that let us tailor the ACLs to our needs. At $54,995, the NSAS is pricey, but judging by the features built into NSAS, and the features Nokia has hinted at for future releases, we’d be willing to wager on this upstart.

NSAS is built on the IPSO 3.7 platform, Nokia’s security-specific IP operating system. IPSO provides robust network-integration features, including support for multiple routing protocols and DNS. NSAS is enabled through Voyager, the IPSO Web interface. Simply enable NSAS and get a license.

Because we wanted to have both users and group membership to come from Active Directory, we used LDAP to authenticate users. Like every other product we tested except for Whale Communications’ e-Gap, NSAS could not pull group membership information when using NTLM authentication, so we switched to LDAP against AD.

With NSAS, we could prioritize authentication methods. For example, we wanted all users to authenticate using Active Directory and only some users to use SecureID. We ordered the authentication servers so that ACE/Server would be tried first, and if that authentication failed, AD would be next. This added just a few seconds to the authentication process. Bear in mind that SecureID is time-sensitive and the passcode changes every 60 seconds. Always put SecureID authentication first so it won’t time out.

Defining access-control rules was a snap. We defined a Web resource by giving it a unique name–OWA for Outlook Web Access, for instance. Next we typed in a description and the text that would show up in the user portal. Finally, we defined the URL and said when to use an internal proxy and whether auditing and debugging logs should be generated. Once set, the access-control page opened, and we set a simple access-control rule: We gave all Domain Users access to the resource by moving the Domain Users group into the allow category. We also could have added the link to the portal automatically. We added the link for the /exchange directory because that is the URL users will point to initially, but the Domain Users were simply given access to two other necessary directories, /exchweb and /public without links on the portal page.

In most cases, simple access-control rules will suffice, but to unlock the power of NSAS, use the advanced access-control rules. With these, we created access-control entries that took user context, such as location and authentication method, into consideration. For example, we wanted to grant external users access to the IIS Admin pages on a Web server only if they used SecureID to authenticate. If the user was internal, then he or she could use a user name-password login.

Using a form-based interface with drop-down menus and clickable operators, we created an access-control entry that said whether a user was coming from an external address and he or she used SecureID to authenticate or if the user was on an internal host and used any authentication method, he or she would be allowed access.

Neoteris’ Access Series and other products can determine if applications are installed or running by using specialized DLLs supplied by the vendor or searching for registry entries. NSAS can be scripted to search for running applications or for files on the local system before letting a user connect to NSAS. Client integrity scans use a scripting language, pnuts, that is run through a Java applet and reports findings to NSAS, then access is granted or denied. The scripts can be configured to run before or after a user authenticates. We didn’t spend much time creating scripts in the course of our testing, but we did modify the existing scripts that searched for files and processes to look for items specific to our environment.

NSAS includes a warning to the effect that the end-user system needs to have a modern browser–such as Netscape 6.2, IE 5.0, or Mozilla 1.0 or better–along with the Java JRE 1.4.1 plug-in. The JRE requirement is unfortunate because even though JRE is supposed to be backward-compatible, we have found it ain’t always so. Be sure to test the JRE with all of your Java-enabled applications before deployment.

Unfortunately, Nokia doesn’t supply an application wiper like the products from Neoteris, Nortel and Whale do. Application wipers aren’t perfect–they don’t always clean up all the cached data–but they do provide additional protection against leaving data behind on the hard drive.

Nokia Secure Access System, Nokia Corp., (877) 997-9199. www.nokia.com/securenetworksolutions

The Alteon SSL Accelerator 410 VPN is at home doing double duty as an accelerator and an SSL VPN device. It offers features similar to those found in the top products we tested–they are just a bit tougher to get at. Like the Array SP, the Alteon 410 can host multiple virtual hosts configured on static IP addresses, TCP ports or both. This capability adds flexibility in a hosted environment and lets you implement graded authentication. The 410’s access-control features are adequate, but not as robust or granular as those found in the products from Neoteris and Nokia. We had to update the software twice during testing to support OWA and Citrix Nfuse.

You can configure the 410 using a CLI or a browser. We started working with the CLI because the documentation is written for it and not for the WebUI. We don’t mind a well-written CLI–sometimes we prefer it–but Alteon’s CLI was difficult to get the hang of. In addition, it lacks input editing, line wrap and other features, and we ran into problems when we added a feature, then deleted it, then added it back again. The product would grouse about dependencies. The only solution was to revert to the last good configuration and re-enter all the commands again–ugh. The WebUI is just an attractive front end to the CLI and suffers from many of the same shortcomings.

Building access controls and portal links are separate tasks; we would have preferred to add a portal link when building access controls (as we could with Neoteris’ and Nokia’s products). User-access controls can be managed via groups. When the 410 authenticates a user from an external user database– such as Windows Domains or RADIUS–the user’s group affiliation, if available, is also captured.

We put all our users in the Active Directory default group of "Domain Users." We also defined a group called "IIS Admin" that contained users allowed to access our IIS server-management pages. We then created the two groups in the 410 and devised different access levels for each.

Once a user authenticates, the 410 presents all the links that are available to that user, according to his or her group memberships. For example, the only access rule for the "IIS Admin" group was to our IIS Admin page, and only those group members had the link. Role-based management greatly streamlines portal management, and Nortel’s solution is enviably simple to implement.

More granular access control is achieved through extended profiles that let you define access based on the client’s source IP address or authentication method. That’s a start, but support for more complex access- control entries, like those supported by Nokia, is better.

The 410’s user portal is superior to those of the other products we tested. User groups can be defined as one of three levels of users, novice through expert. Each portal level comes with a predefined set of features. Novice users, for example, are allowed to view only the resources defined by the administrator. Medium users can browse to arbitrary links and file shares provided they have the proper access control, and advanced users can define arbitrary port forwarding and terminal sessions.

Alteon SSL 410, Nortel Networks, (877) 655-2275 (US), (800) 466-7835 (Canada). www.nortelnetworks.com

Whale Communications e-Gap is an interesting appliance that works differently from its competitors. The e-Gap Remote Access appliance contains two separate Windows 2000 servers, which transmit data via the e-Gap, a SCSI RAM disk. To make e-Gap work, we had to configure both the inside and outside systems. Fortunately, this was easy to do. Once in e-Gap, we defined shuttles, which in Whale-speak means a way to move data between systems. Then we set up the access controls. Because e-Gap is a Windows 2000 server, we added it to our internal domain and received full access to all our users and user groups without having to use LDAP. This is handy. Besides providing access control, Whale also supports HTTP URL filtering using regular expressions and comes with a full set of predefined filters.

Whale claims its e-Gap technology separates the inside of the network from the outside. When a packet hits either interface, e-Gap strips off the TCP headers, adds a cookie to identify a stream and places the TCP payload onto the SCSI RAM disk. Then the other side reads back the data, determines where it is headed and, if authorized, assembles a new TCP packet and sends it along. By itself, e-Gap can protect against network-layer attacks, just like a good proxy can, but a proxy doesn’t do anything above Layer 4 and neither does e-Gap. And therein lies the usefulness of the e-Gap Remote Access product line– robust but easy to configure, SSL-protected remote access.

Like the other products we tested, e-Gap’s access controls can be based on group membership. The authorization tab in the application configuration lets you select which users and groups will have an application icon on their screens. We enabled remote access to our IIS Admin page. We created a user group called "IIS Admin" within Active Directory. When we defined the application in e-Gap, we restricted access to the members of the "IIS Admin" group only. We tested to ensure only those members received the URL and not others.

We wanted to set up graded authentication so only users who authenticated using both a user name-password pair and a SecureID token would have access to a set of applications. However, we didn’t want to pass the SecureID credentials to the end application. Therefore, we had to modify the resource-validation script that is called whenever a user tries to access a resource. The script is written in Visual Basic, which makes it extensible. Under the direction of Whale, we cut and pasted a code snippet into the validation script. Next we had to edit the application parameters in the e-Gap configuration tool, then define an authentication realm (a fancy name for a set of credentials). The assumption is that whenever a server requests credentials, e-Gap checks to see if it has collected them. If it has, it forwards the credentials to the application; otherwise, it prompts the user for the credentials. So we added our Citrix Server and file sharing to the SecureID realm. We successfully tested process.

Support for non-HTTP applications is a bit more difficult. In other products, the process was as simple as defining the TCP/UDP port numbers and a few other parameters. For e-Gap, if an application wasn’t defined, we had to contact support to find out how to edit the XML configuration file. Much of it was straightforward, but it’s still a bit clunky given the rather smooth management features in the rest of the product.

The log files are contained in the log directory and are useless. You need to edit a registry key to turn up logging, then open the text files and process them manually.

e-Gap Remote Access 2.5, Whale Communications, (201) 947-9177. www.whalecommunications.com

Aventail is probably best known for its managed VPN service (see "Add some Fiberlink to your VPN Diet,"). It recently released the EX-1500 appliance for SSL VPN use. The EX-1500 has the makings of a solid product, but the version we tested had some surprising idiosyncrasies. However, Aventail is scheduled to release a new version by the time you read this. Also Aventail’s Connect client (which we didn’t test) offers some useful features. If you’re looking at Aventail’s line, make sure the company has solved some of the deficiencies we found before you sign on the dotted line.

The EX-1500 supports only two types of authentication–RADIUS, which we used for ACE/Server authentication, and ActiveDirectory over LDAP, which can be used for both user name-password sign-on and digital certificates. However, only one authentication method can be used per access type, either Web access or tunneled non-HTTP. We used LDAP to authenticate to our Active Directory. Group membership is pulled from AD using LDAP.

The appliance’s access controls are simple to define, and we liked the many options available to us, including limits by source IP, destination IP, time of day, user name or group membership, and SSL key length. Unique among the products tested, the EX-1500 can disable a rule without having to delete it. This is handy when you’re troubleshooting.

But this product crumbles when it comes to cookies. Cookie caching on the client cannot be controlled, so we could access OWA for one user while logged in to the EX-1500 as a different user. When one user logs out of the EX-1500, all credentials should be destroyed. Granting permissions to multiple resources in a Web server requires that all users have permissions to the common parent directory and assumes access to all subdirectories is allowed, which may not be the case. Dependencies in the management UI have to be deleted manually before a resource is deleted. Finally, any change to the access-control rules causes user connections to be dropped.

EX-1500 6.4.2, Aventail Corp., (877) AVENTAIL, www.aventail.com

SSL VPN 概览

作者：Rich Larsen

提   纲：

随着经济的发展，企业开始以远程接入和企业广域网方案取代过去的Modem池和租赁广域网线路的方式。为了确保远程接入的安全性，各个企业都采用VPN的形式实现。VPN可以实现使用者通过公网安全的远程接入企业的内部网络系统。通常，这种VPN解决方案采用IPsec 站点协议保证安全。IPsec VPN的一个主要特点是必须在每一台机器上安装并配置客户端软件，才能使用VPN。这样某些情况下就会出现问题，比如企业大规模部署VPN，或者非本企业的员工需要临时使用VPN的时候。最近出现了一种基于Secure Sockets Layer (SSL)协议的VPN,他可以安全的替代IPsec VPN。几乎所有的商业浏览器产品都支持SSL协议，它的安全性也得到了证实。本文将介绍SSL协议的发展历史和细节，并对比IPsec VPN和SSL VPN的优缺点。

一、SSL协议在VPN中的应用概况

1. 背景

越来越多的企业和个人使用World-Wide Web从事商业活动。因此一些法令，例如：the Health InsurancePortability and Accountability Act (HIPPA) and the Gramm-Leach-Bliley Act(GLBA)要求企业无论在什么地方都要确保数据传输的安全性。企业必须使用具有如下特征的安全协议：

l         保护敏感数据的私密性

l         确保数据的完整性

l         确认数据传输到正确的接收者

通常企业会选用VPN来通过公网安全的进行数据交换。沿用至今，几乎所有的VPN解决方案都采用的是IPsec协议，RFC2401中规定了这种协议的全部细节。但是IPsec VPN有一个缺陷，它很难用于部署企业远程接入或外部企业网。SSL VPN和它的后继者Transport Layer Security (TLS) VPN作为远程接入VPN的可行方案迅速崛起，替代IPsec VPN。一家知名的IT调查公司—–Infonetics Research，对SSL VPN产品市场进行评估，认为至2005年将达到$87.1亿，占累计财政增长率的143%。本文将介绍SSL协议简史，SSL协议具体的细节（TSL协议类似于SSL协议），以及SSL/TSL作为灵活替代方案解决VPN远程接入问题的可行性。

2. SSL的历史

CommerceNet consortium在90年代首次提出HTTP安全传输协议（S-HTTP），并制定了详细规范，这个安全版本应用于早期的Mosaic浏览器。最初的理念是在连接的两端进行加密和解密。CommerceNet希望顾客使用这个安全协议。90年代初期，Netscape公司发展了SSL协议用以推进浏览器技术的发展。Netscape公司认识到要扩展电子商务的应用，就必须确保公网上各个部分连接的安全性。相对于CommerceNet，Netscape公司比它更成功的原因在于它将SSL协议随浏览器四处免费传播，并且让公众可以下载和了解SSL协议的细节。

Netscape公司选中SSL协议，将它集成到浏览器中，预计向公众收取费用。但是，这种方式只能作为个别案例，不能提供一个统一的解决方案，使那些非HTTP方式的程序也能受益。因此，Netscape公司决定发展一种独立于应用的安全协议。这种新的协议放在现有传输层协议的顶部（例如TCP或OSI结构的第四层协议），给所有的应用提供开放接口。应用程序开发者不必关心SSL的详细执行细节，只需简单的用SSL Calls代替TCP socket calls。Netscape公司还决定将SSL协议的细节公诸于众，以便能够通过安全委员会的详细审查。1994年11月第一次公开发行了SSL协议规格2.0版。由于2.0版被证实有很多的缺陷，。Netscape公司随即在1996年五月发布了SSL 3.0版。SSL 3.0版是应用最为广泛的版本，也是TLS 1.0版的雏形，RFC 2226列出了TLS 1.0的细节。SSL和TLS非常相似，但是TLS要求特殊的加密算法支持。因此，TLS 1.0和SSL 3.0是不兼容的。然而TLS提供了一种方式可以让服务器屏蔽TLS 1.0，从而支持使用SSL 3.0的客户端。

SSL成为保护网络商业安全的首选协议，几乎所有的主流浏览器都支持它，它还有助于网络安全委员会进行安全审查。Schneier and Wagner对SSL 3.0进行了深入的分析，得出以下结论：提供优秀的防护能力，阻止窃听和被动攻击，还能在相当程度上防御特殊目的的主动攻击。”

3. SSL 协议内容

根据协议规范，SSL的主要目的是确保数据在不安全的公网各个部分传输时的私密性和可靠性。SSL通过以下方式实现：

l         连接的私密性

l         连接双方的可验证性

l         连接的完整性

SSL利用公用密匙对需要共享的私用密匙进行加密，以确保私用密匙在交换过程中的安全性，私用密匙才是真正用来完成数据传输加密、解密的工具。私匙密码算法（也称为对称密码算法）是指发送者和接收者使用同样的密匙对数据进行加密、解密（见图一）。这是一种最原始、最古老的密码算法。这种密匙采用二进制字节（0和1）组合成为明文信息，再以约定的方式生成密码信息。这样密码信息就可以在公网上安全传输了。算法安全性随着密码长度的增加而增加。典型的对称算法密码长度是56位、128位或168位。通过数学运算把数据和密匙组合成为密码算法。密匙算法包括Data Encryption Standard (DES),RC4, Triple DES (3-DES), and Advanced Encryption Standard (AES)。私匙密码算法的基本前提条件除了对称性加密算法以外，还有“diffusion and confusion”的交替使用。confusion确保明文和密文的所有关系最小化。这样即使得到密文的副本，也没有可行的方法根据密文副本确定明文。diffusion有助于进一步消除密文中用来表示明文的比特的统计规律。

图一：私匙密码算法图示

    使用对称性密码算法最主要的障碍是使用双方都必须拥有同样的密匙才能交换加密信息。在数据传输中给所有的使用者分配密匙有点像典型的“catch-22”中的情节。因为密匙分配时涉及的传输范围很广，任何一个了解密匙算法的攻击者都可以破解在VPN使用者两端进行交换的连续信息。此外，攻击者还可以化装成VPN的使用者之一发送伪造的信息。因此，需要一种安全的方式给每一个VPN使用者分配密匙。在一些组织中，例如军队：军队有使用者的详细名单，密匙可以通过out-of-band的方式分配，比如一个可以信任的送信员将它放在戴在手腕上的扁平手链里传送。然而在e-commerce领域里，系统分配密匙的时候，需要进行数据交换的使用者是谁都还不能确定，因此priori key分配策略不是完全可行的。

公匙加密算法通常指非对称加密算法，因为它采用既有区别又有联系的一对密匙进行加密和解密（见图二）。每一个使用者必须拥有两个截然不同的密匙分别作为公匙和私匙。公匙和私匙是相互联系的，通常他们都是配对密匙；但是密匙生成之后，是不可能从公匙推算出私匙的。为了加密信息，发送者必须得到接收者的公匙，并且应用同样的公匙加密算法对明文和私匙进行加密形成密文。

图二：公匙密码算法图示

由于公匙的设计初衷是公开使用，它能够邮寄给站长或e-mail给使用者而不必考虑分配过程中的安全性。因为使用者必须拥有私匙才能用相应的公匙对加密的信息进行解密。这种方式假定使用者不会自己泄漏私匙密码。RSA算法是公匙算法的一种，它的名字来源于发明者：Rivest, Shamir and Adelman 。

   公匙加密算法的另一个特征是采用数字签名。发送者可以用自己的私匙在信息上留下数字化的“签名”，接收者利用发送者的公匙校对签名。当发送者是唯一的私匙拥有人时，数字签名可以用于信息验证。举例说明，一个人在电子合同上使用数字签名，并把电子合同传给银行，银行可以核对数字签名。采用对称性算法产生数字签名是不可能的，因为所有的使用者都拥有同样的密匙，无法验证数字签名属于哪一位使用者。

既然公匙加密算法能够解决密匙安全分配的问题，有人会问那我们为什么还要使用私匙加密算法呢？采用公匙加密，信息解密的效率比采用私匙加密的同样的信息解密效率低1000倍。私匙加密技术使用比特控制或合成密码，这个工作在基本的电脑硬件上比如shift registers就可以完成。但是公匙使用的算法比较复杂，因此需要性能更高的硬件，并耗费相当可观的CPU运算周期。此外，公匙密码长度的增加，要求CPU运算性能也相应提高来承担解密工作，而私匙正好相反，私匙密码的长度基本上不影响密码运算的效率。典型的公匙密码长度是512位、1024位或2048位，远远大于私匙密码长度。

结合两者优势的做法是用公匙加密算法分配私匙。换句话说，就是把私匙看作信息，用公匙对其加密。接收者对信息解密后得到私匙，后续的信息传输就可以用这个私匙进行加密了，这样可以提高效率。这种方法的另一种形式是使用者通过安全的公共加密通道交换信息，每个使用者又可以利用通道生成唯一的密匙，生成的密匙可以用来对后续所有的数据传输进行加密。利用通道生成的密匙仅仅用在特定的会话中。如果使用者双方并发通讯，又会产生新的密匙。这就是SSL所采用的技术。以上是关于SSL和TLS的简略回顾。

SSL协议由许多子协议组成，其中两个主要的子协议是握手协议和记录协议。握手协议允许服务器和客户端“在应用协议传输第一个数据字节以前，彼此确认，协商一种加密算法和密码钥匙”。在数据传输期间，记录协议利用握手协议生成的密匙加密和解密后来交换的数据。图3显示了握手协议期间发生的服务器和客户端的数据交换。客户端发送“Hello”信息给服务器端特定的TCP端口（通常443端口用于Secure Http），请求一个新的握手协议。

这个信息包含了密码规格列表（加密协议和密匙长度）还有客户端浏览器支持的压缩协议以及客户端产生的随机数。客户端随机数由32位的UNIX timestamp value加上客户端浏览器生成的28位的pseudo-random number组成。服务器也发送一个Hello信息响应客户端，这个信息包括它根据随机数值（服务器随机数）选择的密码规格和服务器对客户端的认证，密码规格和客户端随机数的格式相同。服务器的认证仅仅包括服务器的身份和经过“certificate authority” (CA)验证的公匙。CA是指对服务器身份进行核实，联系服务器自己的数字“指纹”给予确认。值得注意的是指纹是用两种不同的算法提供的，不是所有的浏览器都支持这些算法。大部分浏览器已经包含了可信任的CA证书列表和相应的大型CA证书机构的公匙，例如：Verisign or Entrust。

    如果CA不能验证客户端，客户端就需要获得CA的证书，并且把证书安装在浏览器中。CA证书可以从Web网站下载，但这样会增加风险，因为其他的使用者也可以将他们自己的证书伪装成CA机构的证书。客户端使用CA公匙单独计算证书中的“指纹”，并将它与接收到的服务器的“指纹”进行比较，来确保证书没有被修改过。服务器还给客户端提供一个会话ID号码。SSL的握手期计算量相当大，客户端和服务器端会交换会话ID号码，这样万一TCP连接中断也能迅速恢复会话。事实上，SSL也提供了一个简单的握手恢复协议，它不像初始的握手协议的计算量那么大。会话ID和密匙存在着被重新复制使用的风险，因此绝大多数浏览器都会定期的重新产生会话ID和密匙。客户端在一次会话期间可能会多次连接服务器，通常客户端每一次新页面的请求都要产生至少一个TCP连接。

客户端确认了服务器的身份后，它可以选择传输自己的证书到服务器上，进行相互验证。这不是SSL必须的步骤，因为很多客户端没有单独的数字证书。但是企业如果想对客户端进行验证，可以生成并分配证书给每一个客户端，并且要求服务器验证客户端。当然在客户端连接前，证书必须先下载并安装到浏览器上，这样就不能用随意一台没有证书的电脑接入内部网络。完成验证后，客户端产生一个二次随机数（Pre-master secret），并用服务器的公匙对信息加密，再把信息传回给服务器。客户端也会用客户端随机数、服务器端随机数和Pre-master secret结合产生master (secret) key。这种密匙用来对数据传输过程进行加密。客户端也用messageauthentication code (MAC)产生二次随机密匙，用来验证随之而来的数据传输。一旦客户端顺利完成任务，它就传送一个“Change Cipher Spec”的信息(another sub-protocol of SSL)给服务器，说明它准备用计算出的密匙加密后续的数据传输。服务器执行和客户端一模一样的运算，并发送一个Server Change_Ciper Spec信息给客户端。这时握手协议结束，服务器和客户端开始用SSL记录协议进行数据交换。

记录协议是SSL真正的工作者。它负责发送和接收加密SSL帧，这些帧来自或发往网络传输层。记录协议从应用层取得数据流，然后把数据流分解成不超过16K字节的块。然后这些块压缩（不压缩）后，用安全会话密匙加密。最后在record layer封装成包，包的内容包括：

l         内容类型—-定义运行数据的程序（如：IMAP、Telnet、FTP）

l         协议版本号码—-通常“3”代表SSL 3.0版

l         包的字节长度

l         有效负载（加密和压缩）

l         Message Authentication Code (MAC)

这幅帧通过网络传输层传送给接收者。在接收端，帧从传输层进入SSL record layer，在此进行解密和解压，根据内容类型域的值，把数据传送给支持它相应的应用程序。接收者还会核对MAC，以确保数据在传输过程中没有被修改。

总而言之，SSL是Internet上应用最为广泛的协议。Netscape Communications首先发展了SSL协议，提供了如下功能：

l         数据私密性—-使用对称密匙算法协议，这个协议基于定期重新生成的secret “session” key

l         端点验证—-SSL要求客户端验证服务器的身份，也提供可选的客户端、服务器相互验证

l         信息完整性—-SSL检验确保数据在客户端和服务器之间传输时没有被修改

SSL独立于应用，因此任何一个应用程序都可以享受它的安全性而不必理会执行细节。SSL置身于网络结构体系的传输层和应用层之间。此外SSL本身就被几乎所有的Web浏览器支持。这意味着客户端不需要为了支持SSL连接安装额外的软件。这两个特征是下面要讨论的SSL能用于VPN(virtual private networking)的关键点。

、SSL在VPN远程接入中的应用

时至今日，SSL一直在基于HTTP协议的Internet浏览器中使用，以确保数据安全传输。大多数人可能都使用过SSL，它最明显的标志就是浏览器窗口下端的锁状图标。由于SSL的位置介于应用层和传输层之间，它是一种理想的保护应用层安全的协议，就像HTTP、FTP、E-MAIL等协议一样。因此，它迅速成为企业部署VPN时的更好的选择。

今天，员工在机场和咖啡厅远程接入企业内部网已经不是什么新鲜事了。随着西门子AG的发展，几乎3.3亿的员工被称为“mobile”(意思是他们有至少一半的时间在远程工作)，到2005年，估计“mobile”人数会发展至5亿。企业以VPN的方式把内部企业网的应用扩展至每一个“mobile”，以满足他们的需求。这些VPN的特点是采用IPsec协议保护连接的安全性。IPsec是一种安全站点协议，它提供数据的私密性、终端可校验性、不可重复性。SSL也具有这些优点。IPsec和SSL不同之处在于工作原理，IPsec是在使用者之间建立一个安全的网络层“隧道”，所有的通信都在这个“隧道”中进行。举个例子，一个企业有远程站点或办公室。企业选择通过公网发送内部站点信息，而不是在站点间租用私人wan线路。企业把安全网关硬件放置在内部网和公网的连接处（一般放在企业防火墙的外部）。企业的远程机构和本地都有LANs。所有远程机构的使用者通过服务器端程序建立连接，这个程序用于连接本地LAN。公司也有mobile员工，他们要求远程接入内部网。

      为了创建VPN，安全网关必须建立一个IPsec隧道。隧道建立的细节前面已经介绍过了，这种站点间的安全会话通常是用握手协议实现的。安全会话要定义所需参数（比如对称密匙等）。这些参数储存在会话的“database”中，由每个网关负责维护。多站点对主站点的连接是可以实现的，每一个站点都和主站点建立类似上述的安全会话。建立会话连接后，Ipsce也像SSL一样用诸如DES、3DES或AES等算法对数据进行加密、解密。从这点来说，两个不同的站点就像同一个站点一样。工作在分支机构的员工不会察觉到他发送信息要经过公网、或其公网堵塞时使用的其他传输路线。她可以获得所有有权限查看的数据。这些优点使得IPsec VPN解决方案十分吸引人，尤其是那些拥有多各个分支机构又希望公司所有的应用都能集中实现的企业。

远程员工使用的情况和上面讲的分支机构类似。不同的是，他们大多会用客户端软件来代替硬件设备，这些软件都是公司的IT部门预先在他们的电脑上安装的。这些软件和硬件设备的功能相同，也执行握手、建立安全会话和创建IPsec隧道的过程。但是这种情况是将一台单独的电脑连入企业内部网。客户端软件的参数必须配置的和内部网的安全网关一样。此外，客户端软件还要配置远程使用者身份校验证明的功能。这个功能一般用用户名/密码、发布给客户端的数字证书或安全ID来实现。

当然，这一切实现的前提是IT部门能连入mobile使用者的电脑，安装、配置客户端软件，或者使用者自己利用IT部门提供的工具完成这些工作。但并不是所有的情况都是这样的，比如使用者完全处于远程，或者使用者偶尔用自己的电脑或家里的电脑接入。此外，使用者可能是合作伙伴公司的员工，因为某个特殊的项目需要临时接入企业的内部网。企业当然不希望给这样的使用者提供固定的长久连接。不幸的是大多数商业IPsec VPN解决方案都不提供这种临时连接（粒状连接）的管理功能。

      如前所述，IPsec VPN给远程机构或个人使用者提供到内部网络的虚拟连接。这种连接一旦建立，远程节点就变成企业内网的一个节点，它的接入权限就和员工真正身处总部使用时一样。使用者通过VPN验证后接入内部网，如果你是“candy” （外部脆弱、内部坚固）安全模式，就是使用者安全防护能力差，而内部网防御能力强，这时企业内部网抵御攻击的能力也会随之下降。除非企业给每一位远程使用者配备经过配置的笔记本电脑，否则很难确定使用者的电脑是否有防护措施，杀毒软件是否已经升级。此外，使用者可能让家人、朋友使用自己的电脑，随意连接一些internet站点。这就带来了潜在的安全隐患。一旦存在安全隐患的电脑通过IPsec隧道连入企业内部网，病毒就会悄悄的感染内部网中的其他电脑。

    针对IPsec VPN的这些缺点，厂商开始评估替代方案。SSL迅速崛起，代替IPsec实现VPN远程连接，主要有两个原因：一是可资证明的安全性，二是几乎所有的商业浏览器都集成了SSL。

这些优点促使SSL VPN成为VPN市场增长最快的亮点。John Girard是Gartner Group研究部门的负责人，他预言“到2004年，60%的企业用户将会使用瘦客户端VPN(SSL VPN)，而不是胖客户端VPN(IPsec VPN)”。这仅仅是指远程接入类型的VPN，主要是提供给mobile使用者，而不是远程站点。IPsec VPN在站点通信方面有着不可置疑的优势，它仍占有自己的市场份额。

SSL VPN 不能完全替代IPsec VPN，它是VPN在远程接入方面的有益补充。最好的证明就是SSL VPN的生产厂商同时也会提供IPsec VPN设备。下一节我们将从以下几个标准来比较IPsec VPN和SSL VPN：

l         客户端软件需求

l         安全性（例如：密码算法和身份校验）

l         应用程序支持性

l         工作效率

1. 客户端软件需求

    SSL VPN 优于IPsec VPN的其中一点就是不需要安装、管理和支持个人电脑上的客户端软件。通常企业都会选择软件、硬件相结合的方案。除非IT组织控制了所有的硬件，才可能统一硬件的规格标准。IPsec VPN需要安装并配置好客户端软件才能建立连接。但是不同的IPsec VPN生产厂商的客户端软件并不都能和其他厂商生产的硬件兼容。对于外部使用者来说就存在一个问题，他使用的硬件可能是其他厂商制造的。而且生产厂商提供的VPN客户端软件也不能支持所有的操作系统。更重要的是，IPsec VPN在处理地址转换Network Address Translation (NAT)

方面存在问题。使用者在具有NAT功能的防火墙后请求连接会有困难，因为不是所有的NAT路由器都支持IPsec，或者需要改变VPN的参数设置才能连接。这就增加了IT技术支持人员的负担，他必须解决每一个使用者的具体故障。反过来看，几乎所有的主流商业浏览器都集成了SSL，不需要再安装额外的软件。绝大多数SSL VPN的生产厂商都通过“signed plugins”提供其他的功能，“signed plugins”可以跟随浏览器自动传输给客户端。

2. 安全性

   SSL和IPsec都支持同样的密码算法标准：40/128-bit RC4, 56-bit DES, 168-bit Triple-DES。除此之外，IPsec还支持AES，SSL不支持AES，但TLS支持。IPsec的优点之一就是它的每一个连接都由安全会话控制着。使用IPsec VPN，只要使客户端软件和网关的参数设置一样，就可以很容易的在连接中采用特殊的密码算法。而使用SSL VPN时，需要更改参数设置的是浏览器，但不是所有的浏览器都支持所有的密码算法。此外，浏览器会把密码算法的强度降低到服务器和客户端都能接受的最低平衡点。例如：某些浏览器可能会采用40-bit RC4算法，尽管它不是很安全。当然，管理员可以在网关设置具体的最小安全级别，但是这样增加了一些客户端不能连接的风险，这可能是由于客户端浏览器配置比较特殊，或者是因为浏览器的版本不符。

     至于身份验证，SSL VPN和IPsev VPN都把双向验证作为规格标准的一部分。由于IPsec的客户端软件安装在电脑硬件上，它会继承硬件的一些验证性能。IPsec客户端还能预先设置成只接受某一特定服务器证书或者是只接受企业规定的用户名/密码。SSL VPN不采用这种方式，当服务器发来新的证书，它会提示用户，由用户自己选择接受或拒绝这个证书。大多数没有经过专业训练的用户通常会选择接受证书，他们认为这样可以使他们更快的获得需要的信息。这样做的结果是造成“man-in-the-middle”攻击。虽然服务器证书可以预先安装到浏览器上，但是这样做就抵消了SSL不需要安装、配置客户端的优点。

SSL还有一个潜在的安全隐患来自于使用者，因为会话结束后他们一般不会及时关闭浏览器。如果连接请求来自于共享的公众场所，这样做是极其危险的。如果浏览器没有及时关闭，前一个使用者建立的信任连接状态就会一直保持，后来的使用者可以继续利用这台电脑的信任状态接入公司内部网。针对这种情况，很多厂商生产的浏览器都提供了“inactivity timeouts”功能，但这不是全面解决方案，因为电脑仍然在一段时间内存在安全弱点。此时，如果连接请求来自不可控制的公众场所，电脑则处于危险状态，因为攻击者可以利用电脑上的键盘纪录来重复使用者的会话。

3. 应用程序支持性

IPsec VPN运行在网络层，它可以支持所有运行在IP-based network之上的程序。如前所述，IPsec VPN就像企业内部网的延伸，所有在公司内部网能够运行的程序也能通过IPsec隧道原模原样的运行。这对那些需要运行多种类型的客户端程序的企业来说，IPsec VPN是一种无缝方案。

SSL是源于浏览器应用程序发展而来的。它支持很多典型的网络应用程序，例如：email、文件传输、聊天室。但是许多服务器-客户端程序则需要重新编写才能在SSL中使用。很多厂商都提供了一些常用程序的应用代理。即就是客户端Web浏览器与代理网关通信，代理网关将应用翻译后交给终端服务器。但是这样会降低执行效率，而且也不是所有的程序都可以通过这种方式运行。如果企业使用大量的服务器-客户端程序，SSL VPN将变得不实用了。

4. 工作效率

IPsec VPN远程使用者的数量增加后一般需要升级。很多IPsec VPN的单个硬件网关可以同时建立5000个隧道。而且大多数厂商都由提供一些升级用的标准组件，以便远程用户数量增加时可以升级硬件。当使用者人数增加时，IPsec VPN的可维护性下降，IT部门不得不花费更多的时间来配置和维护客户端软件。因此，IPsec VPN实际上可维护性不太好。SSL协议由于使用公匙密码算法，运算强度要比IPsec VPN大，SSL VPN的性能也会随着会话数量的增加而下降，但下降幅度比IPsec VPN要小。很多厂商都提供单独的SSL加速方案，这样SSL可以把一些运算交给其他的硬件完成，这些硬件已经针对SSL运算作了优化。当然，这样做会增加成本，当使用者人数增加时需要权衡成本。既然IPsec和SSL都要对数据进行加密和解密，工作效率自然低于没有安全措施的程序的运行效率。程序对数据延迟非常敏感，在一些程序比如声音或媒体流程序中，是不适合出现数据延迟的。此外SSL是会话导向程序，就是说安全参数是在会话开始时商定的，与一次会话中单个连接的次数无关。因此一些不考虑会话因素的程序，例如基于局域网的客户机-服务器程序，使用SSL可能会出现执行效率方面的问题，这些程序需要经常不断的重新确定安全参数，而这个过程正是SSL运算量最大的过程。

下表对SSL和IPsec进行了对比：

总结：

用户希望在任何地方都能连接他们需要的数据和应用程序。企业为了节约成本取消了集中拨号的modem池和私人wan线路，取而代之的是更多的使用公网进行远程连接。企业还部署了extranets，供合作伙伴远程连接。为了确保这些连接的安全性，企业采用了VPN技术。传统的VPN技术都采用的是IPsec协议，建立安全隧道，连接远程站点、远程用户和企业内部网。IPsec的安全性和信任度已经得到证实，但是它需要在每一个客户端设备上安装、配置客户端软件，导致大规模的远程接入管理困难。mobile用户必须携带已经安装、配置好的笔记本电脑才能接入内部网。这就增加了IT部门的管理难度和成本负担。

SSL也是得到证实的网络安全协议。Netscape Corp.发展了SSL协议，将之用于HTTPS协议中来保护web浏览器会话的安全性。SSL和IPsec一样，都提供服务器和客户端数据的私密性、完整性和可验证性。但SSL和IPsec不同的是它被集成到几乎所有的商业浏览器中，因此不需要安装额外的客户端软件。此外，一些web、email和文件传送协议的安全版本规格都直接采用了SSL。近来，厂商开始用SSL VPN代替IPsec VPN，以减轻客户端软件的管理工作量。许多应用程序开始升级或重新编写成“web-enabled”，以便他们能够很好的采用SSL。Gartner Group预言到2004年末，绝大多数远程用户会选择SSL VPN。因为SSL VPN在降低企业管理成本和提高工作效率方面优于IPsec VPN。但IPsec VPN作为intersite VPN解决方案还是占据重要地位，而SSL VPN的设计初衷不是用于此方面的。SSL VPN在应用程序的支持性方面也有缺点，一些原有的服务器-客户端程序不能在SSL接入中使用。

      IPsec和SSL可以看作是互补的方案，可以使企业给mobile员工和合作伙伴提供安全、标准和随时随地的远程内部网连接。两种方案在不同的应用方向上各有优缺点。每个方案都应该针对个别的应用目的和应用环境单独评估。IPsec和SSL将会继续共存，满足企业不同的远程接入要求。

昨天有朋友提问，C/S结构的应用怎么建立SSL加密通道的问题，今天这个问题就是我们的话题。

现在的用户的应用的大的趋势是转向b/s（web-based）这个一点也没有错，但是很多客户以前已经花了很大的资金建设的C/S的应用还没有被淘汰，还在继续发挥着他们的作用。

那ssl vpn 怎么建立通道呢，纵观所有的SSL VPN厂家，除了不支持的C/S结构的，大家的共同的解决方案是：在客户端安装一个代理软件。这个代理软件就是实际意义上的客户端，只是这种做法也分成几种：

1、直接安装永久的一个软件，有配置界面，有后台的代理模块，这样把本地的所有客户端应用的数据包打包成SSL 数据，和中心网络中的SSL VPN网管建立SSL 通道穿数据；

2、简化配置，采用JAVA APPLATE程序每一次通过浏览器建通道的时候自动下载到本地了来，做ssl 代理程序，把相关的客户端的数据包打包到ssl通道中去，这样做的好处是简化配置，客户感觉不到客户端程序的存在，但是缺点是有一些应用程序肯能不支持；

3、采用acetiveX程序，也是随着浏览器登陆建通道的时候下载到本地来，优缺点同第二点；

如果是针对C/S结构应用的客户来讲SSL VPN的优势不在于有没有客户端和客户端的配置是否方便等等。现在的很多IPSEC vpn也在大力的简化客户端的配置方法，但是ipsec vpn是一个全联通的连接方案，这一点在相关的比较稳当中能够看到。

ipsec vpn适用于低成本的全联通的连接解决方案，比如两个分公司之间，也就是site to site 的解决方案，而ssl vpn 的解决方案最适合移动办公人员对总部资源的访问，合作伙伴，客户对本公司的相应的资源的访问。

在c/s的方案中采用ssl vpn的还有一个好处就是对访问权限的控制，而不是IPSEC的全连通，全连通的的最大坏处就是当一个外部的电脑通过IPSEC连入了总部网络，那么这台电脑就已经成了整个这个网络中一部分，但是这台电脑并没有受整个网络的安全政策的控制，比如这台电脑感染了病毒，它就成了整个网络的突破口，而感染全部的网络，不受边界上的病毒防火墙的控制，如果这台电脑找到黑客攻击，那么这台电脑就可以成为黑客攻击整个网络的跳板。这台电脑就成了整个安全的最低的那块木板。

简单来说，SSL和IPSEC两个都是加密的通讯协议 (encryption protocol) ， 从任何TCP网络来保护IP-based的数据流(data stream)。我认为，可以从任何技术上的角度来探讨哪一个协议较强或较弱， 但是如果以应用(application)的角度来比较哪一个较好就比较不科学和不实际了。当要选择用哪一个VPN时，公司所选择的通讯协议并没有对与错，因为这两种通讯协议都有它们自己独特的特色和好处。

回顾过去，IPSEC VPN原是最早的作用是用来作为保护通过因特网在私有网络之间的数据通讯(data communication)。之后，此技术延伸到保护行动使用者(mobile user)进入公司的内部网络的通讯。而这几年，由于机动性(mobility)已成为趋势，保护行动使用者的存取使的IPSEC VPN使用正逐渐增加，而这增加的趋势已造成一个公司的负担并提高成本。如果使用端要透过VPN连接到一个私有的网络，那使用端必须先安装一个客户端的VPN软件。而此软件的维护就是造成公司负担的原因。这对用来支持行动使用者的营运成本(operation cost)有直接的影响。 随着广域网络的激增，telecommuting的使用者也因此连接不安全的家中网络到公司的网络。不久以后，委外的采购商和商业合作方法被采用后， 不可信任的网络将会快速的连接到公司的私有网络上。IPSEC VPN是一个非常具有full-spectrum存取的安全解决方案，也曾经是一个对办公室内部安全连结上非常有效的通讯协议。但是，在一段时间后，它发展成为所有远程访问one–size-fits-all的解决方案。因此，如我们所知，今天IPSEC VPN已变成一个公司在安全防护上的弱点，并不是因此协议是薄弱的，而是因为它的使用方式。

SSL是专门设计来保护HTTP通讯协议。当浏览器和web server双方皆已设定好来支持SSL时，如果透过这个通讯协议所传输的数据流加密，SSL将提供一个安全的“封套(wrapper)”来保护浏览器和web server中的IP封包。在IPSEC和SSL通讯协议的设计上有一些原理上的不同。第一，IPSEC是以网络层(network-layer)为中心，而SSL是以应用层(application-layer)为中心。第二，IPSEC需要专门的使用端软件，而SSL使用任何SSL支持的浏览器为使用端。最后，SSL原本是以机动性为中心而IPSEC不是。举个洽当的例子，SSH通讯协议虽然是一个以应用层为中心的加密解决方案，有潜力发展为一个新的SSH VPN，可是它并没有。SSL的成功因素是机动性(mobility)。

在这几年，因为通讯协议的原理，SSL VPN已衍生成为一个比较适合保护application-based的存取解决方案。在使用中，您可以容易的发现SSL VPN可以迅速的解决IPSEC VPN的相关弱点。以应用程序为中心的方法允许细化的控制使用者的存取权，因此，建立一个策略性的end-user存取。这种无使用端的想法，虽然浏览器被视作真正的使用端，可提高使用者的方便度并且减少公司在维修上所会碰到的负担和成本，SSL VPN的end-user在存取时会受到授权的限制，有别于IPSEC VPN，user大部分会被授权除非有限制。最后，将限制存取(restrictive access)和无使用端软件(clientless)的方便功能加起来，SSL VPN可以有效的保护所有使用者和网络之间的数据流，而IPSEC VPN仍然也可以在网络之间保护数据流。因此，以目前而言，将 SSL VPN视为增强的解决方案而不是和IPSEC VPN竞争的解决方案是较洽当的。

以目前的速度，SSL VPN正在快速的冲刺。对IPSEC VPN所有的信赖问题是自然的，却是无意义的。IPSEC VPN是一个被认同的解决方案而且会永远持续下去，除非我们目前所知的计算机世界彻底的改变。许多公司应该问的是：「这两个技术如何能同时生存？」，而不是「哪一个比较好？」

基础上，IPSEC VPN是设计来保护私有的数据流从各种不被信任的网络传送到信任的网络。SSL VPN的由来是保护在相关资源的数据流，这些来源不管是user或是网络都可能是不可信任的。这是两个方案中最重要的概念，必须了解这概念才能正确有效的使用这两个VPN的解决方案。曾经，对于可信任和不可信任的资源是可以清楚的分别。可信任的资源是内部的网络及员工。而今天，这种区别是非常难的。以network-to-network的连接来说 您合伙人的网络可以信任吗？国外或国内委外采购商的网络可以信任吗？分享和数据缓存器(DR)的设备可以信任吗？Telecommuting员工家中的网络可以信任吗？针对user-to-network连接，顾问或委外代理商是可信任的user吗？您合伙人的员工可以信任吗？以组织层更深入些来说，与公司有不愉快的员工可信任吗？Telecommuting员工可以信任吗？如果信任代表存取权(access privilege)，那普通的使用者和技术人员是否应该有同等到IT设施中的存取权？一个资历较浅的IT人员是否可以和高阶IT人员或主管有同等到管理系统的存取权吗？重点是，内部网络应该是唯一一个可以信任的设施，并且受到IPSEC VPN的最高保护。在那之中，SSL VPN可提供细化的存取控制，如所有的使用者无论是在办公室里或外和其它不属于公司本身的网络，必须要有明确的许可来进入内部网络中的资源。技术上来说，IPSEC VPN透过因特网保护内部网络之间network-to-network的数据流，而 SSL VPN保护来自分类的使用者、企业外部网(extranet) 及因特网(internet)的资料流。

趋势走向

如SSL VPN帮助公司统一及保护所有使用者的远程访问，下一个必然的趋势会走向一个可以利用的并且可以有效地结合各种不同的存取方法，使所有的ingress point可以集中管理，在SSL VPN设备之中，和防火墙及IPSEC VPN管理外部的解决方案。要完成这个目标表示公司可以建立一个可实施的并且以策略为基础的存取权给所有的end-user，而这些end user可以分成：透过计算机终端与公司联系的在家工作者(telecommuter)、长途在外奔波的工作者(road warriors/traveling employee)、合作伙伴、供货商……等等。内部的安全保护可以有显著的增强且方便审核。

SSL VPN建设的需求是因为考量数据的处理性、盗窃、或是未经允许的行动工作者这些情形下所产生。而这些是IPSEC VPN所无法有效发挥的。可是，因为最近全球的骚动，如：911、SARS和2003年美国东岸的大停电，导致对机动性(mobility)的兴趣有急遽上升的趋势。跟平常不一样的是，机动性不仅适用于end-user也适用于IT设施。SSL VPN虽然还很新，但已经改变了IT的情况。除了只提供inbound存取，如远程使用者存取公司网络的计算机和应用程序，SSL VPN还必须满足outbound存取的需求，如为避免远程IT设施未来发生的任何天灾人祸。因此，一个无所不包的SSL VPN解决方案必须可以同时支持end-user存取和远程的IT管理；此外，SSL VPN也必须支持技术人员所需的进阶远程访问方法，如所有out-of-band和电源控制的能力。实质上，我们所需要的是一个有力的SSL VPN解决方案，提供end-user简单和安全的远程访问，及提供IT人员在任何时间、地点存取和管理远程、多样化IT设施的能力。