Connectivity is more important than ever. Most members of a mobile workforce must be able to access critical files, print services, company intranet applications and even their workstation desktops outside of normal business hours. Whether a user connects to a branch, main or home office, access is the key issue. To maintain secure access remotely, many organizations are turning to or have already implemented virtual private networks (VPNs). The VPN allows a remote user to connect over the internet to the remote office in a secure manner.
The VPN connection uses encrypted tunnels to protect the confidentiality of the information, as well as making the connection appear to the user as if they are on the corporate local area network (LAN). Originally, remote access used IPsec (internet protocol security)-based VPNs to maintain remote access to the office. However, more networks are blocking the ports associated with IPsec-based VPNs. For instance, many hotels, internet service providers and corporate LAN administrators are blocking UDP (user datagram protocol) port 500 to stop connectivity to IPsec-based VPNs.
In some cases, this is done for security. For example, a corporate LAN may choose to block the IPsec connection because the connection is encrypted and cannot be processed for malicious content, such as surfing to an inappropriate site or emailing company information to a competitor. Many ISPs block the IPsec-based VPN in order to charge a higher rate for a business class account, which allows the traffic for IPsec-based VPNs to pass through the filter.
IPsec is a standard written to specify running on top of internet protocol (IP) networks. The standard implements security features that the IP never was designed to have. Since the IP protocol was originally designed for interoperability and redundancy without a thought for security, IP is not a secure protocol. IPsec uses components — such as authentication headers, encrypted payloads and message authentication codes — as a way to provide pseudo non-repudiation. It provides confidentiality and integrity, but the message authentication code only authenticates the group of users of a connection and not an individual using the connection.
IPsec-based VPNs work just fine as long as the port for internet key exchange (IKE) is open. Since this port is getting blocked more and more, organizations are turning to SSL-based VPNs as a replacement for the older IPsec-based VPNs. This is because SSL (secure sockets layer) is a standard protocol used by regular web surfers, so it is difficult to block SSL access without blocking internet connectivity. Because the port cannot be blocked from a practical perspective, SSL-based VPNs are more likely to be allowed through whatever type of network the remote user may be on.
SSL differs from IPsec
Let’s examine the steps of establishing an SSL connection. Like IPsec, SSL is a negotiated protocol, which means that both parties have to agree on how the protocol will be used in order for the communication to take place. However, SSL uses hybrid cryptography, which means it uses both public key cryptography and private key cryptography as part of the communication process. SSL begins when the client (usually a web browser) sends a client hello message to the SSL server. This message contains a list of cipher specifications. This is a list of all the cryptographic algorithms the browser will support. Once the SSL server receives this message, the server picks one of the ciphers and returns the specification to the client in a server hello message. When this is completed, the server then sends over the server certificate for the client to inspect. The client performs several checks against the certificate, such as comparing the signing certificate authority against the list of trusted authorities configured in the browser.
Once the certificate is checked, the browser extracts the public key from the certificate, generates the private or session key, encrypts the session key with the server’s public key, and then sends the session key over to the server. At this point, all communication changes from public key cryptography to private or secret key cryptography.
We tested the SSL VPNs by installing them into our test network and using a Windows XP client to connect to the SSL-based VPN. We attempted to use the SSL portal, as well as the layer three SSL VPN clients to access the internal network.
Mike Stephenson contributed to this Group Test.
Errata: In the Application Vulnerability Assessment Group Test review in the August issue, on page 50, Application Security’s product review should state: AppDetectivePro is part of the DbProtect suite of products, which also provides activity monitoring, patch management and database encryption. Our apologies for