SSL (https, really) accelerators for Linux/Apache?

There is too much conflicting information out there.  Can
someone
please recommend an SSL accelerator board that they have
personally
tested and used, that works with the 2.6.* kernels and the
current
release of OpenSSL, and is actually an *accelerator* (I've
used a
board from a certain otherwise famous manufacturer that
acted as a
decelerator...).  I only need this for SSL, not for IPsec.

Thanks,

/ji

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

On Tue, Jan 02, 2007 at 01:43:14PM -0500, John Ioannidis
wrote:

> There is too much conflicting information out there. 
Can someone
> please recommend an SSL accelerator board that they
have personally
> tested and used, that works with the 2.6.* kernels and
the current
> release of OpenSSL, and is actually an *accelerator*
(I've used a
> board from a certain otherwise famous manufacturer that
acted as a
> decelerator...).  I only need this for SSL, not for
IPsec.
> 

I don't have any experience with any hardware in this space,
but you
should be clear about one thing:

    - Are you trying to accelerate symmetric bulk crypto of
the SSL
    payload, or the PKI operations in a cold SSL handshake?

Depending on the application and load, and given a suitable
SSL session
cache, the PKI load may be negligible. For example, traffic
between two
fixed MTAs with caches on both sides only does one SSL
handshake per
cache TTL and then just bulk crypto for many deliveries that
reuse the
cached SSL session.

So what is your load like?

-- 

 /" ASCII RIBBON                  NOTICE: If received
in error,
  / CAMPAIGN     Victor Duchovni  please destroy and notify
  X AGAINST       IT Security,     sender. Sender does not
waive
 /  HTML MAIL    Morgan Stanley   confidentiality or
privilege,
                                   and use is prohibited.

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

for lots of topic drift about fast transactions and
lightweight SSL
(somewhat related to past assertions that majority of SSL
use has been
e-commerce related)... recent post in thread on secure
financial
transactions
http://www.g
arlic.com/~lynn/2007.html#28 Securing financial
transactions a high priority for 2007

having some discussion about this news URL from today:

Faster payments should not result in weaker authentication
http://www.securitypark.co.uk/article.
asp?articleid=26294&CategoryID=1

... other posts in the same thread:
http://www.ga
rlic.com/~lynn/2007.html#5 Securing financial
transactions a high priority for 2007
http://www.ga
rlic.com/~lynn/2007.html#6 Securing financial
transactions a high priority for 2007
http://www.g
arlic.com/~lynn/2007.html#27 Securing financial
transactions a high priority for 2007

so having done a lot of optimization on the original payment
gateway
and some other SSL uses ... some of it mentioned in this
thread
(to help minimize payment transaction elapsed time):
http://www.ga
rlic.com/~lynn/2007.html#7 SSL info
http://www.g
arlic.com/~lynn/2007.html#15 SSL info
http://www.g
arlic.com/~lynn/2007.html#17 SSL info

now, in the above thread, I've discussed the possible
"catch-22" for
the SSL domain name certification industry 
ht
tp://www.garlic.com/~lynn/subpubkey.html#catch22

however, in the past, I've also discussed leveraging the
"catch-22"
to implement a really lightweight SSL ... somewhat similar
proposal
mentioned here in old email from 1981
http://www.
garlic.com/~lynn/2006w.html#12 more secure communication
over the network

and a couple past posts discussing really lightweight SSL in
the 
context of the catch-22 scenario:
http://www
.garlic.com/~lynn/aadsm20.htm#43 Another entry in the
internet security hall of shame
http://www.
garlic.com/~lynn/aadsm22.htm#0 GP4.3 - Growth and Fraud
- Case #3 - Phishing
http://www.
garlic.com/~lynn/2006f.html#33 X.509 and ssh

So after the initial e-commerce activity ... there were some
number of
efforts in the mid-90s to improve the internet payment
technologies
...  two such activities were SET and X9A10. The financial
standards
X9A10 working group had been given the requirement to
preserve the
integrity of the financial infrastructure for all retail
payments (not
just internet) ...  resulting X9.59
http://www
.garlic.com/~lynn/x959.html#x959
http:
//www.garlic.com/~lynn/subpubkey.html#x959

I had gotten ahold of the SET specification when it was
first
available and did a crypto-op profile and calculated some
crypto-op
performance for typical SET transactions. Some number of
people
associated with SET claimed that my numbers were off by two
orders of
magnitude (too large by a factor of one hundred times) ...
however
when they eventually had running code ... my profile numbers
were
within a couple percent of the measured numbers. On an
otherwise idle
dedicated test infrastructure, a simple SET transaction was
over 30
seconds elapsed time ... nearly all of that crypto-op
processing.  In
a loaded infrastructure, contention and queueing delays
could stretch
that out to several minutes (or longer). Besides the
enormous 
processing bloat ... there was also a lot of protocol
chatter and
enormous payload bloat. misc. posts:
http
://www.garlic.com/~lynn/subpubkey.html#bloat

by comparison, X9.59 had to be a lightweight payload,
lightweight
processing, and fast transaction that was applicable to all
environments (not just the internet).

x9.59 went for lightweight payload transaction that could
complete in
a single transaction roundtrip, with strong end-to-end
security
(applicable whether the transaction was
"in-transit" or "at-rest").  It
effectively substituted end-to-end strong authentication and
strong
integrity for information hiding encryption. X9.59 also
eliminated 
knowledge of the account number as a fraud exploit
http://www.garlic.com/~lynn/subingetrity.html#harvest

and therefor eliminated the need for the most common use of
SSL for
hiding account numbers in e-commerce transactions (i.e. for
really
high performance and lightweight SSL is when you don't have
to do it
at all).

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com