httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 47055] SSLVerifyClient + Directory doesn't use cache sessions
Date Wed, 20 May 2009 09:49:31 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=47055





--- Comment #17 from Joe Orton <jorton@redhat.com>  2009-05-20 02:49:26 PST ---
Hmmmm, very interesting, nice investigative work Mike, thanks a lot for looking
into this in such detail.

I expect the intent of the code in ssl_engine_kernel.c that your patch changes
is deliberate - to create a unique "context id" for the directory, such that it
cannot be resumed in a different context.  (similar to the intent of using the
vhost id to constrain the session to a specific vhost)

I'm just trying to understand the debug output you've posted - 

for the two tests you ran, are you restarting the browser or otherwise ensuring
a fresh session is used by the client each time?

in this case:

CACHE ret-len: 4, s-len: 32
CACHE ret-str: <4-byte-mess>, s-str: 529a40abf407766626d15b85c1627a5f
1
8
10

if I am reading this right, what is happening is:

1) the "session id context" for the SSL * object has been set to the
md5(vhost-id) string at the time of this code being invoked

2) the client has asked to resume a session with some id

3) that id is looked up in the session cache, and the session is found

4) this cached session has an "id context" of the md5(request_rec *) for the
location pointer; i.e. it is a session previously used for the per-dir
renegotation

5) hence, the code falls through the cache-miss path because of the mismatch
between expected "sid context" and the cached session's "sid context"

Do you agree with that analysis? 

I think that is expected if this is initial handshake for a new connection to
that vhost.  i.e. we are the point before the GET request is processed and the
second handshake is required for the configured per-dir access control stuff.

I haven't got my head round the security impact of the sid context mismatches,
so I'm not at all sure whether or not your patch is going to open up a security
issue.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message