In the last newsletter, we examined IPSec, which has become the de facto protocol for providing security on Internet-based VPNs. We pointed out that while it works great for transparently connecting two networks across the Internet, there are some rather significant issues that arise for widespread remote worker access.
Enter the SSL alternative. SSL, in its traditional form, is designed to encrypt browser-based traffic without making any requirements on the network infrastructure. With authentication and encryption options that are essentially equivalent to IPSec, there is little difference in the inherent strength of the security in the two protocols.
Further, since SSL looks like any other browser traffic, it allows access to SSL-enabled applications for secure access from virtually any location - including partner or customer sites (which is problematic with IPSec) and public Internet access locations. And as far as the client side is concerned, most browsers support SSL, so implementation from the client side is quite simple.
The problem with SSL is that, by its very nature, it's designed for Web-based applications. Consequently, in order to use SSL in a corporate environment, the application must be "Webified." Sometimes this means rewriting a homegrown application. Or it might mean buying an additional module from the vendor of your major corporate application.
But perhaps the most significant drawback to SSL from a technical perspective is the fact that it assumes that the traffic will be TCP traffic. SSL was not designed with real-time applications in mind, such as VoIP, which depends on UDP for performance. Consequently, if you are supporting a Web-based application that has a VoIP interface, you could be faced with running both SSL and IPSec for that single application.
Next time, we'll tell you about one company's approach to the IPSec/SSL dilemma.