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 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 are 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. WiKID gives you one central remote user database. Moreover, becuase 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 configured with networking, etc. and are ready to add two-factor authentication.