Извините за настырность, но когда ожидается русский Апач с исправленным SSL?
Olga Scherbakova <olga@xxxxxxx>
>---------- Forwarded message ----------
>Date: Mon, 22 Mar 1999 19:42:49 +0000
>From: Ben Laurie <ben@xxxxxxxxxxxxx>
>Subject: OpenSSL/SSLeay Security Alert
>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
>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.
>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
>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.
>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:
>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
>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.
>There are no known exploits of this security hole.
>Ben Laurie, for the OpenSSL team.
>"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
= Apache-Talk@xxxxxxxxxxxxx mailing list =
Mail "unsubscribe apache-talk" to majordomo@xxxxxxxxxxxxx if you want to quit.
= Archive avaliable at http://www.lexa.ru/apache-talk =
"Russian Apache" includes software developed
by the Apache Group for use in the Apache HTTP server project
Copyright (C) 1995-2001 The Apache Group. All rights reserved.
Copyright (C) 1996 Dm. Kryukov; Copyright (C)
1997-2009 Alex Tutubalin. Design (C) 1998 Max Smolev.