Ssl certificate management

IPsec and SSL: The Nitty-Gritty

Although both IPsec and SSL can provide secure access to network applications, they operate differently. Here are the technological differences between the two protocols. IPsec is typically used in conjunction with IKE (Internet Key Exchange) for key management. Together, IPsec and IKE are described in a series of Internet Engineering Task Force (IETF) standards: RFC 2401 to 2411. IPsec supports multiple encryption algorithms (AES, DES, 3DES, RC4) and multiple integrity mechanisms (MD5, SHA-1), as well as authentication via X.509 certificates.

IPsec works at layer 3 (the network layer) of the OSI network model to encapsulate normal IP packets. Once a VPN tunnel has been established, any application (Web, e-mail, FTP, telnet, even VoIP) can use it without discrimination. This can be a positive for an organization that relies on multiple applications, but it can become a vulnerability if the remote-access client has been compromised.

IPsec is well suited for site-to-site VPNs, because it can be implemented in network devices without any client operating systems or applications having to be modified. But the necessary deployment of software on individual clients' PCs is an ongoing IT responsibility, and this can be costly, depending on how many remote workers have to be supported.

IPsec VPN devices are commonly referred to as concentrators, because just one of them can manage many sessions. Many of them are capable of performing well in a high-volume environment (1-Gbps traffic with support for thousands of concurrent users) and support fail-over without dropping sessions.

IPsec connectivity can be impaired by firewalls, routers, and proxy devices that reside between the client and the concentrator. In addition, if IPsec VPN sessions are not terminated in the DMZ of a properly managed firewall, companies are in effect punching a hole through their network security measures and providing remote access to the network rather than to specific servers or applications.

Most of us are already familiar with SSL, because it is the authentication and encryption mechanism for e-commerce. SSL was originally developed by Netscape; it runs on layer 4 (the transport layer) of the OSI model, above TCP/IP and below HTTP.

When a client establishes an SSL-connection handshake with a server, the following actions occur. First, the server is authenticated to the client, verifying that a server's certificate and public ID are valid and have been issued by a trusted certificate authority. Then the client and server negotiate and select cryptographic algorithms that they both support. The client may then be authenticated to the server, and an encrypted SSL connection can be established.

SSL operates transparently across proxies and routers performing Network Address Translation, and it uses TCP ports that are usually left open on firewalls. One potential drawback is that SSL is computationally heavy for both the client device and the SSL VPN device; unless implemented properly, it may require multiple handshakes per session, thus increasing the computational load. This calls into question the ability of SSL devices to scale to support thousands of concurrent remote users. For more on this, see our online sidebar "Improving SSL Remote-Access Appliance Performance and Scalability".