When traditional VPNs were not enough for secure remote access

ssl vpn

With the mobile workforce on the rise there were a couple of stringent needs that put a lot of pressure on the traditional remote access VPNs that relied on IPsec:

  • the need for connectivity.
  • the need for functionality.
  • the need for mobility.
  • the need for security.

Basically these needs determined the appearance of SSL VPNs and shaped their evolution.
The way SSL VPNs made available features to address these issues and combined them resulted today in SSL VPNs being the premier choice for secure remote access.
secure remote access solutions

Connectivity

The remote users connect from anywhere: public wireless hotspots, hotel rooms, coffee shops, guest wireless LANs; they try to use whatever connection is available.

It’s hard to know in advance what outbound protocols will be allowed in such locations; usually TCP ports 80 and 443 should be allowed.

IPsec is the most commonly used network layer security control.
SSL is the most commonly used transport layer security control.
Originally IPsec had issues going through NAT devices. Furthermore it did not provide a feature dealing with network roaming scenarios. These issues were addressed later.

But with all the modifications made to IPsec, VPNs using IPsec cannot connect behind restrictive firewalls or web proxies.

secure remote access solutions

On the other side, SSL has been commonly associated with HTTP. HTTPS traffic uses TCP port 443 as the destination port.

Browsers use the HTTP CONNECT method to tunnel HTTPS through web proxies.
SSL VPNs take advantage of these, even when a full blown SSL VPN client is used.


All these may come at a performance cost; SSL can also use UDP for better performance(DTLS), but then would have the same limitations as IPsec.


Some vendors attempt to try to use with their SSL VPN clients a combination of both TCP and UDP meaning that when possible UDP will be used, otherwise the VPN will fallback to TCP.

Although SSL is a transport layer security control, SSL VPNs can provide network level access. The tunnel mode of SSL VPNs is different from the IPsec one in that the SSL tunnels are usually created using a non-standard tunneling method, while the IPsec tunnels are created with methods described in the IPsec standard or associated standards(for example IPsec’s native tunnel mode or L2TP secured with IPsec).

Functionality

With traditional VPNs functionality is limited from two points if view:
  • administrative points of view; the need to configure and deploy VPN clients for basic connectivity introduces administrative overhead and increases the TCO.
  • users’ point of view; users nowadays tend to use whatever machines they have access to for VPN-in. The need of a VPN client available is a great issue; furthermore the way users find and access the corporate resources once the VPN connection is established influences the ease of use of the VPN solution.
In the Web 2.0 era, many applications have a web interface.
Virtually all the devices are equipped with a SSL capable browser.


secure remote access Web 2.0


Imagine the situation of mapping drives once the VPN connection was established.
Usually some scripts are run to map these drives; name resolutions must be handled properly.

In case of SSL VPNs, from the portal page users can access their shares from a web page that looks like directories.

This is made possible since the VPN gateway does protocol translation.
Similar situation for FTP shares, no need for an additional FTP client or to manually connect to the FTP server.

  • Access to non-web application is provided through SSL tunneling; this is accomplished with port or application forwarding mode(thin client, client-server applications) and full tunnel mode(full client, network level access). SSL VPNs tend to simplify the deployment and management of the full blown SSL VPN clients.
  • There are times when an application client(SSH, Telnet, RDP) is not present on the users’ machines; SSL VPNs deal with this situation by using Java-based application clients(alternatively ActiveX-based clients can be provided) downloaded and loaded by users from the portal.

The SSL VPN gateway can delegate the users’ credentials to the back application; single-sign-on, improved user experience.

While SSL VPNs tend to provide more functionality than traditional VPNs they have their own drawbacks. As they rely heavily on the browser, compatibility issues may appear for various devices.
For example for supporting mobile devices like smart phones a special functionality of the portal may be required to have the portal usable on the small screen of these devices.
Furthermore the newest version of browsers can break some portal features; or lack of Java support can make certain SSL VPN features unavailable.

Mobility

The latest generation of WiFi or 3G/4G enabled mobile devices provides the mobile workforce with almost anywhere Internet connectivity.

Popular smart phones like the iPhone or Android-based phones, iPad or Android tablets are used by remote users to access corporate data.

secure remote access Mobility

The mobile devices share a common thing, they all have a browser.
SSL VPNs use this browser as a VPN client to provide access to web applications; the so called clientless access mode.
If needed, a full blown SSL VPN client is available; this client is easy to install from the app market or store of the respective mobile platform.
Some vendors also offer a thin client for access to client-server applications(non-web based ones).
Mobile devices typically lack support for Java Runtime Environment. This makes certain SSL VPN features like port forwarding or application forwarding unavailable; port forwarding or application forwarding are typically provided using Java applets or ActiveX controls.

Security

Traditional VPNs, since they operate at the network level, are not particularly concerned with applications; they were primarily created to extend the corporate network to include the remote users’ machines allowing all traffic between these machines and the corporate network.
This may still be acceptable for managed machines, sort of; application inspection is still needed at the VPN gateway level.
While SSL can protect traffic like HTTP or FTP, by itself does not provide a secure remote access solution:

  • The servers are exposed to the Internet.
  • There is no central point of authentication, authorization and logging.
  • Security is enforced by the application itself, at the extent available.

SSL VPN gateway

SSL is not particularly concerned about the application; rather the application is made aware of the presence of SSL.
Take for example web applications; login forms can be submitted in clear, cookies not marked as secure by the web applications can be leaked by browsers over an insecure channel.
The SSL VPN gateway:
- through its reverse proxy rewrites the URLs to ensure requests are not made in clear.
- through the portal authenticates users and authorizes access to resources; can delegate to the back application users’ credentials.
- marks the cookies as secure.

SSL VPNs provides secure remote access incorporating:

  • Granular access to resources per user or group of users; by default they tend to allow only what’s needed.
  • Application inspection; threats mitigation, spot on web applications.
  • Endpoint identification and control; deals with managed and unmanaged devices.
  • Strong authentication methods.
  • SSL offloading; lift any SSL implementation issues from the back server’s stack.
SSL VPNs are often referred as providing application layer VPNs.


Conclusion

SSL VPNs use the SSL protocol, which is virtually included in all standard web browsers, to secure the traffic between the remote users and the enterprises as it traverses public networks; the browser acts as a base VPN client.
They provide anywhere secure remote access to corporate resources(either web or non-web applications).