A step towards wider SSL implementation

Two great stumbling blocks on the path leading to a Web-wide implementation of the SSL/TLS protocols have always been cost and speed.

So far, the great majority of websites has chosen to take a gamble and hope that they won’t be the ones that will regret not implementing it for the time being. But, as part of our lives move online and we increasingly shop, play, converse, bank and do many other things via the Internet, the time will soon come when major sites will be forced to do it regardless of cost.

When the HTTP session hijacking Firefox extension Firesheep was first presented back in October, it created quite a stir. This wasn’t the first tool that allowed attackers to hijack sessions, but it was the first that was designed in such a way that even the less technically savvy users were able to use it.

Its developers said that their primary goal is to bring people’s attention to the “elephant in the room” that is the lack of SSL implementation on major sites, and they succeeded. It didn’t bring about an immediate reaction, but it is safe to say that many websites started contemplating the option.

Luckily for them, researchers have not been sitting with their hands in their laps. ComputerWorld reports about a group of them that tackled the SSL speed problem and came up with a promising answer – a GPU-accelerated SSL proxy dubbed SSLShader.

SSLShading uses a specific algorithm to redirect SSL traffic either to the CPU or the graphics processing unit (GPU) and which makes that decision based on its assessment of which component is in the position of executing the job faster at that particular moment. “SSLShader offloads cryptographic operations to GPU only when it can benefit from parallel execution, and otherwise use the CPU to minimize latency,” write the researchers.

They tested the developed proxy on off-the-shelf hardware – an Intel Xeon X5550 CPU with four cores and an NVIDIA GTX 480 graphic card with 480 cores – and practically sextupled the number of transactions per second.

The solution has its shortcomings. “For small transactions under 1MB, SSLShader outperforms lighttpd with or without AES-NI support. For large files SSLShader throughput is lower than that of lighttpd due to data copy overhead of proxying,” the researchers note. “The current bottleneck in SSLShader mainly is in the fact that the Linux kernel’s networking stack does not scale well to multiple CPU cores, and that we have data copying overhead due to proxying.”