httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 47055] SSLVerifyClient + Directory doesn't use cache sessions
Date Fri, 25 Sep 2009 08:30:02 GMT

--- Comment #38 from rm4dillo <> 2009-09-25 01:29:53 PDT ---
Sorry, I did not see your first question.

In fact, the session id is correct and the problem is in the session id
In mod_ssl the session id context should be set once in
"mod_ssl.c:ssl_init_ssl_connection" function and it's value is the md5 hash of
the virtual_host id.

The problem is that at the first connection of the user, when we perform a full
renegotiation the function "ssl_engine_kernel.c:ssl_hook_Access" sets the
session id context to an invalid value which is "(unsigned char *)&id" where
"id" is a "request_req *" before storing the session id in the context.

So at the next connection of the user, mod_ssl never finds the session id in
the cache because it uses the session id context set in
"mod_ssl.c:ssl_init_ssl_connection" which is valid but the session id is not
stored there. It's stored using the "request_req *" context which we'll never
find again.

mod_ssl keeps storing session ids in a different context for each request but
it never finds them again. The patch solves this by removing the call to
"SSL_set_session_id_context" in "ssl_engine_kernel.c". That solves the problem
and no side effects have been detected.

If that doesn't answer your question, don't hesitate.

Thank you for your response though

(In reply to comment #37)
> I had raised a question which was never answered, that's a first good step in
> getting a patch committed at all.
> Secondly, you need to pass the trunk gauntlet, get it committed to the dev
> branch.  I'm not willing to do this because I'm still unclear why it has
> handshaked the wrong session if the client produced the right session ID,
> is it because the server at the root level refuses to accept the client
> certificate at all, resulting in a new session?
> Finally, once a patch is on trunk, three devs need to agree to move it to
> the stable branch, where it would appear in the next httpd 2.2 release.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message