×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Build an Open Source SSL Accelerator

timothy posted about 5 years ago | from the macguyver-it-up dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

136 comments

Huh? (1, Interesting)

TheRaven64 (641858) | about 5 years ago | (#27590425)

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:Huh? (1, Funny)

jd (1658) | about 5 years ago | (#27590515)

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? (4, Informative)

Trepidity (597) | about 5 years ago | (#27590613)

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:Huh? (0, Troll)

GNUbuntu (1528599) | about 5 years ago | (#27590795)

Well then they should just buy the Ninnle SSL accelerator that is a octo-core rackmount server with 100GigE and only costs you 500 dollars. This is all thanks to the new innovations constantly coming out of Ninnle Labs.

Re:Huh? (2, Interesting)

Anonymous Coward | about 5 years ago | (#27591175)

you combine nginx, haproxy, varnish-cache and you've got 80% of what Big-IP does!

Re:Huh? (2, Informative)

Anonymous Coward | about 5 years ago | (#27590629)

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:Huh? (0)

Anonymous Coward | about 5 years ago | (#27591269)

any leave all the sensitive traffic on your (hopefully) private network unencrypted. Yay! what a smart idea.

Re:Huh? (-1, Troll)

Anonymous Coward | about 5 years ago | (#27591717)

Private network? Use self-signed certs you clueless neeb. It's free.

Re:Huh? (0)

Anonymous Coward | about 5 years ago | (#27591875)

You're missing the point. In a SSL accelerator scenario, you're only encrypting this traffic at the border. Between the accelerator and the web server, the traffic is unencrypted. If it's sensitive enough to encrypt at the border, should you be assuming your network is pure?

Re:Huh? (0)

Anonymous Coward | about 5 years ago | (#27594405)

Just because you don't understand doesn't mean he's missing the point. He gets it, you don't.

Re:Huh? (1)

BigBuckHunter (722855) | about 5 years ago | (#27590711)

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:Huh? (1)

TheRaven64 (641858) | about 5 years ago | (#27590803)

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.

Re:Huh? (1)

Bert64 (520050) | about 5 years ago | (#27591643)

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:Huh? (2, Insightful)

TheRaven64 (641858) | about 5 years ago | (#27591687)

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? (4, Informative)

upside (574799) | about 5 years ago | (#27590789)

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:Huh? (0)

Anonymous Coward | about 5 years ago | (#27591361)

yeah : you combine nginx, haproxy, varnish-cache and you've got 80% of what Big-IP does!

Re:Huh? (1)

jgtg32a (1173373) | about 5 years ago | (#27591425)

For 10% of the price

Re:Huh? (1, Insightful)

Anonymous Coward | about 5 years ago | (#27592671)

And an order of magnitude less user-friendliness.

Re:Huh? (1)

afidel (530433) | about 5 years ago | (#27596711)

Not when you include the man months to do all the configuration and tweaking needed to get it working perfectly. Plus it's not like you can really simulate the real world load these types of boxes experience so you would have to put your homebrew solution in front of a webfarm where downtime is many multiples the cost of the BigIP solution. The fact is only a cash poor startup is likely to use such a solution because it's about the only situation where you would have sufficient traffic without the revenue to justify the commercial solution.

Re:Huh? (-1, Troll)

Anonymous Coward | about 5 years ago | (#27591905)

You clearly have no idea what a Big-IP is capable of.

Re:Huh? (5, Insightful)

Anonymous Coward | about 5 years ago | (#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.

Re:Huh? (0)

Anonymous Coward | about 5 years ago | (#27594733)

But wouldn't the opensource project want a company to pay a geek to do this for them, so as to have the geek contribute back to the opensource project (a requirement since it's, um, well, under an opensource license)... So, as long as a few of these companies are willing to support the required number of geeks, the project will float. Perhaps this whole article is all a ploy to get this opensource project into the mainstream by getting some companies to fund some geeks. Heh. Good luck, if that's the case.

Re:Huh? (1, Insightful)

Anonymous Coward | about 5 years ago | (#27594947)

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 things that are supposidly tested on that commerical grade piece of equipment, which is why the geek will only take a week to get it working.

(It's also been my experience that commerical grade tested stuff somehow doesn't seem to work with your piece of equipment, even though the brouchure said it did, meaning you've got both the 50K expenditure AND all the geek time required to get the 50K box doing what it was supposed to do.)

Big iron gear is usually unnecessary. The main question is whether this open source box can keep up with the demand - and, for a lot of situations, it can.

Re:Huh? (0)

Anonymous Coward | about 5 years ago | (#27591465)

How about an approved FIPS 140-2 compliant solution

Re:Huh? (0)

Anonymous Coward | about 5 years ago | (#27593647)

You are leaving out PC build time, OS install, config and maintenance, and applications and of course your time is free.
If you are really cheap but want reasonably good - especially for the money - get a Barracuda.
I work with Cisco Local Directors,CSS, NetScalers and Barracuda and for reasonably nice ( port redirection, ssl offload, various performance load parameters ) they are hard to beat.

Course I did this 6 years ago with 750 MHz P3s and then ran Stunnel back to remote servers thereby maintaining encryption all the way. 2 Cisco Local directors at the front end handled the actual load distribution.

You might still be able to pick up used Alteon/Intel SSL boxes as well.

Re:Huh? (0)

Anonymous Coward | about 5 years ago | (#27594121)

which one please? name you names...

SSL Accelerator?? (0, Redundant)

Narnie (1349029) | about 5 years ago | (#27590533)

Why bother with that? I just encrypt everything with ROT-13... twice. Much faster.

Re:SSL Accelerator?? (3, Funny)

Zaurus (674150) | about 5 years ago | (#27590609)

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:SSL Accelerator?? (0, Redundant)

Narnie (1349029) | about 5 years ago | (#27590675)

Hmmm... not too sure if ROT-52 is enough. If you can make a ROT-208 accelerator for $100,000, you might just have a sale.

Re:SSL Accelerator?? (0, Redundant)

fuzzyfuzzyfungus (1223518) | about 5 years ago | (#27590625)

Double rot-13 is, perhaps, the only algorith that can be optimised using only the delete key...

Re:SSL Accelerator?? (-1, Flamebait)

Anonymous Coward | about 5 years ago | (#27590723)

This is, in fact, a lie.

You filthy yew.

Re:SSL Accelerator?? (-1, Redundant)

Anonymous Coward | about 5 years ago | (#27590741)

Damn!

I was doing it four times. Weeks of extensive testing here has proved that your system was just as effective with twice the efficiency.

I salute you, sir.

an OPen sourse (1, Funny)

geekoid (135745) | about 5 years ago | (#27590537)

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

Re:an OPen sourse (1, Funny)

jd (1658) | about 5 years ago | (#27590721)

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

Tangental question... (1, Offtopic)

Richard_at_work (517087) | about 5 years ago | (#27590599)

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.

Re:Tangental question... (1)

jd (1658) | about 5 years ago | (#27590825)

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 connections only to the rebooted machine on the basis that all older sessions will terminate before the second machine fails.

Re:Tangental question... (1)

Richard_at_work (517087) | about 5 years ago | (#27590891)

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

Re:Tangental question... (0)

Anonymous Coward | about 5 years ago | (#27591467)

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.

You can have a .net farm of machines where session state is stored in an sql database and not by the web server (assuming that you have a robust live replicated or clustered database). Works well.

Re:Tangental question... (1)

awpoopy (1054584) | about 5 years ago | (#27591655)

What I think you're looking for is "carp" and all flavors of bsd do it. You may want to check out pfsense: http://www.pfsense.org/ [pfsense.org]. I've used it for years. Depending on requirements, just throw the appropriate amount of hardware together. You can fail-over ipsec tunnels with it. Suitable for all enterprise uses.

Re:Tangental question... (1)

nacturation (646836) | about 5 years ago | (#27594149)

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 (3, Informative)

anthonyclark (17109) | about 5 years ago | (#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:uh (2, Interesting)

Puzzleer (309198) | about 5 years ago | (#27591289)

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 (3, Informative)

deraj123 (1225722) | about 5 years ago | (#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.

Re:uh (1)

hackstraw (262471) | about 5 years ago | (#27592283)

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 site either (marketing/manager speak or some other language I don't know), but many of these devices like the F5 Big-IP also have pretty much tamper proof storage of the private keys for the certificates. These things will zero out the device if tampered with and whatnot, which may or may not be of importance to you. Its likely to be more important to you if you are in a colo setup.

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.

What is almost sad is that the box probably already runs ngix or some variant of Linux and/or SSLeay.

Ideally... (4, Interesting)

jd (1658) | about 5 years ago | (#27590647)

...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? (1)

dj245 (732906) | about 5 years ago | (#27593249)

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? (3, Insightful)

raddan (519638) | about 5 years ago | (#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.

It can't be that good (3, Funny)

Anonymous Coward | about 5 years ago | (#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 on all web sites (1)

Matt Perry (793115) | about 5 years ago | (#27590785)

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:It'd be nice to see SSL on all web sites (2, Interesting)

fuzzyfuzzyfungus (1223518) | about 5 years ago | (#27590975)

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

Verisign.

Re:It'd be nice to see SSL on all web sites (0)

Anonymous Coward | about 5 years ago | (#27591035)

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

There are many sites that don't really require SSL. It just isn't private or sensitive information, and the crypto overhead isn't trivial.

Further, regular SSL requires a dedicated IP address for each certificate. You can't have multiple SSL websites on the same IP address.

On the other hand, this would push for IPv6...

Re:It'd be nice to see SSL on all web sites (1)

TheRaven64 (641858) | about 5 years ago | (#27591243)

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:It'd be nice to see SSL on all web sites (1)

Matt Perry (793115) | about 5 years ago | (#27594303)

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

No they don't.

You can't have multiple SSL websites on the same IP address.

Yes you can. Read. [wikipedia.org]

Re:It'd be nice to see SSL on all web sites (1)

Mr. Slippery (47854) | about 5 years ago | (#27596779)

Yes you can.

...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:It'd be nice to see SSL on all web sites (1)

Darby (84953) | about 5 years ago | (#27592143)

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:It'd be nice to see SSL on all web sites (2, Interesting)

jd (1658) | about 5 years ago | (#27591031)

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

Re:It'd be nice to see SSL on all web sites (1, Informative)

Goyuix (698012) | about 5 years ago | (#27592113)

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:It'd be nice to see SSL on all web sites (1)

Matt Perry (793115) | about 5 years ago | (#27594277)

Apache is only half the problem at best, the real issue is the lack of compliant clients at a significant level.

What do you mean by significant? All of the major browsers currently support SNI [wikipedia.org].

Re:It'd be nice to see SSL on all web sites (0)

Anonymous Coward | about 5 years ago | (#27595087)

Read that again. IE6 and IE7 on XP don't support SNI. Vista has flopped and IE8 hasn't even been out for a month, so writing off all those users is not going to be an option for at least another year.

Re:It'd be nice to see SSL on all web sites (0)

Anonymous Coward | about 5 years ago | (#27597603)

As the wikipedia article you link to states, IE only supports SNI on Vista, so the most used browser on the most used OS doesn't support SNI. It'll be some time yet before SNI can be widely used to solve the SSL vhosts problem.

Summary: use nginx. (1)

mystik (38627) | about 5 years ago | (#27590823)

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.

UltraSparc T2 server as competitor? (3, Interesting)

owlstead (636356) | about 5 years ago | (#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.

Re:UltraSparc T2 server as competitor? (1)

bajan_on_ice (32348) | about 5 years ago | (#27592017)

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:UltraSparc T2 server as competitor? (1)

owlstead (636356) | about 5 years ago | (#27592645)

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:UltraSparc T2 server as competitor? (0)

BobSixtyFour (967533) | about 5 years ago | (#27592305)

Big mistake.

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.

Re:UltraSparc T2 server as competitor? (1)

owlstead (636356) | about 5 years ago | (#27592539)

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 easily configure it for SSL acceleration. It does have the 8 (EIGHT) cores including crypto accelleration and 2 x 10 GBit eithernet connections, so in theory it should be great. However, theory != practice. For instance I don't know how much you'd have to spend after the initial 15K, and if there are any easy to install/free SSL-proxies available.

Re:UltraSparc T2 server as competitor? (0)

Anonymous Coward | about 5 years ago | (#27592555)

Big mistake.

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.

Where did you learn this from?

There are only 8 cores running at full speed (not at 1/4 speed as you state). There are not 32 cores, but 4 threads per core. Most of the core's units are shared among threads.

Re:UltraSparc T2 server as competitor? (1)

otis wildflower (4889) | about 5 years ago | (#27593219)

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:UltraSparc T2 server as competitor? (1, Informative)

Anonymous Coward | about 5 years ago | (#27593705)

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 being able to keep all 16/8 int units busy all the time. If the OS is executing more than 16/8 processes concurrently, then per process speed will be less than 1.2GHz obviously. No different from running four busy processes on a 1Ghz Pentium, (ignoring superscalar execution) each one will run at about 250MHz. Any number of concurrent processes above the number of real cores x int units you have is just eking out better efficiency, not real processing power.

There is a lot to gain from better efficiency though, because typical processors spend a lot of time doing nothing even when the OS sees 100% busy.

I don't know where this stupid 300MHz myth started (Oracle?), but it's not why single threaded performance on T1/T2 lags behiind other processors. The reason is other UltraSparc chips are super scalar, and mostly have a faster clock rate. That is the real trade off for better efficiency, laying out all the resources horizontally, as opposed to stacked vertically.

Here's an anology:
Niagra chips work like queuing up to four customers to a cashier, but if any one of them stalls (price check!) he simply starts on the next one immediately. You'll put one in each lane before this happens though.

Other modern chips are like sticking two cashiers (and baggers) per lane, but strictly working with one customer at a time. A stall can easily hold up multiple workers. You have fewer lanes, but they can be really, really fast - except in practice, your customers do really stupid things all the time, like handing you a cart full of tagless items. For this reason, your workers need to be extra fast to average out all the worst case scenarios.

stunnel (1)

KillerBob (217953) | about 5 years ago | (#27591481)

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:stunnel (1)

Bert64 (520050) | about 5 years ago | (#27591625)

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.

Offloading Proxy (1)

tronicum (617382) | about 5 years ago | (#27591517)

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.

Build your own to replace the BIGIP? (-1, Troll)

Anonymous Coward | about 5 years ago | (#27591649)

Good luck. The BigIP platform is sold to Enterprise companies. If there is any enterprise company that is wasting money hiring a guy to build them that, and support it, and update the software on it, and so on, and so on... That is an enterprise company that has the wrong goals in mind, and won't be around for long.

Buy another enterprise server if that's too much.

For the screw around test lab in my basement environment, yes... go build your own. It's way too much for that.

A lot of that money is for the hardware, but then another good chunk is probably for the support license.

Reduce the number of certs? (1)

Sentry21 (8183) | about 5 years ago | (#27591985)

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:Reduce the number of certs? (1)

owlstead (636356) | about 5 years ago | (#27592227)

"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 connection to a specific server depending on the URL. I understand this is what many offloaders do.

In any case, you would only have to setup keys and certificate stores on the one or two off-loaders instead of all the application servers out there, which simplifies management, even when multiple keys/certificates are required.

Re:Reduce the number of certs? (0)

Anonymous Coward | about 5 years ago | (#27592351)

Actually, most SSL-certificates require you to buy licenses for every additional server you install them on, and the licenses cost about as much as the certificate itself.

Re:Reduce the number of certs? (1)

profplump (309017) | about 5 years ago | (#27593281)

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.

Lame fanboy piece - no threading (1, Informative)

Anonymous Coward | about 5 years ago | (#27592605)

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.

Crescendo Networks (0)

Anonymous Coward | about 5 years ago | (#27593329)

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

Objectivity - author of the article works Nortel (0)

Anonymous Coward | about 5 years ago | (#27593497)

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.

Idiotic (1)

scubamage (727538) | about 5 years ago | (#27594403)

Big-IP products are not just SSL accelerators. If you want an SSL accelerator go on ebay and pick up an ncipher card for cheap.

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.

Re:Idiotic (0)

Anonymous Coward | about 5 years ago | (#27597271)

Big-IP products are not just SSL accelerators. If you want an SSL accelerator go on ebay and pick up an ncipher card for cheap.

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.

RTFA, the comparison was done with the industry leading SSL Accelerator, everyone knows that F5's product is more than an SSL Accelerator. If you read the article though, it suggests you can use HAproxy and Varnish-Cache on the back-end to perform the load balancing functions. I think the point of the article wasn't to replace Big-IP at military or medical institutions but to make the technology accessible to those that cannot afford the heavy price tag.

On a side note, the price does *not* include two units. The Big-IP 6900 costs $51000, with another $25k for the licensing. So that is $76000 per unit. They will discount the unit down to 80% normally but in this economy I have seen it get marked down as much as 60%.

If you are impressed by F5 then you are an idiot. All F5's box is, is a x86 machine with a switch-port fanout card and some additional hardware. All of the techniques that F5 uses are available through this project or that project. F5 has them just tied together with a nice UI.

HTTPS versus HTTP Cacheing (1)

shentino (1139071) | about 5 years ago | (#27594511)

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:HTTPS versus HTTP Cacheing (1)

Jeremy Visser (1205626) | about 5 years ago | (#27595193)

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 (1)

bytesex (112972) | about 5 years ago | (#27594563)

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 (1)

zdzichu (100333) | about 5 years ago | (#27595083)

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.

is SSL overused? (0)

Anonymous Coward | about 5 years ago | (#27595241)

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?

Key security must not be forgotten (0)

Anonymous Coward | about 5 years ago | (#27595443)

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.

Article fell off the net, because... (0)

Anonymous Coward | about 5 years ago | (#27596187)

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

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...