Build an Open Source SSL Accelerator 136
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."
Huh? (Score:2, Interesting)
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: (Score:2)
Looks like some guys on Elliot Bay have mod points today.
Re:Huh? (Score:5, Informative)
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, Interesting)
Re: (Score:2)
The other 20%, and your time, is what makes it worth $25k.
Re: Features...all on the same 6900 (Score:1, Troll)
Re: (Score:2)
Still wrong...
It's support... plain and simple...
It is rather simple to get an over night RMA if a unit behaves strangely or begins to fail sporadically. At the same time, there is a support channel available to assist with configuration or other types of soft issues.
I'm not arguing for or against this type of solution, but rather pointing out why it is so high.
There are multiple components to consider when determining what type of purchase to make.
Re: (Score:2)
Re: (Score:2, Informative)
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.
Re: (Score:1)
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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)
Re:Huh? (Score:5, Informative)
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.
Re: (Score:2)
Re: (Score:1, Insightful)
And an order of magnitude less user-friendliness.
Re: (Score:1)
Fortunately, this is a complex area anyway and the person installing it should really know what they're doing.
I wouldn't want some moron from geeksquad configuring my company's SSL stuff.
Re: (Score:2)
Re:Huh? (Score:5, Insightful)
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.
Re: (Score:1, Insightful)
You're confusing 'the time it takes to solve the problem' (i.e., accelerate SSL performance by offloading) against 'the time it takes to produce a a shrink wrapped product that I can sell.'
See, the 50K big-iron will solve the problem; yes. But the goal isn't to replicate what that big-iron never-ever-fail comes-with-a-cherry-on-top can do, the goal is to accelerate *this web server*. Not your web server, not everyone's web servers, but THIS one.
And on THIS web server, we might not *care* about 90% of the
Re: (Score:2)
Mini-PCI card? How about doing it on the GPU [manavski.com] instead?
an OPen sourse (Score:2, Funny)
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".
Tangental question... (Score:2, Offtopic)
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
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
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.
Re: (Score:1)
If it's
Re: (Score:1)
http://httpd.apache.org/docs/2.3/mod/mod_proxy_balancer.html [apache.org]
uh (Score:4, Informative)
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)
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.
Re: (Score:2)
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
Re: (Score:2)
And what if you want several of them (multiple locations, redundancy etc) ? High-end boxes hunt in packs.
The $50k a pop adds up quickly and I quite like the idea of factoring out each feature into a separate cheap box.
The argument is also cited that building something in house means that there is only one person who understands it. That may be true, but I've seen bought-in systems deployed where no-one in house understands fully what it does or
Ideally... (Score:5, Interesting)
...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 a card? (Score:2)
Re:Why a card? (Score:4, Insightful)
Re: (Score:2)
In order to maintain parallelism, you could put the acceleration hardware on the ethernet card. If it's in the CPU, unless it's a parallel core (in the same way that the IBM Cell operates), you don't gain any offload advantage.
It can't be that good (Score:3, Funny)
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 on all web sites (Score:2)
It'd be nice to see SSL used on all web sites. Apache can now handle SSL virtual hosts so that obstacle is gone.
Re: (Score:3, Interesting)
Verisign.
Re: (Score:1)
Y'know who else thinks that it would be nice to see SSL used on all web sites?
Verisign.
You know who is missing (part of) the point of an SSL accelerator? You are!
One wildcard cert + one pair of SSL accelerating Load Balancers = All of your sites can now be SSL.
Re: (Score:2)
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:2)
No they don't.
Yes you can. Read. [wikipedia.org]
Re: (Score:1)
...as soon as you get old OSes and browsers off the net. Read the article to which you link, the scheme doesn't work with Win XP running IE 6 or 7.
So even if you were silly enough to run experimental code in your server, a large percentage of your clients can't use the extension anyway.
The GP is correct: regular SSL requires a dedicated IP address for each certificate. The fact that an experimental extension to SSL gets around this requirement does not alter that fact.
Re: (Score:1)
Actually, strictly speaking, you can run it on a single IP and different ports.
But no one likes that solution.
Re: (Score:2)
Those clients represent an ever decreasing share of the browser market. By the time SSL virtual hosts are deployed on a wide scale, those browsers may be a tiny fraction of the ones in use. A service provider may also decide that the ability to support SSL virtual hosts outweighs the loss of those clients and instead encourage them to upgrade to a different browser such as Firefox.
So even if you were silly enough to run experimental code in your server, a large percentage of your cl
Re: (Score:2)
if you dig into that a little youll realize that the necessary TLS extension isnt officially part of apache yet, and even IE7 on XP doesnt support it.
effectively, at this point, for the vast majority if the internet it is not supported. which is a shame, because id love to use it right now on a project im working on.
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.
Re: (Score:2)
What do you mean by significant? All of the major browsers currently support SNI [wikipedia.org].
Re: (Score:1)
Yeah, except for that whole 'XP running IE6 or IE7', which is something like 60% of all web browsers.
Re: (Score:2)
And steadily declining. It's also only relevant if you care about being accessible to everyone. Do you think Amazon.com or Ebay is going to fret over hosting multiple sites behind a single IP address? Of course not. SSL virtual hosts are most important to home users like you and me. That's where the value it. Not all of those sites care about being accessible by every browser. If people can't access my sit
Re: (Score:1)
It's also only relevant if you care about being accessible to everyone.
Except that you started off this conversation talking about 'all websites', you loon.
But from now on you feel free to pretend 'all websites' are run by hobbyists who can afford to ignore 60% or more of the people out there, and everyone else can freely ignore you.
Re: (Score:2)
Please do not use personal attacks. I will be glad to engage you in conversation but only if you can be civil.
Re: (Score:2)
Yes, I did. Specifically, I said that I'd like to see SSL used on all web sites. Here's the exact quote:
One obstacle to all sites using SSL is the lack of support for SSL virtual hosts. That obstacle is now gone thanks to SNI.
Many sites have dedicated IP addresses and can use SSL just fine. But there are many other web sit
Re: (Score:1)
You don't consider IE 6, or 7 on XP, to be "major" browsers? What odd traffic patterns you must get. I see over 30% IE 6 on my personal server.
Summary: use nginx. (Score:2)
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.
Did anyone else read the headline and think (Score:1)
that they were building an open source Synchrotron Light Source accelerator.
Re: (Score:2)
I somehow read it as SSC [wikipedia.org].
I did. (Score:2)
I did
UltraSparc T2 server as competitor? (Score:4, Interesting)
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.
Re: (Score:2)
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]
Re: (Score:2)
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.
Re: (Score:2)
$50k for something that performs at $150k? And that's for a LB that saturates a 10GB line with full SSL acceleration. That's not trivial to do, and most sites wouldn't even come close to using that. In that case, I'd recommend Intel/AMD gear.
I've used the Zeus software. Never got trained on it, and had it up and running in less that 2 hours. Its really well designed.
Re: (Score:2)
Interesting stuff indeed, and the 50K/150K is of course interesting. But still only if you need the performance of that 150K server, otherwise other project may be less expensive.
My X2 Phenom CPU may also not beat many others in price/performance, but it does what I need using not too much power. I probably could buy a 150$ CPU instead, but I would loose 75$ dollars doing it...
Re: (Score:2)
Done and done... $50k and equivalent performance of the high end BIGIP stuff
Zeus is not a valid competitor for a lot of markets until they add Route Health Injection. It's a glaring feature-set hole for site-to-site failover (via routing) that both Citrix NetScaler and F5 BIGIP support as a bread-and-butter function.
Otherwise, their features like TrafficScript aren't half bad.
Re: (Score:2)
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
Re: (Score:1)
You mean how a 1.6ghz Atom CPU's hyperthreading means it has 2 800mhz threads?
Care to share your crack pipe with the rest of the class?
Re: (Score:1, Informative)
What Sun DOESN'T tell you is that each of those eight 1.2 GHZ "cores" are actually 4 threads (read: cores)... running at 300mhz each.
So what you REALLY get is.... 32 cores, each running 1 thread (total of 32 threads) at a speed of 300mhz. They just group four of them together and market them as a core.
No, you're wrong.
On a T2, you can have 8 or 4 cores, each with a floating point pipeline and two integer pipelines (T1 had one int per core, and one float per chip). Each (real, 1.2GHz) int pipeline is fed by four hardware threads. The hardware threads allow the processor to quickly service the next process if anything stalls. The OS can't do anything about these stalls, and only sees them as busy time, as if the processor was really doing something. The 4 to 1 ratio gives the system pretty good odds of
Re: (Score:1)
My company has a T2000, and it is slow. 1/4 as slow as the 1.2ghz box it replaced.
Everything is slower. From the tarring of files to the rsync of directories.
In order us to even return to the same performance as our old box, we had to make multi-threaded processes kick off approx 4 worker threads to handle the work.
It's not an oracle myth when your single-threaded shellscript takes 4x as long as before.
It's the equivalent of that cashier taking smoke breaks 3/4ths of the time instead of scanning my food!
Sur
stunnel (Score:2)
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.
Re: (Score:2)
Or squid as reverse proxy.
Re: (Score:2)
You don't want to use multiple ports, most proxies will only permit https connections on port 443 so a lot of users behind corporate proxies would be screwed.
Re: (Score:2)
Surely you're joking? stunnel costs an exec() per connection.
Re: (Score:2)
It doesn't if you're merely using it to unwrap the SSL from the connection and proxy it to another TCP port.
Offloading Proxy (Score:2)
Reduce the number of certs? (Score:2)
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.
Re: (Score:2)
"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
Re: (Score:2)
Or you could buy from a more reasonable authority that doesn't impose such restrictions.
Re: (Score:1)
Um, I've never seen a 'license' on SSL certs at all. Where are you people buying these things from?
Lame fanboy piece - no threading (Score:1, Informative)
Hmm, why no mention of nginx's thread limitations? By design, nginx does not use threads and as a result has performance issues scaling beyond one CPU or core. Those limitations will become apparent on certain real world workloads and with realistic tests. Those are important issues and this piece, like many nginx discussions, glosses over them. It also disingenuously tries to compare nginx to commercial solutions.
I like nginx a *lot* and have tested and deployed it in many different situations. But it
Idiotic (Score:2)
Big-IP products are used for their load balancing abilities, and can be used to build content delivery networks based on pools of application resources/servers. They're for sites that simply cannot go down, because downtime would be tremendously costly. Think military. Think medical. Think ebay or amazon. That's a pretty big farking far cry from a simple SSL accelerator. The only
Re: (Score:2)
The only comparable device is a module from Cisco that currently slips my mind.
The Cisco product is pretty sucky. The only comparable product is really Citrix NetScaler.
Re: (Score:2)
HTTPS versus HTTP Cacheing (Score:2)
Any negative interactions?
I hope that HTTPS can cache like HTTP does.
Running end-to-end encryption would certainly prevent proxies from stashing away frequently accessed objects.
Re: (Score:2)
Any negative interactions?
I hope that HTTPS can cache like HTTP does.
Running end-to-end encryption would certainly prevent proxies from stashing away frequently accessed objects.
Your web browser can cache the data in its own cache, but you are correct in guessing that a proxy cannot transparently cache the data.
However, recently, I was looking at Riverbed Steelhead [riverbed.com], which claims to be able to cache SSL-encrypted data. I'm guessing it would work similar to a replay attack -- you don't know what the data means, but you still know what its encrypted form looks like, so you can still cache it. Might be worth a look.
That's bloatware (Score:2)
Why do people bother with ssl accelerators ? It's somewhere else, so you're always talking to it via a stream. Doing a round of AES ECB isn't so expensive as to weigh up to all that network traffic, right ? Better to equip your hardware with crypto-coprocessors, crypto-PCI hardware, or run it all on VIA C-7's. They have on-board crypto, accessible via special instructions.
Buy a decent CPU (Score:2)
Nehalem family CPUs have AES encryption commands in assembler (supported by Linux). UltraSPARC T2 have 8 cryptographic accelerators onboard. By buying modern CPU you have SSL acceleration.
Re: (Score:2)
Nehalem family CPUs have AES encryption commands in assembler (supported by Linux).
Except that AES isn't processor intensive to begin with; it's a bunch of XORs and table lookups for GF(8) exponentiation. The processor intensive part of SSL is the public key work.
More of a security risk with this scheme (Score:1)
The problem with that statement is private does not always stay private when web servers are involved. If any one of the web servers on the lan between the webservers and the SSL decryp
Compile OpenSSL with -O3? (Score:2)
I guess if you're BofA or Wellsfargo and you have 10gb of traffic and just an army of contractors for your IT staff, this might make sense, but - Seriously! It's been a while since I played with accelerators, and I also hate anything F5 with a passion, but with commodity hardware as cheap as it is (PowerEdge 1950 or Sun X4000-something equivalent), why bother with an expensive magic box which has some cheapo Supermicro-class PC on the inside? Especially if you have an app, like a web app or some random VPN
what about offloading encryption / decryption? (Score:1)
Re: (Score:3, Funny)
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?
Re: (Score:1, Redundant)
Re: (Score:1)
Yes, all content in SSL pages is encrypted, because otherwise MitM attacks are easy..an attacker simply replaces part of the loaded unencrypted content with Javascript to pass them a copy of the page and all submitted data.
This is why web browsers warn about unencrypted content.
Re: (Score:2)