How to secure an SSL VPN with one-time passcodes and mutual authentication.

SSL-based VPNs were designed to eliminate the need for complex configurations on the user's PC. Unfortunately, that was before the dangers of public WiFi networks and tougher regulatory requirements came into being. Thanks to WiFi, many attacks that were difficult are now quite simple. In particular, a man-in-the-middle attack can intercept SSL-encrypted traffic, rendering SSL-based VPNs useless - even if it's protected by a typical one-time password system. The man-in-the-middle can easily feed the one-time password into the SSL-based VPN within the alloted time.

In order to thwart this attack mutual authentication is required. Mutual authentication means that the user is validated to the site and the site is validated to the user. In this document, we will show how to configure the WiKID Strong Authentication System to provide strong, mutual authentication for an SSL-Explorer. To make life easy, we will be using the VMware versions of both SSL-Explorer and WiKID. We'll show you what to expect when it works and what to expect when it doesn't.

While you might be tempted to use client certificates for SSL-VPN authentication, there a few reasons why WiKID might be better for you. First, you more than likely have non-SSL-VPN remote services. Perhaps you have OpenVPN or SSH that require two-factor authentication. Using WiKID creates one central remote user database. Moreover, because WiKID validates the PIN on the server, it is not susceptible to passive brute-force attacks and therefore is more secure than typical certificates. WiKID is much easier to manage and requires no CRL list management.

We assume that you already have the servers essentially configured with networking etc and are adding two-factor authentication.

Configure the WiKID Server

Adding a domain to the WiKID server

This is fairly easy. From the WiKID server web administration interface, click on the the Domains tab and Create New Domain. Enter a domain name for the gateway and a device name. The device name will show up on the WiKID token. In the Registered URL box put the URL of the SSL VPN server. When the domain is created, the WiKID server will fetch the certificate from the VPN, so make sure that you enter 'https:'. The server code will be the routable, zero-padded IP Address of the WiKID server (e.g. 10.1.1.1 = 010001001001). Set the other parameters as you see fit. While a longer PIN may increase security mathematically, a four digit PIN may be better: if a user uses their ATM PIN, they are more likely to protect it.

Create a network client

After saving the domain information, click on the Network Client tab and Create New Network Client. Enter a name for this client and the IP Address of the SSL-VPN server on the internal network. Select Radius as the protocol and the domain you created above as the domain.

Add a user

If you have a large number of users, or you prefer to let users do their own work, you can configure some simple scripts to allow users to validate themselves on the WiKID server. There are ASP scripts, for example, that you can run on your LAN that will configure users based on their Active Directory credentials. Examples are also provided with the Java, Python, PHP and Ruby network client packages. In this example, we will be manually adding a user.

If you haven't already, you can download a copy of the the open source WiKID PC token client. The Blackberry, Palm, Windows Mobile and J2ME token clients do not support mutual authentication. The first time you launch the token client, you need to create a passphrase. Once started, select Actions and Create New Domain

Enter the 12 digit domain identifier and the public key will be sent to the WiKID server. You will be prompted for a PIN.

The WiKID server will store the PIN and return a registration code.

At this point, the account has been created on the WiKID server, but it is not active. We will manually validate the user on the WiKID server. From the WiKIDAdmin web interface, click on Users and Manually Validate A User. Click on the Registration Code and enter a user name.

Now, from the token client, select the domain you created and enter your PIN. You should get the one-time passcode back (and it should be copied into your clipboard) and your browser should launch to the Registered URL.

Configuring SSL-Explorer

Updating the VMware image

The first thing to do is to make sure that you have updated to the latest VMware version. From the shell, select Upgrade:

We are using the 0.2.14_01 Enterprise Edition of SSL-Explorer.

Adding the WiKID Server via Radius

Starting from the Main screen, click on Security Options

Then click on the Radius tab and enter the domain name of your WiKID server and the shared secret. Those are the only boxes that need changing.

Next we will create an authentication scheme for WiKID. From the main screen, click on the Authentication Scheme link in the left hand pane, then click on Create New Scheme on the right hand side. That will bring up the scheme creation wizard:

Now assign the Radius module to this scheme:

And assign the policy to Everyone. You could also create a new policy and add selective users.

Click Finish on the next screen to save the scheme.

Now, from the main Authentication Scheme page, move the newly created WiKID-Auth-Scheme to the top.

In order to require WiKID two-factor authentication, you will need to turn off the Default and Password and Personal Details Schemes for Everyone. Remember to not turn them off the Administrative Policy until after you have setup the Admin user in WiKID! Click on each of the two policies to be removed and their respective policy tabs and move Everyone from the Selected box to the Available box:

Testing Mutual Authentication

Lauch the WiKID token client and select the SSL-Explorer VPN domain you created and enter your PIN:

In the background, the token client is going to the domain's registerered URL, getting the SSL certificate and hashing it so it can compare it to the downloaded hash. If the hashes match, you will get the one-time passcode back, it will automatically be pasted into the clipboard:

and your default browser will be launched to the registered URL:

However, if the certificates do not match, the user will get an error:

This message tells the user that something is amiss and not to proceed.

Conclusion

SSL VPNs gained popularity as a ubiquitous access method that was more secure than PPTP and far simpler than IPSec VPNs. Unfortunately, they also gained popularity before the weaknesses of Wifi were widely known and before new compliance mandated two-factor authentication for so many companies. There is no need to dump your SSL-based VPNs. You just need to address the increased risk of man-in-the-middle attacks by deploying one-time passwords for session authentication and strong, mutual authentication.

This document was originally published on Howtoforge as How to secure an SSL VPN with one-time passcodes and mutual authentication.