The Play by Play of SSL for VPNs

Security is important, and SSL VPNs can provide that security. We also know that SSL is used for most online transactions that require security. Before we jump in to the VPN portion, it is also important to understand the basics of how SSL works. If a customer was opening up a browser and going to connect to a banking server, or some other type of SSL device, here is what we would expect:

The client initiates a connection to the server using the destination IP address of the server and the destination TCP port 443. The source IP address is the IP address of the client, and the source port is some random unused port number on the client machine greater than 1023.

There is the standard three-way handshake, which is the normal process for TCP in establishing sessions.

After the client initiates its request for the connection, the server responds, providing its digital certificate, which contains the server’s public key.

The client, upon receiving this digital certificate, has a big decision to make. That decision is whether to believe the credibility of the digital certificate that it just received from the SSL VPN server. This is where PKI comes into play. If the digital certificate is signed by a certificate authority (CA) that the client’s browser trusts, and the validity dates for that certificate cause the client to believe that the time has not run out on that certificate, and if the client is checking a certificate revocation list (CRL) (and the serial number for the certificate is not on the CRL), the client can trust the certificate and extract the public key of the server out of the certificate.

The client then generates a shared secret that it would like to use for encryption back and forth between itself and the server. The problem is now how to get this shared secret that the client wants to use sent securely over to the server? The answer is the client uses the public key of the server to encrypt the shared secret and send the encrypted secret to the server.

The server decrypts the sent symmetric key using the server’s own private key, and now both devices in the session know and can use the shared secret key.

The key is then used to encrypt the SSL session.

Because SSL VPN provides network access to remote users, you have to consider the placement of the VPN termination devices. Before implementing the SSL VPN feature, ask the following questions:

Should the Cisco ASA terminating the VPN be placed behind another firewall? If so, what ports should be opened in that firewall?

Should the decrypted traffic be passed through another set of firewalls? If so, what ports should be allowed in those firewalls?

Are there any proxy servers between the client and the Cisco ASAs?