Shopping For An SSL Accelerator

Believe it or not, the cost of a 128-bit certificate can be a significant factor in the decision to purchase an external acceleration device as opposed to an internal device when multiple Web servers are involved. Even with discounts, the cost of purchasing one certificate per Web server rises quickly. And the cost is recurring because renewal is required every year. Don't forget to factor in the expense of managing each certificate and each set of keys. For large sites, the cost of the certificates could quickly grow to more than the cost of the accelerators. On the other hand, an external device can front hundreds of Web servers, enabling them all with SSL for a fraction of the cost.

If you require SSL encryption at all times, including on the wire on your internal network (often the case for financial institutions), you're going to eat the cost of the certificates anyway because you'll need certificates on all servers, and the decision becomes primarily a question of load-balancing needs. If you need the ability to route traffic at Layer 7, you'll want an SSL-enabled external device to handle these chores. A good reason for routing at Layer 7 is service levels based on cookies (gold members are always directed to server A, B or C because they're the "phat" servers; everyone else gets D, E or F). Also, you can organize your Web farm more efficiently (rules like "images are served from server Y unless Y is under heavy load, then it's X" are difficult to code into Web pages). If you don't require load-balancing above Layer 4, you'll be able to get away with a simple load-balancing solution while leveraging your investment in certificates and internal acceleration devices.

The underlying truth here is that even if you deploy an external cryptographic acceleration device, you're going to want internal acceleration. Without it, the encryption bottleneck will continue to be in your SSL-enabled Web servers--you'll gain almost nothing in terms of number and speed of transaction processing. Why? In this scenario, the SSL session is terminated at the load-balancer and a new SSL session is initiated to the Web server. If you aren't accelerating both sides of the equation, you're still introducing high latency because of SSL processing overhead. Some devices, such as those offered by F5 Networks and NetScaler, pool SSL connections to reduce this overhead.

There are two types of external accelerators: those offered by network device manufacturers, such as Array Networks, F5 and NetScaler, and those offered by primarily hardware cryptographic vendors, such as Rainbow and SonicWall. The differences between them are in each device's ability to go beyond accelerating cryptographic functions. Accelerators offered by network device manufacturers generally include more complete network control--load-balancing, cache-redirection--while the network support offered by traditional cryptographic hardware manufacturers tends to focus more on the cryptography and offers limited, if any, additional network-based options. Your selection will depend entirely on your networking needs. If you require load-balancing and other network functionality, an F5 or NetScaler product will serve you well.

Muddying the picture even more, if you have deployed or are thinking about deploying a network-based IDS (intrusion-detection system), you may want to consider an external device. An IDS can't process SSL-enabled traffic, so you'll need to decrypt the traffic before the IDS receives it. You can always re-encrypt to the back end if necessary, but your IDS won't serve its intended purpose if it's getting encrypted traffic. If you need to re-encrypt traffic, choose a device that supports this function on the back end, such as F5's Big-IP.