For your information I forward the security announcement of the OpenSSL side of life also to this list. All you've to do is to rebuild with OpenSSL 0.9.2b. The final solution (with SSL_set_session_id_context() which enables the session cache again) will be provided with mod_ssl 2.2.6-1.3.5 or 2.2.6-1.3.6, dependent how long we need on the Apache side of life to finally kick out a new release these days (there are last minute problems, so be patient). Because mod_ssl is in the middle, I've to wait for both sides, and even I'm part of both sides, it's sometimes not easy to sync with both (currently I've prepared mod_ssl 2.2.6-1.3.5 for you but the chances are high that we skip the 1.3.5 version in Apache).... ;-) So, my advice: Just be patient a few more days until the Apache side settled a new release to which mod_ssl can sync or build your old server with just OpenSSL 0.9.2b in the meantime. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com -- forwarded message -- 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. -- end of forwarded message -- ______________________________________________________________________ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]