Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Build an Open Source SSL Accelerator

Posted by timothy on Wed Apr 15, 2009 03:24 PM
from the macguyver-it-up dept.
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."
+ -
story

Related Stories

[+] F5 Fires Back On Open Source SSL Accelerator 120 comments
Random Feature writes "In response to Build an Open Source SSL Accelerator, in which o3 magazine detailed how to build a solution comparable to an F5 BIG-IP 6900 on the cheap, F5 Fires Back claiming it's not as cheap as it appears and pointing out the potential performance implications of a 'cobbled together set of components designed to mimic similar functionality.' The discussion on the performance of the Open Source solution based on Opteron RSA operation processing capabilities brings into question the validity of the 'more SSL TPS for cheaper' argument presented by o3."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • Huh? (Score:2, Interesting)

    A miniPCI card with an OpenSSL-supported crypto engine that can handle saturate the bus costs around $50. What do you get by spending three orders of magnitude more? Something that can handle multiple, 10GigE connections?
    • Re: (Score:2, Funny)

      You forgot to mention the fancy box with the plush anti-static bag for the card. What, did you think you were just giving the companies those $5,000? It costs a lot to make something that's both plush AND anti-static, you know!

    • Re:Huh? (Score:5, Informative)

      by Trepidity (597) <delirium-slashdo ... h.org minus poet> on Wednesday April 15 2009, @03:38PM (#27590613) Homepage

      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.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      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.

    • A miniPCI card with an OpenSSL-supported crypto engine that can handle saturate the bus costs around $50.

      You would pay $50.. for a ssl crypto PCI card, and you're implying that 'other' people are being suckered?

      BBH

      • I've not bought one, but I know a couple of people who use them in little embedded firewall boxes. These typically have something like a 266MHz Geode CPU which can't handle SSL or IPSEC at line speed without the accelerator, but can with the (mini)PCI card installed.
        • Dont the geode processors have some sort of AES capability built in? At least the 500mhz Geode-LX does, i have one and it has a kernel driver for the loop-aes device...
          Is there any way to have OpenSSL use this hardware on linux? One of the soekris net5501 boxes would make a good little vpn box if i could do that.

          • Re: (Score:3, Insightful)

            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.
    • Re:Huh? (Score:5, Informative)

      by upside (574799) on Wednesday April 15 2009, @03:49PM (#27590789) Journal

      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.

        • For 10% of the price
        • Re:Huh? (Score:5, Insightful)

          by Anonymous Coward on Wednesday April 15 2009, @06:17PM (#27592497)

          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.

    • Mini-PCI card? How about doing it on the GPU [manavski.com] instead?

  • particle accelerator I can build? cool..oh wait. damn.

    • Re: (Score:2, Funny)

      We did the particle accelerator some time back. Do a search for "scotch tape" and "x-rays".

  • At the moment I have two OpenBSD servers acting as a single firewall infront of two IIS6 Windows 2003 R2 servers - the OpenBSD servers are acting as an Apache2 reverse proxy for IIS. Only one of the IIS6 servers is 'live' at any one time, the second is the spare.

    Currently, the setup has an automatic failover for the OpenBSD servers via CARP, which works great. However, the IIS servers are currently limited to manual failover, they cant use MS Network Load Balancing because I need session based balancin
    • One thing to consider is whether you need session-based fail-over. If you're going to only treat one as live at a time, then send the spare computer the same packets you are sending the live computer, but drop the responses. If the live computer stops responding, allow the responses from the spare to go through.

      The problem will be getting the machines back in sync once the first machine is rebooted. If you assume that the time between the two machines failing is going to be great enough, forward new connect

      • Well, that is one option, but ideally because the IIS servers will be running .Net apps, it would be nice to actually load balance them, so they would both be 'live' in that situation. At the moment, I have to physically repoint the Apache2 proxy at the other server to fail over (or change IP addresses on the IIS box).
      • What I think you're looking for is "carp" and all flavors of bsd do it.

        Here is the third sentence of the post you replied to:

        "Currently, the setup has an automatic failover for the OpenBSD servers via CARP, which works great."

        Given that, he's most likely talking about .NET Session state.

  • uh (Score:4, Informative)

    by anthonyclark (17109) on Wednesday April 15 2009, @03:39PM (#27590621)

    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.

    • Re: (Score:2, Interesting)

      50k? Are you insane? I worked at a company that built similar products, and we had six developers working on it for five years.

      Don't trivialize how hard it can be do build a piece of high performance equipment (especially where you are doing crypto in hardware).

      • Re:uh (Score:4, Informative)

        by deraj123 (1225722) on Wednesday April 15 2009, @05:25PM (#27592001)

        but I guess it'd take a developer more than 50k worth of time to do it.

        He wasn't trivializing. He was, in a somewhat roundabout way, saying that 50k is a lot cheaper than what it would cost to implement the same solution yourself. The summary (don't know about the article, didn't read it) was trivializing the difficulty, the GP was refuting the summary.

    • you *do* know that an F5 Big-IP is more than an SSL accelerator? Like, a load balancer with lots of cool features.

      Yes, that is true. What this also means is that after spending the big bucks for the front end like this, you will save money in the long run because you now have the ability to throw as many boxes behind the SSL switch/load balancer box up until all of its links are used. You don't have to buy new certificates or wildcard certificates for any of the backend devices and/or worry about name mismatches, or any of the common issues with SSL certs.

      I didn't see it on their website, and couldn't really read the

  • Ideally... (Score:5, Interesting)

    by jd (1658) <imipakNO@SPAMyahoo.com> on Wednesday April 15 2009, @03:40PM (#27590647) Homepage Journal

    ...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.

    • Why have an addin card? The acceleration hardware isn't all that complicated. Hell, VIA put it into their proccessors- look at the huge [mini-itx.com] difference it makes. Even if the graph is best-case scenario, that x86 compatable processor is dynamite with encryption.
      • Re:Why a card? (Score:4, Insightful)

        by raddan (519638) on Wednesday April 15 2009, @08:42PM (#27593445)
        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.
  • by Anonymous Coward on Wednesday April 15 2009, @03:46PM (#27590733)

    If their solution was really worthwhile, wouldn't the link to the article have been https:/// instead of just http:// ?

  • It'd be nice to see SSL used on all web sites. Apache can now handle SSL virtual hosts so that obstacle is gone.

    • Y'know who else thinks that it would be nice to see SSL used on all web sites?

      Verisign.
        • Further, regular SSL requires a dedicated IP address for each certificate

          Yes you can. The standard was published almost a decade ago, and I think it's pretty well-supported now. It requires connecting and then doing the SSL handshake once you've identified the server (just as STARTTLS extensions on most other protocols do).

    • Re: (Score:3, Interesting)

      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 corporat

    • Re: (Score:2, Informative)

      Apache is only half the problem at best, the real issue is the lack of compliant clients at a significant level. Server Name Identifcation (the extension to allow for virtual hosts behind SSL/TLS connections) has been supported in Firefox since v2 I believe, and Internet Explorer 7 - though I think that is only on Vista for some reason. I have no idea what Safari, Opera and other browsers and platforms might support.

  • Nginx has been getting a lot of press lately, much of which is well deserved.

    This article is simply that -- use a front-end reverse proxy (like nginx) to your backend server, and let nginx handle the ssl transaction and pass the body of the HTTP request to your backend server where it handles the important stuff.

    This is not an uncommon strategy, and lets you have a lot of flexability.

  • by owlstead (636356) on Wednesday April 15 2009, @04:17PM (#27591221)

    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.

    • Done and done... $50k and equivalent performance of the high end BIGIP stuff
      http://www.zeus.com/news/press_articles/zeus-price-performance-press-release.html [zeus.com]

      • Yes, but then you are back to the 50K pricepoint. OK, that's INCLUDING the application server, but it might still be a bit steep for many applications. And you'd have to port/reconfigure the applications to run on the T2 server.

        One of the advantages of an SSL-offloader is that you only have to remove the SSL from the port running SSL. Hmm, maybe the T2 is not such a good idea if you're having other deadlines pending. System admin time and knowledge is a costly thing.

      • 32 cores at 300 MHz? Only if you really don't understand the difference. And it seems you don't.

        I am self-educated in basic processor design, and that's just plain wrong if you look at the hardware. If you look at it from the OS, you will indeed see 32 cores, but if you are using 8 threads you will get higher speeds than a single core running at 300 MHz. The reason Sun uses 4 threads per core is to optimize the use of the ALU's of the core.

        That's the theory, but I was wondering if you could buy a T2 and eas

  • It's already been done. It's called stunnel. Among other things it lets you do, you can specify a different host to connect to.

    In other words, host A accepts connections on port 443 and can automatically encrypt the traffic and route it through to host B on port 80. It allows you to accept connections on multiple ports, each with its own mapping.

    It also works with name virtual hosts, forwarding the name request through to the other host.

  • Well if you RTFA it says in first paragraph that its NOT a accelerator but off-loader. Beside that it is proxying the connection so you have to change your logging to adept to the Real-IP being inside the http headers. The argument that it is equal secure as true https as it transfers http in the "local subnet only": that vanishes if a machine in this subnet gets compromised. As others mentioned, comparing such (nice) reverse proxy hack with a BIG-IP load balancer is a joke.
  • How does this reduce the number of certificates required? It might reduce the number of copies of the certificate, but you still need either one certificate per subdomain, or one wildcard certificate per domain.

    I'll grant that it makes certificate management simpler, but not significantly so â" it really only saves two minutes every year.

    • "How does this reduce the number of certificates required? It might reduce the number of copies of the certificate, but you still need either one certificate per subdomain, or one wildcard certificate per domain."

      I think that would be because in some instances you could serve multiple applications from the same server (with the same certificate). This does of course not work for internet store applications and such, but for many business communications, it might well work. The proxy can then create a connec

      • Verisgn says SSL accelerators don't count anyway -- you still need to license for each connected server.

        Or you could buy from a more reasonable authority that doesn't impose such restrictions.
    • 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?