Patch info for blinding-4.x_bri
Patch info for blinding-4.x_bri
Creator | Brian Hatch |
---|
Patch to Version | 4.04 |
---|
Type | Bugfix |
---|
Patch | blinding-4.x_bri.patch |
---|
Status | Not needed if you have recent versions (later than 0.9.6j or 0.9.7b) of OpenSSL. Patch fixed on Apr 23, 2003, to not turn on blinding in client mode when no cert in use. |
---|
Description (Full Text) | Forces RSA blinding to prevent timing attacks which can determine an RSA private key.
|
---|
Author Comments
Any SSL connection that does not have RSA blinding turned on
can be abused through a "timing attack" which can reveal
the private RSA key. This RSA timing attack was proven to
be effective against Stunnel (and other SSL software) by
David Brumley and Dan Boneh. Their original announcement to
the Stunnel list is at the end of this document.
OpenSSL versions 0.9.6i and earlier, and 0.9.7a and earlier
did not enable RSA blinding by default. The next versions of
OpenSSL (0.9.6j and 0.9.7b) are expected to enable blinding
by default, with a compile-time option to disable this feature.
For those unable to upgrade OpenSSL currently, I provide
the following patch to Stunnel-4.04 that forces RSA blinding on
all RSA keys -- server, client (if using peer certificates)
and emphemeral keys (if temporary keys are used, for example
with exportable crypto).
This patch does not enable blinding if you are using a version
of OpenSSL greater than 0.9.7a. (0.9.7b has blinding on by default.
It unfortunately also has a memory leak. Hopefully 0.9.7c will
fix this.) It does not, however, differentiate between 0.9.6
variants - it will enable blinding for even non-vulnerable OpenSSL
versions of the 0.9.6 series.
If you compile your version of OpenSSL 0.9.7b or later with
blinding not automatically enabled (which is not the default)
it will not be enabled in Stunnel either for consistancy. I
do not expect anyone will be compiling OpenSSL 0.9.7b or later
without blinding on by default, so this should not be a problem.
Enabling RSA blinding has a negligible performance impact (2%
by some estimates) that is well worth the security of your
private RSA keys.
-----------------------------------------------------------------------
To: stunnel-users@mirt.net
Date: 13 Mar 2003 16:09:17 -0800
From: David Brumley <dbrumley@stanford.edu>
Subject: Timing attack against stunnel/OpenSSL
Dan Boneh and I have been researching timing attacks against software
crypto libraries. Timing attacks are usually used to attack weak
computing devices such as smartcards. We've successfully developed and
mounted timing attacks against software crypto libraries running on
general purpose PC's.
We found that we can recover an RSA secret from OpenSSL using anywhere
from only 300,000 to 1.4 million queries. We demonstrated our attack
was pratical by successfully launching an attack against Apache +
mod_SSL and stunnel on the local network. Our results show that timing
attacks are practical against widely-deploy servers running on the
network.
While OpenSSL definitely does provide for blinding, mod_SSL doesn't
appear to use it. One reason is it appears difficult to enable blinding
from the SSL API.
This paper was submitted to Usenix security 03. The link to the paper
is here:
http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html
We notified CERT about a month ago re: this attack, so it's possible you
heard about this from them already.
flames > /dev/null. Feel free to write with any questions.
Cheers,
-David Brumley
This website makes patches available for use by the
Internet community. However it does not endorse any of the patches
contained herein. They could be work perfectly, or totally foul up
everything. We don't know. Contact the authors if you have any
questions. Use at your own risk.
The Stunnel software package does not contain any
cryptography itself, however please remember that import and/or export of
cryptographic software, code providing hooks to cryptographic
algorithms, and discussion about cryptography is illegal in some countries.
It is imperative for you to know your local laws governing cryptography.
We're not liable for anything you do that violates your local laws.
|