OpenSSL and SSLeay Security Alert
---------------------------------
It was recently realised that packages that use SSLeay and OpenSSL may
suffer from a security problem: under some circumstances, SSL sessions
can be reused in a different context from their original one. This may
allow access controls based on client certificates to be bypassed.
Unfortunately, before the the problem was fully understood, it was
discussed on various public lists. The OpenSSL team have therefore
decided to release an interim version of OpenSSL which addresses the
problem by disabling session reuse except in limited circumstances
(see below).
A future version will deal with the problem more elegantly by redoing
verification on reused sessions when necessary.
Although this problem is not strictly a defect in OpenSSL, it is
rather tricky for applications to be coded correctly to avoid the
problem due to the sketchy nature of SSLeay/OpenSSL documentation. We
therefore decided to protect applications from within OpenSSL.
The problem
-----------
SSL sessions include a session ID which allows initial setup to be
bypassed once a session has been established between a client and
server. This session ID, when presented by the client, causes the same
master key to be used as was used on the previous connection, thus
saving considerable session setup time.
When the session is reused in this manner, all access controls based
on client certificates are bypassed, on the grounds that the original
session would have made the necessary checks.
Unfortunately, the lack of documentation has resulted in the caching
structures being used in certain applications without appropriate care
being taken to assure that the cached sessions are only available at
the appropriate moments.
As a result it is sometimes possible for a specially written SSL
client to fraudulently obtain an SSL connection which requires access
control by reusing a previous session which had different or no access
control.
The problem affects servers which support session reuse and which have
multiple virtual hosts served from a single server, where some virtual
hosts use differing client server verifications. Note that "different"
includes no verification on some hosts, and verification on others, or
different CAs for different hosts.
In order to exploit this problem carefully written client software
would need to be written. The attacker would need considerable
knowledge of the SSL protocol. Standard web browsers will not and
cannot be made to use SSL in this way.
Affected software
-----------------
All server software using SSLeay or versions of OpenSSL prior to
version 0.9.2b that support multiple virtual hosts with different
client certificate verification may be vulnerable.
This includes, but is not limited to:
Apache-SSL http://www.apache-ssl.org/
mod_ssl http://www.engelschall.com/sw/mod_ssl/
Raven http://www.covalent.net/
Stronghold http://www.c2.net/
The solution
------------
Download OpenSSL 0.9.2b (see http://www.openssl.org) and build it in
the usual way.
Check the application for updates, and download those, too (NB: this
step is not necessarily required, the updated library will fix the
problem). The versions of the applications listed above that you should
use are:
Apache_SSL 1.3.4+1.32
mod_ssl 2.2.6-1.3.4
Raven 1.4.0
Stronghold 2.4.2
Rebuild the application (if needed).
If you are an application author, you should look in to the use of
SSL_set_session_id_context(), which can be used to reenable session
reuse when appropriate.
Known exploits
--------------
There are no known exploits of this security hole.
Ben Laurie, for the OpenSSL team.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:39:26 PDT