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."
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?
I am TheRaven on Soylent News
Why bother with that? I just encrypt everything with ROT-13... twice. Much faster.
greed@All_Evils:~#
particle accelerator I can build? cool..oh wait. damn.
The Kruger Dunning explains most post on
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 balancing, and not just IP based balancing.
Can anyone recommend an easy way to implement session based failover? I took a look at Nginx before settling on Apache simply because the Nginx documentation was terrible, and also very highly 'you already know the product' orientated.
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.
...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)
Frank Shoemaker dies at 86.
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.
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
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.
Why aren't you encrypting your e-mail?
that they were building an open source Synchrotron Light Source accelerator.
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.
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.
If you believe everything you read, you'd better not read. - Japanese proverb
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.
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 is not always the best choice, and in some cases is a poor choice.
When I rolled out some new nginx services 6 months ago, nginx was only being developed by one person. Again, not a showstopper for everyone but it would be for some.. and Very worth mentioning in an article that compares nginx to commercial solutions. Nginx is great at some things but it is still maturing.
Why have an addin card? The acceleration hardware isn't all that complicated. Hell, VIA put it into their proccessors- look at the huge difference it makes. Even if the graph is best-case scenario, that x86 compatable processor is dynamite with encryption.
Even those who arrange and design shrubberies are under considerable economic stress at this period in history.
Crescendo Networks has a product called the AppBeat DC (Horrible name, great product). It beats the pants off F5, and was about 60k for a pair of them...Does Hardware SSL, Compression, Load Balancing, TCP Offloading...Oh, and it doesn't slow down if you turn it all on at once. :-) http://www.crescendonetworks.com/application.aspx?appbeat_dc
The author of the article "currently holds a Software Engineering / Consulting position in the Global Product Support group at Nortel, where he works on the Nortel VPN Gateway line of products." (http://www.o3magazine.com/0/6.html). Maybe the fact that Nortel's LB and VPN solutiona are getting creamed in the Gartner reports has him a little mad? Of course it could be that he "work as a Sustaining Engineer at Alteon WebSystems Inc" which is soon to be sold off to Radware, all competitors of the company mentioned.
It is a cool little project and would be nice if you have a small site but is not really in the same league as real dedicated LB solutions from any of the big players in the space.
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 comparable device is a module from Cisco that currently slips my mind.
The summary is drivel, it compares apples to oranges. You pay the price tag for f5 because it includes training, two units (they will not sell a single unit, period, for redundancy purposes). I have two of them on my desk right now that I have to learn, and they're some pretty effing awesome pieces of kit.
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.
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.
Religion is what happens when nature strikes and groupthink goes wrong.
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.
:wq
I've got a lot of questions...
Is SSL's slowness a problem for serving web pages or for VoIP or?
Is it the private (symmetric) key exchange that takes time or the symmetric cypher?
If we're talking about slow secure web pages servicing, isn't SSL's overuse the main problem?
How much does a website really need to encrypt?
If, say, I'm adding something to my online shopping cart on a page using https, are all the banners, logo, etc. served using encryption (provided they were not previously cached)?
Could a better "webapp design" help deal with SSL's apparently inherent slowness?
You forget the fact that most crypto hardware actually generate and/or store the key in a secure location (HSM). It's not only about acceleration.
... their DNSen, all freaking two of them, are like next to each other and then the link failed, or something. Way to do a micros~1 here, people.
I did
"The SSL accelerator in front of the servers takes the incoming SSL transactions, decrypts them, and then forwards them on to the servers as HTTP. This is still secure as the connection between the SSL accelerator and the servers is a private local network, there is no unsecured transaction going over the public Internet."
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 decryption server get compromised then getting the unencrypted data from other servers on the same lan is very easy to do since all the SSL traffic is plain text on the web server lan. Hopefully the backend traffic is also encrypted too.
If you are just running one website then you could argue that if one server is compromised then the attackers would only get data from that one website but just more of it. I have a feeling most people who implement this type of solution would have multiple sites being decrypted on the same lan though.
You could reduce this risk by making sure that every site has it's own dedicated lan between the web servers and the decryption server.
I know this method would not be acceptable at our company. Different companies have different ideas about acceptable risk though.
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 thing, which is easily clusterable.
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
Anyone have any success offloading encryption / decryption functionality using these cards? Not so much for SSL acceleration but for securing database rows?
Discloser: I work for F5... You're discounting the real time OS which provides all the integrated SSL offload, compression, caching, etc inline... TMOS. Even a comment on our own Dev Central was asking where they could download our proxy source, just because we use CentOS as a bootstrap and platform for our control plane (GUI). It would be a major technology misunderstanding to believe that we process our real time integrated proxy code in standard SMP interrupt driven I/O ways on the hardware. We don't. I really appreciated the fact that the author and comments at least see clearly the need to go to true proxies without fast pathing the server response. I'll have you talk to the customers of my competition and expect the P.O.s to show up. Here is a list of critical features I deploy regularly for my customer with TMOS which I would be interested in hearing the FOSS solutions for. These are all stock features, not software add-ons (we have those too!) of BIG-IP LTM on 6900. - Homing 100-1000s of virtual servers each with their own separate layer 4 WAN/LAN optimization characteristics. We give about 20% performance improvement at layer 4 for your TCP based applications (not just HTTP). What's the corresponding FOSS way of doing 100s of different TCP layer optimization configurations on the same box? - We base the level of HTTP gzip compression on the layer 4 rtt timing, effectively giving variable rate compression tuned to the individual end client's connection ability. We don't compress at all if you are sitting right next to the server on a Gbps link... why would you.. it slows things down? - We do HTTP level connection multiplexing on the backend, saving your server 1000s of connection requests...driving your scaling way up. - We user our business logic engine to AES encrypt/decrypt HTTP cookies on the fly. (Shall I start base64ing everyones cookies now and see how many sessions I can high-jack?) - We use our business logic engine to perform DR and business continuity decisions based on backend application performance metrics. This demands dynamic SNATs per backend connection. (Personally I need this for a charity I help with... Someone have interesting iptables on steroids solution for me?) - We use our business logic engine to consume HTTP redirects, avoiding costly WAN re-connections. That can be as much as a 4-5x improvement in user experience over the Internet. - We use our business logic engine to intelligently decide to cache or compress specific pieces of content. Anyone run into IE choking on specific Javascript because it was compressed...we do all the time. - We use our busines logic engine to help direct search bots to optimized content servers to improve a sites search ranking. - How about something as simple as rewriting the page content to replace hard coded links on the fly at Gbps speeds? We do it everyday. I can go on for hours.. We use our real time software stack (TMOS) as a swiss army knife to perform solutions which vary between helping reduce backend replication topologies, to SIP message based load balancing for IVRs, to SMTP mail reputation service integration, to.. you name it. And we do it at high-speeds for everything because of the tight integration... not point proxies chained together in a box. With the level of switching integration also provided in our platforms, we virtualize layer 2,3,4,5,6, and 7 in the stack with integrated business logic. You add that to our load balancing and monitoring heritage, and that's a 6900..not just basics SSL offload, caching, compression proxies. We're a layer of intelligence on the network you are not used to having. A lot of the guys inside F5 are linux heads and love their FOSS. Me included.