Ben Laurie schrieb:
>
> Bodo Moeller wrote:
> >
> > How are things in Apache-SSL with respect to the potential problem
> > discussed below?
>
> I don't believe it is necessary to take any action for various reasons.
> The most obvious is that if guessing session IDs gets you anywhere,
> you've got a far more serious problem than their accidental reuse across
> multiple vhosts!
>
> The other really obvious point is that a session ID is just a
> negotiation shortcut. Unless you know the symmetric key that goes with
> the session, the ID is no use to you.
>
> Session IDs themselves are large random numbers, to avoid the obvious
> mayhem should collisions occur.
>
> So, in short, the "potential problem" is, in fact, a non-problem.
To be more exact: Yes, the sessionID is a short cut and avoids
unnecessary PubKey operations. It is like a index into a table with
stored sessions. The session context there has f.i. the client cert
stored.
Wether this is a potential thread depends on where the client cert
is checked: (if not looked in the sources)
If the check is done within the handshake then there is no problem
(at least security wise: the client might not be able to present
another cert that is required since a session is reused. But since
it's another host no client should use this sessionID).
If the handshake is resumed and the verification is bypassed as
well (this means, the verify() for the client cert is not done)
then we have a problem: An attacker that has access to one host
can have access to the another virtual host!
The quick solution (at least for mod_ssl) is to use the flexible
Require directive to double check the situation.
The clean (and easy) solution at the openssl end is to add an
entry "ipaddr" to the SSL_SESSION struct and check this addr
when looking for the session in the cache.
> >
> > Ralf S. Engelschall (to the sw-mod-ssl mailing list):
> > > Bodo Moeller:
> >
> > >> mod_ssl's dbm session cache can be shared between virtual hosts (and I
> > >> think the example configuration does that). Question: Can this lead
> > >> to clients using the wrong session on one virtual host (thus possibly
> > >> bypassing client authorization, or using a session established with a
> > >> client certificate from a CA not accepted by the current server)?
> > >> If so (and that is my impression from reading the code, but I don't
> > >> have enough knowledge on the software's architecture), the manuals and
> > >> examples should contain appropriate warnings. Otherwise, the source
> > >> code should have comments saying why this can't happen.
> >
> > > Hmmm.... interesting questions. I've to think about this topic and
> > > check the code of OpenSSL and mod_ssl to be able to give a good
> > > answer. At least one thing is true: The SSL layer doesn't have any
> > > knowledge of the HTTP layer. But I've still no clue whether this
> > > (under your imagined situation) could actually lead to security
> > > problems for the server. Does anybody already know more on this
> > > topic and can give an answer?
> >
> > Bodo M"oller
> > <[EMAIL PROTECTED]>
>
> --
> 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
--
Holger Reif Tel.: +49 361 74707-0
SmartRing GmbH Fax.: +49 361 7470720
Europaplatz 5 [EMAIL PROTECTED]
D-99091 Erfurt WWW.SmartRing.de
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
