A few days back, Scott Gilbertson of Wired observed that an increasing number of web sites were offering HTTPS as an option, but were not defaulting to them. (HTTPS is more secure, so why isn’t the Web using it?) As he inquired into the why, he connected with Yves Lafon of W3C who made the following assertions:



1.    HTTPS can’t be cached

2.    HTTPS adds a lot of latency

3.    HTTPS costs a lot of money

4.    HTTPS doesn’t work with virtual hosts (mostly)

Now Yves is a smart guy, but I don’t think he’s giving enough credit to the value that Application Delivery Controllers like the NetScaler have brought to HTTPS, especially when we’re behind some of the largest HTTPS implementations in the world. So let’s step through the cited issues:

HTTPS can’t be cached

This is somewhat misleading. What Yves means to say is that HTTPS can’t be cached by forward proxy caches at the network edge, as is typically used at ISPs. This is different than caching at the browser which still very much works. Web sites that manage their caching headers correctly in their web site can still have their CSS, static HTML, JavaScript, and images cached at the browser with SSL.

The question to ask is whether we want some things that merit SSL to be placed in a shared edge cache in the first place. My login response is private to me, no one else should have that and if there is a HTTP cookie in the response, the edge cache (if it is following RFC standard) shouldn’t cache it. If anything, going through the edge cache in those cases can actually slow a connection down.

HTTPS adds a lot of latency

Yves is technically correct – if the web site hasn’t taken the step to optimize SSL correctly. Software-only based SSL implementations are notoriously slow and with the push towards 2048 bit SSL certificates by the issuers like Verisign the performance impact is HUGE. We’ve seen implementations slow down by a factor of 10x compared to 1024 bit SSL certificates.

BUT… tools like the NetScaler have provided hardware accelerated SSL for a decade now to specifically address this. On the high end, the NetScaler dishes up 220,000 SSL transactions/sec compared to a software implementation that may peak in the hundreds. We’ve also optimized the 2048 bit SSL implementation so that it is near the mathematical ideal in terms of the amount of extra work necessary. (The mathematical ideal is 4x the number of math operations for each RSA handshake.)

With these optimizations, SSL termination and decryption on the NetScaler far outpaces what a standard server can do with straight HTTP. Translation: SSL is not an impact to latency if the site administrator chooses for it not to be.

HTTPS Costs a Lot of Money

This is a tricky one. Adding a security capability does cost money. The question is how much does it cost to not do it. When recently working with a company in the manufacturing space, the discussion of their knowledge center came up. The knowledge center was password protected for their customers since each customer had a personalized view that reflecting the products they purchased.

Technically, there was nothing secret about the materials. Every customer had access to the same content. However, the fact that a particular customer had a particular combination of products was a secret… to the customer. That combination of purchases could signal to the customer’s competition what they were planning which would have serious ramifications if shared. For the dollar amounts in question, wiring up Firesheep and hanging out at the local coffee shops around the competition could be money well spent. Corporate espionage doesn’t protect here – on a wireless network, the end user broadcast their data.

Bottom line, the manufacturer needed SSL.

I’ve now had this conversation countless times across countless vertical industries. The answer inevitably ends up being the same. The potential cost of not doing something as cheap as SSL far outweighed the cost of SSL itself.

As part of reducing the cost of SSL, hardware like the NetScaler MPX can be immensely helpful. Since the NetScaler can provide a very high number of SSL operations in a single 1U or 2U chassis, significantly fewer servers are necessary to support the traffic load since connections from the NetScaler to the server are straight HTTP. The cost per SSL transaction can be much cheaper this way than using the server to terminate SSL.

HTTPS Doesn’t Work with Virtual Hosts (mostly)

An RFC was passed some time back that formalized how SSL needed to work in virtual hosted environments. The system uses a two-stage SSL handshake so that the server could get enough information from the client to determine which certificate to use and send it out. Both Apache and IIS support this model  and there are hosting providers out there that will happily sell you HTTPS support for your virtual host.

The NetScaler has supported this feature for a while now so that administrators can also benefit from the scale and reduced cost of SSL while still supporting virtual hosts.

The Bottom Line

There is little good reason to not use SSL on a web site. It’s a cheap element to add, not very complex, and has a stellar return for the effort. Best of all, it single-handedly defeats attacks like those thrown by Firesheep and given the ubiquity of SSL support on the client, everyone is ready to support those kinds of transactions.

SSL… Yeah, it’s that awesome.