Saturday, 13 April 2013

The problem with SSL is not performance, its management

In a chat with Michael Hidalgo about SSL, he mentioned the posts Overclocking SSL (from Google), Dispelling the New SSL Myth (from F5) and Still not computationally expensive (Google guy responding to F5).

I have written a couple post on SSL:
And if you read them you will notice that from my point of view, the issue with SSL is not really a performance issue, but a management/workflow one.

Namely the fact that:
  • SSL requires Development and Infrastructure to work together,
  • It adds more complexity to the deployment (note how the Azure team is taking a long time to add support for it)
  • It is still a pain to add SSL support to existing web servers
  • Management of keys is hard
  • It is another source of bugs (for an application).
  • There are a lot of people (and organizations) that really don’t want SSL-everywhere to happen
That said, I agree that the time for SSL-Everywhere has come, and we really need to do a better job at protecting our browsing data

1 comment:

Danger Moose said...

Full disclosure, I work for F5.

That said, performance isn't the problem with SSL Everywhere. Sure, increasing key lengths and stronger ciphers in the name of better security will require more horsepower to support web-scale applications. However, CPU horsepower, even for crypto, is very cheap.

Managing SSL certificate renewal, key-length, version, and cipher enforcement at web scale *is* hard. Automation, orchestration, and virtualization all serve to make certificate management and some of the other aforementioned SSL management complexities more approachable or even trivial.

The real challenge, in my view, is building applications that work via both HTTP and HTTPS. Supporting naked HTTP and the SSL-wrapped version adds another point for regression testing, and another piece of logic to be managed by the application or the underlying server platform. Since application server platforms vary widely in their default handling of HTTP via SSL, it makes sense to treat SSL encryption of web applications as a commodity function to be handled elsewhere. Here is where a centralized point of control to terminate SSL can really help web application developers move onto more complex challenges and use their time more effectively.

Certainly, the cost of such a head-end solution that terminates SSL is a factor. However, there is also a cost to the extra time spent building & testing application code and/or configuring application server platforms and/or management and orchestration suites.