Firesheep killed HTTP. Long Live HTTPS With Free SSL Acceleration, Courtesy of SPARC/Solaris!

Before we continue our little Performance Analysis Series, let's look at some current news:

The Bad News: HTTP is dead. Get over it. The killer? It's called Firesheep, a free Firefox extension that makes it trivially easy for that kid sitting next to you in that Wifi hotspot to steal your Facebook, Twitter or other web services' identity.

The Victims: The first line of victims are of course millions of unsuspecting users that are sitting in WLAN areas, not knowing that their web identities can be stolen at the click of the button. But the real victims are hundreds, if not thousands of website owners, starting with the who-is-who of web companies, who are now (rightly so) faced with the challenge of upgrading their web infrastructure to HTTPS as soon as possible, preferably overnight.

The Good News: Adding encryption to your web servers used to be an additional burden on the CPU, negatively impacting performance by as much as 2-3x. Fortunately, the new SPARC T3 processors enable you to switch SSL encryption on for your web applications, without any performance impact. This is possible through built-in encryption engines at the core level. And thanks to the Oracle Solaris Cryptographic Framework, it's easy to take advantage of hardware encryption for any application that needs it.

Wanna learn more? Read on!

After reading the news about Firesheep, my first reaction was: "Boy am I glad I fixed that hole back in January for my own blog!"

My second reaction was: "Cool, finally the web can become a safer place!"

Why Firesheep is a Good Thing

At first sight, Firesheep looks like an evil hacker's tool: Hijack innocent people's web identities at the click of a button. But the real effect (and intention) of this tool is much more productive: It wakes up both the public and web-based companies, pointing the finger at the open wound that web security has had for a long time.

Now, companies all over the world (be they web based or not) are faced with the reality that HTTP as a protocol is insecure, especially if you want to transfer sensitive information like session cookies and other identity related stuff.

The Cost of Web Security

Now, if HTTP is so insecure, why didn't companies adopt HTTPS earlier? One reason: Cost. Depending on who you ask (here's a quick, practical SSL overhead observation), SSL overhead can be as much as 60-70%.

In other words: Switching from HTTP to HTTPS cripples your web server performance by a factor of 2-3x (if it spends 70% for overhead, it can only spend 30% for real work, reducing the amount of transactions to about a third).

So, after securing your web service, you'd need to double or triplicate the amount of web servers to make up for the performance loss, or upgrade to 2x-3x faster servers.

No wonder companies have shyed away from adopting HTTPS across the board for so long!

Never be Cheap on Security

But cutting costs at the wrong end never helps. Google's GMail service learned that lesson earlier, after being attached by Chinese hackers.

And now the rest of the world is learning that lesson too. Finally.

It Doesn't Have to be Slow, nor Expensive

But here's the good news: Modern hardware and software that is specifically designed to easily deal with highly parallel, networked and encrypted load can help you secure your web stack easily, without additional costs in performance or server capacity. That's essentially what SPARC T3 processors and servers are all about.

SPARC T3 in a Nutshell

Here's what's inside an Oracle SPARC T3 Processor:

16 cores, each equipped with 2 processor pipelines, each in turn can handle 4 threads in parallel. Yes, that's a total of 128 threads running on a single CPU. Great for those masses of parallel user transactions!
4 DDR3 memory channels to feed the CPU quickly with data.
Embedded PCIe I/O interfaces to quickly connect with the outside world.
Two built-in 10 Gigabit Ethernet connections directly to the CPU. No extra bus bandwidth or latency wasted.
Each of the 16 cores comes with its own crypto-acceleration engine. You heard it right: Not one but 16 crypto-accelerators on a single chip!
And much more.

The beauty of this chip is that it's 100% optimized to serve the network: Data comes in through two 10GBE interfaces directly to the CPU, where it's decrypted and processed in parallel, then reincrypted and sent back to the clients, without having to leave the CPU in the process.

The SPARC T3 is a pure network processing machine.

Accessing Crypto-Power Through Solaris

But pure hardware is worthless without the right software to help you realize its potential. And that's where SPARC/Solaris comes into play.

The Oracle Solaris Cryptographic Framework is the software interface to connect your application to the SPARC T3's ample supply of cryptographic horsepower. In other words: Most of the time, If you're running standard software that's compiled to run on Solaris, the OS will take care of everything and it "just works".

More precisely: If your software is compliant to PKCS#11 and linked to the Solaris libpkcs11.so library, or if your software uses the Solaris supplied OpenSSL libraries from /usr/sfw/lib, then the SPARC T3's crypto acceleration should just work. Similarly, Java applications need only use the SunPKCS11-Solaris provider and they're all set.

More information on how to leverage the Solaris Crypto Framework (with SPARC-T3, any other SSL accelerator supported by Solaris or just software-based) is available here:

Lawrence Spracklen: Using the UltraSPARC Hardware Cryptographic Accelerators
Solaris 10 Documentation on docs.sun.com: Chapter 13 Solaris Cryptographic Framework
Stefan Hinker: Oracle Encryption and the Solaris Cryptographic Framework

SPARC T3 Crypto: The Details

Behind the scenes, a lot of complexity is happening. First, data goes in and out through highly optimized 10 Gigabit Ethernet Interfaces that are sitting right inside the CPU and that help categorize and parallelize network packets for consumption by Solaris' highly optimized networking stack.

Then, the SPARC T3 crypto-accelerators are already in their 3rd generation. The latest enhancements to this technology is described in wonderful detail in Larry Spracklen's Hot Chips slide deck Sun's 3rd generation on-chip UltraSPARC Security Accelerator.

Finally, more details on how to use the Solaris Cryptographic Framework have been compiled by Ben Rockwood in a nice blog post, simply named Solaris Cryptographic Tools.

The Net Result: 200%-300% More Performance!

In the end, the only stuff that counts are results and here they are:

200%-300% Better SSL Performance for Weblogic Applications
Better than 1.9x increase of crypto performance over the preceding T2+ generation (which already had crypto-acceleration in the CPU as well)
Oh, and crypto-acceleration probably didn't hurt during the SPECjvm World Record Benchmark run either :).

Now, it depends on how you look at the numbers,but for all practical purposes, if your web infrastructure is running on SPARC T processors, you can just switch to HTTPS instead of HTTP and you should not experience any performance degradation. SSL for free!

Summary and Conclusion

Firesheep is the latest wake-up call to more safety on the web: All modern web traffic is always worthy of protection, making HTTPS mandatory everywhere, from web sites that care about their integrity, to user information, to cookies, to any type of transaction on the web.
Adding encryption to your web infrastructure used to come at a considerable processing cost. The SPARC T-Series, and in particular the latest SPARC T3 processors, solve this problem by providing crypto-acceleration on the CPU, together with 2x10GBE networking capabilities.
Oracle Solaris helps administrators take advantage of their crypto-accelerated hardware by offering a complete set of crypto-APIs, from PKCS#11 to optimized OpenSSL to a Java cryptographic provider.

Wait, There's Even More!

Incidentally, Jörg has had a similar idea about Firesheep, the need to encrypt everything and SPARC T3. Honestly, we didn't conspire or otherwise talk about it :). It's just that I'm a slower article writer than he is, and when he published his article, I was halfway through mine.

Anyway, if you want another perspective, I recommend you read Jörg Möllenkamp's article entitled: Firesheep and the SSL everywhere route - Solaris and SPARC may be of help.