Russian Apache Switch to English
Switch to Russian koi8-r
windows=1251
cp-866
iso8859-5
Russian Apache Как это работает Рекоммендации Где взять Как установить Как настроить Статус и поддержка
Краткий обзор FAQ Список рассылки Благодарности Поиск по серверу Powered by Russian Apache
Russian Apache mailing list archive (apache-rus@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[apache-talk] Fw: OpenSSL/SSLeay Security Alert (fwd)



Извините за настырность, но когда ожидается русский Апач с исправленным SSL?

Olga Scherbakova <olga@xxxxxxx>

>---------- Forwarded message ----------
>Date: Mon, 22 Mar 1999 19:42:49 +0000
>From: Ben Laurie <ben@xxxxxxxxxxxxx>
>To: BUGTRAQ@xxxxxxxxxxxx
>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
>(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
>

=============================================================================
=               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 ] [ Как это работает ] [ Рекомендации ] [ Где взять ] [ Как установить ] [ Как настроить ] [ Статус и поддержка ] [ Краткий обзор ] [ FAQ ] [ Список рассылки ] [ Благодарности ] [ Поиск по серверу ] [ Powered by Russian Apache ] [ Apache-talk archive ]

"Russian Apache" includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/) See Apache LICENSE.
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.