Holger Reif wrote:
>
> 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).
You can only present another cert by renegotiating, which, by
definition, is not the same session.
> 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!
Hmmm. Yes, this is an interesting problem. BTW, the verify for the
client cert _can't_ be done, because SSLeay/OpenSSL doesn't keep them!
This is a bug that I work around rather painfully in Apache-SSL, but not
to the extent of revalidating the cert.
> 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.
That's only half a solution, though - it assumes that the sole
distinguisher is the IP address, which is only true for limited cases.
Cheers,
Ben.
--
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
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
