Slashdot Mirror
Build an Open Source SSL Accelerator
Amin Zelfani writes "SSL accelerators like Big-IP 6900 from F5 Networks typically carry a $50k or more price tag. An article over at o3magazine.com shows you how to build an SSL accelerator that's on par with the commercial solutions, using Open Source projects. SSL Accelerators offload the encryption / decryption process from web servers, reducing load and reducing the number of certificates needed."
The problem with that is that you still have the performance hit of calling the ROT-13 function times four (twice for encryption, twice for decryption).
I'll sell you my ROT-52 accelerator card for $50,000 which will do it all in one function call, and hardware accelerated to boot! Did I mention it supports unicode?
Partly the article is quoting prices on a whole box, not just the SSL acceleration. The Big-IP 6900 mentioned in the summary, for example, is a dual-core rackmount server with 10GigE, and hardware SSL and compression. Presumably much of that money you're paying is going for the actual server, not just the SSL-accelerating coprocessor. Of course, you're probably also paying a markup for buying a specialty server of that sort, rather than slapping an SSL accelerator in a server from a commodity vendor.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
you *do* know that an F5 Big-IP is more than an SSL accelerator? Like, a load balancer with lots of cool features.
I guess you could duplicate the features of an f5 with nginx and more, but I guess it'd take a developer more than 50k worth of time to do it.
----- Documentation is worth it just to be able to answer all your mail with 'RTFM' - Alan Cox.
Actually you forgot to mention that most licensing systems require multiple licenses per 'machine'. One of the advantages of using one of these SSL accelerators, besides offloading the work, is being able to consolidate certs onto one machine for many front-edge machines.
...you'd offload the entire TCP/IP stack (Linux' networking isn't the fastest) as well as the SSL. Preferably get the IPSEC in there as well. It shouldn't be too hard to build a card that does the lot. You could then use VCHAN or some other kernel bypass method to forward the data as though Linux had just processed the packets within its own networking stack. The software doesn't need to know where the operation is taking place, so long as the API is the same.
However, just getting the SSL onto a card is a definite advantage, as SSL is a heavy processor consumer and is used frequently-enough that it's a drag on systems.
There are many encryption chips out there (Freescale's S1, for example) and there are projects on OpenCores that you can download right into a low-cost FPGA, so you can get pretty much whatever speed you want at whatever budget you're prepared to set aside.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
If their solution was really worthwhile, wouldn't the link to the article have been https:/// instead of just http:// ?
The BIGIP does load balancing, active-active clustering, routing, packet manipulation using scripts etc. It's extortionately priced but is very powerful and very user friendly.
I'm sorry if I haven't offended anyone
Y'know who else thinks that it would be nice to see SSL used on all web sites?
Verisign.
Better yet, it'd be nice to see SSL used on all pages on all web sites. One of the first rules of security is that context can tell you a lot about what is being encrypted and can potentially weaken that encryption. It also allows attackers to distinguish packets of interest from context.
Using SSL for only critical stuff is like using encryption for only shell passwords. It's better than nothing, but exposes far far too much.
(One might argue that there's so much valuable data placed on computers in corporate DMZ's that further security is pointless until that is fixed. That's true, but one reason corporations don't bother with security is that customers don't demand it. One reason customers don't demand it is that SSL is slow, so sites that don't have good security give a better response, which is what the customer thinks they want. If the response was fixed, customers might start considering sites with competent security preferable to those that effectively hand out bank details to any cracker that asks.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
you combine nginx, haproxy, varnish-cache and you've got 80% of what Big-IP does!
It doesn't cost 50K to buy a T2 based server from Sun (more like 15K at entry-level prices). This would give you 8 crypto-accelerated cores with 2x 10GBit ports straight into the processor. They are also not that power hungry. You could use this to both accelerate your web server as well as your SSL. Wouldn't this be a better solution than building two servers?
Just thinking out loud, maybe I've overlooked something as I'm not a network engineer or anything.
I think the newer Geodes do, but the older ones have been around for a long while and are still cheap. No idea about Linux - I've no idea why you'd run anything other than OpenBSD on a machine like that.
I am TheRaven on Soylent News
nginx, haproxy, varnish-cache
Ok. Lets say your geek is $65k+stuff a year. It takes your geek 6 months to fully ascend the nginx/haproxy/varnish-cache learning curve and get the stack working properly. A geek making only $65k WILL take that long trying to achieve some semblance of parity with a commercial quality, regression tested appliance. That's around $50k in labor (remember, employers pay hidden costs) + hardware (still not free, that.) Meanwhile, you've lost some number of eyeballs to glitches and poor performance and disappointed whomever wanted it 12 weeks ago.
You could use a better geek, but those cost more and you overrun your $50k budget faster, so that's a wash. Might lose fewer eyeballs that way...
Now you rely on a "one off" mystery that your geek, and only your geek, can possibly manage without learning the hard way WHY he's the only one. On the upside you also have the beginnings of a network appliance you might try to productize... if you can get your geek to document it.
Or you could drop $50k now and put your geek on something that doesn't come in a box.
I know, I know. "SIX MONTHS!!!111 What kind of idiot..." I've been involved with this stuff a long time. It isn't done when the light comes on. It takes lots of effort to go from "oh look, it lit up!" to a finished product. In the end you'll spend every damn minute of that 6 months whether you do it up front or amortize it over half a decade. If you take the long view you realize that there is a reason BigIP has customers.
The problem with wiring the accelerator into the CPU is that, although the CPU can perform the calculation faster, it does not actually free the CPU from having to do the packet processing. In addition to CPU time spent, you also need to consider interrupt overhead, which for high-speed networks (like 10GbE) is pretty significant. A separate TCP offload engine, with hardware encryption support, and access to memory via DMA, can significantly reduce the amount of time a CPU spends processing packets. It just interrupts the CPU when a decrypted TCP payload is ready and waiting in memory. And since your add-in card doesn't need a large instruction set, you can make it very, very fast.