https://issues.apache.org/bugzilla/show_bug.cgi?id=47055
--- Comment #17 from Joe Orton <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
