SSL Acceleration

From: anonymous
Date: April 16, 2000

The nCipher/Linux solution is spotty. I had a lot of trouble getting it to work right and ended up getting a tech out to help me. In addition to a driver, it needs a special application that loads into memory to help it....

The Rainbow card is better, but their OpenSSL support is so/so. From the patches, it appears that they basically modify OpenSSL so that it can offload the big number stuff to the card. I think it would be much wiser of them to publish a spec to the OpenSSL group and let them do true integration with it. Because of their patch, we could never get more than 117 connections/sec. with the Rainbow card.

Now the catch with the Rainbow card.... =) Read the fine print carefully and you see that they do 200 RSA ops/sec. More accurately, they can do one RSA operation in 4.9ms. This does not take into account the overhead of SSL, network connection setup and tear down, etc. The iPivot (Intel) solution that advertises 200 connections per second really only gets 117 when you tell Web Bench to not do any session id reuse. (Oops.) I'm sure that is also the case with anyone who uses the Rainbow card in their product. Ditto with nCipher.

Overall experience with the Rainbow card: Good. Their tech support is pretty good. The patch to OpenSSL works reliably, albeit, slower than I'd like it to. Their sales team is confused, but what else is new?

Personally, I'd like to get my hands on the Compaq Atalla card to benchmark it and find out. I'm sure if they managed to get native OpenSSL support, they'll whip the pants off Rainbow.

From: anonymous
Date: April 20, 2000

The nCipher boxes are definitely Not There Yet for Linux support. [as of October 1999 - ed.] They had severe problems with kernel versions, OpenSSL versions, etc. -- the list of supported versions was quite narrow and sometimes inconsistent. They did not release driver source code to the public, but their drivers could be quite sensitive to kernel versions because they use the SCSI generic (sg) interface to talk to the nCipher device through a SCSI host adapter.

nCipher does not actually have a lot of customers using their product with Linux. It was originally designed for other Unix operating systems. So far, the Linux drivers seem like an afterthought. I am concerned that it feels more like a demo or proof-of-concept at the moment.

I have no doubt that their product is nice and could work well with Linux at some point. I hope that the company will provide better support for Linux in the future than it has done so far.

The Rainbow cards are indeed a better choice right now. The fact that they go inside of your machine makes them kind of scary. But the vendor shows more commitment to helping people use the cards with Linux.

I think the information on your site is right in that neither vendor has yet published source code. (This is a pretty big problem for hardware, where kernel data structures and interfaces are a moving target.) I am told that it may be possible to get the Rainbow code under NDA.

We were told that the iPivot stand-alone box contains several Rainbow cards and runs an embedded BSDI Unix. Considering the price tag, we didn't want to open up a demo unit to look.

I would like to have seen some of the other devices you mention which actually do have open source drivers. I don't think most of them were around last year.

From: anonymous
Date: April 20, 2000

Hi, I just saw your SSL acceleration page and it was interesting. I've been using NCipher Nfast (now called NForce) accelerators where I work. You probably already know that a 700 mhz Pentium III running stock OpenSSL can do about 100 RSA secret key ops (1024 bit) per second, so a dual processor PIII can do twice that many, while still costing [less than] most of the accelerators you mentioned. This is way more SSL connections per second than any reasonable web server will ever need to initiate, since low traffic sites won't get that many hits, and high traffic sites probably have enough dynamic content that they'll be splitting loads of that magnitude across multiple servers. Keep in mind that the SSL session cache in the browser and server means you normally won't start new SSL sessions as you click around inside a secure site. IMHO, the most important use of crypto hardware in a secure web server is secure key management, and your page doesn't mention that at all.

Also, you might like to know that NCipher recently released Linux drivers for the NForce series that are supposed to be much better than the old drivers. Better still, they're now available in source code form, at least to NCipher users (I doubt if they're open source). NCipher also offers some OpenSSL integration. I'm not trying to make a sales pitch for NCipher, but I've generally been happy with their stuff and haven't used anyone else's.

Finally, you might want to mention the Java cryptographic iButtons (http://www.ibutton.com/ibuttons/java.html). These are programmable FIPS 140-1 secure processors in welded steel cans the size of watch batteries, that start out at about $12.00 apiece. They take about 1 second to do a secret key RSA op, so they might best be classified as "decelerators" rather than accelerators, but they seem like a very cost effective key management solution. I'd probably even use them for SSL session startup on low traffic servers.

From: anonymous
Date: April 25, 2000

I have a cryptoswift card ... and they have NOT released the driver code. I am not talking about the API and libraries, but the kernel module driver that controls the hardware. Because I use the non i86 machines and the latest [Linux] kernels, the drivers they supply will not work.

I wish that you can post this message with the SSL page that you have. I would like the driver code or my money back.

From: [email protected] (Steve Parkinson)
Date: April 26, 2000

I work with the security group here at Netscape. I saw your page describing hardware crypto solutions for Linux. For Netscape products, we support the PKCS#11 API, which I believe has given us the widest range of hardware support for crypto devices - smartcards and accelerators.

The code which Netscape uses for SSL has been open-sourced recently under MPL and GPL. This includes our SSL implementation and the code which manages PKCS#11 devices - collectively called NSS. I would very much appreciate it if you could put a link to our page on your site. We went through great pains to dual-licence the code specifically so that Linux developers would be able to use it. Check us out.

http://www.mozilla.org/projects/security/pki/

From: [email protected]
Date: April 30, 2000

Hi Dan,
I noticed you put up a nice page on getting SSL hardware acceleration for linux (kudos for the great info!) and wanted to follow up with some info about Rainbow, and iPivot (now Intel).

First, Rainbow: I'm very happy with them... We're currently using a bunch of CryptoSwift cards, and I've also played with their NetSwift (which is targetted more for IPSec/IKE applications). We've gotten full driver source for the NetSwift and the kernel crypto libraries, as well as sources CryptoSwift driver from them without any arm- twisting on our part (well, we bought ten cards for starters, so that may have had some effect 8-). Although their OpenSSL integration is not the greatest (from the point of view of ease-of-use, keeping up with new OpenSSL versions, and archtiecture of their code), it works and was given to us also without any major effort on our part.

I'm pretty happy with performance -- with our in-house servers, which use a phhttpd-based I/O core, I get pretty close to the 200 conn/s. I hear they also have a card spec'ed at 600 connections/second.

Next, iPivot: I don't want to crap on these guys, but they're the main reason I ended up writing the SSL-terminator software mentioned above from scratch. Both their boxes do 200 conn/s, but max out at around 2500 connections through one box. When we were evaluating their CA-1000 box in December, it would regularly crash and nuke all existing 2500 connections rather than roll over or deny the connection. The max connection limit may not be bad for people doing standard web serving where connection come and go quickly, but we had a need for long-lived connections, so it was of ultimate importance. (As a side note, it was also pretty easy to defeat their lame console security and muck around in the OS -- which is BSDI, and it does just package an OEM version of the Rainbox chip onboard -- running on the box, although we had to return the box before I really had any fun with it 8-).

I don't have any experience with nCipher, but my manager had been beating on them for a couple of months for driver source before I started and never got anywhere. Rainbow was also the choice we made at my previous employer where we were doing IPSec/IKE work.. They were the most helpful with software/drivers/specs.