Bug 47055 - SSLVerifyClient + Directory doesn't use cache sessions
Summary: SSLVerifyClient + Directory doesn't use cache sessions
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.2.13
Hardware: All All
: P1 blocker with 7 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate, PatchAvailable
: 44858 44961 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-04-20 05:10 UTC by Mike
Modified: 2018-11-07 21:08 UTC (History)
10 users (show)



Attachments
enable funny debug (2.11 KB, patch)
2009-05-18 08:08 UTC, Mike
Details | Diff
patch (1.25 KB, patch)
2009-05-19 06:19 UTC, Mike
Details | Diff
patch (1.30 KB, patch)
2009-05-20 00:22 UTC, Mike
Details | Diff
Light patch (333 bytes, patch)
2009-09-09 06:14 UTC, rm4dillo
Details | Diff
Light Patch (671 bytes, patch)
2009-09-09 06:58 UTC, rm4dillo
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mike 2009-04-20 05:10:21 UTC
1. Simple httpd.conf:

LoadModule ssl_module modules/mod_ssl.so
<skip>
SSLRandomSeed startup file:/dev/urandom 512
SSLRandomSeed connect file:/dev/urandom 512
SSLSessionCache shmcb:log/ssl_scache(512000)
SSLMutex default 
<skip>
<VirtualHost 172.25.16.86:8443>
    ServerAdmin kuku@parks.lv
    ServerName redhat1-mp.parks.lv
    DocumentRoot "/mihailp1/www-secure"

    SSLEngine on
    SSLCertificateKeyFile "/root/redhat1-mp-ca/redhat1-mp.key"
    SSLCertificateFile  "/root/redhat1-mp-ca/redhat1-mp.crt"
    SSLCACertificateFile "/root/redhat1-mp-ca/redhat1-mp-ca.crt"
    
    <Directory /mihailp1/www-secure/s>
    SSLVerifyDepth 3
    SSLVerifyClient require
    SSLOptions +OptRenegotiate
    </Directory>

    ErrorLog  "logs/secure-error_log"
    CustomLog "logs/secure-access_log" common
</VirtualHost>

2. Simple user's auth, cert imported to browser.
3. If i access url: https://redhat1-mp.parks.lv:8443/s/test.txt
browser opens pop-window to select which cert to use.

The problem is browser opens pop-windows for every request, it doesn't use cache. So, i see only SET requests:
[Mon Apr 20 14:59:36 2009] [debug] ssl_engine_kernel.c(1598): Inter-Process Session Cache: request=SET status=OK id=DA696786BAFAD9ED6DF78942C7B98C3771A4614DF693ED9DF7EB10B619419ABC timeout=299s (session caching)

The problem appear from openssl.0.9.8f, there is the CHANGELOG:
  *) In the SSL/TLS server implementation, be strict about session ID
     context matching (which matters if an application uses a single
     external cache for different purposes).  Previously,
     out-of-context reuse was forbidden only if SSL_VERIFY_PEER was
     set.  This did ensure strict client verification, but meant that,
     with applications using a single external cache for quite
     different requirements, clients could circumvent ciphersuite
     restrictions for a given session ID context by starting a session
     in a different context.
     [Bodo Moeller]

4. Check the diff between 0.9.8e and 0.9.8f for ssl_sess.c:ssl_get_prev_session(). If i copy this function from 0.9.8e version apache works as before.

5. It doesn't use SSL_CTX_set_session_id_context() in ssl_engine_init.c:ssl_init_ctx_session_cache(), but it didn't help.

6. I have setuped test environment and can easily test and patch set.
Comment 1 Mike 2009-04-20 05:19:28 UTC
it fails at SSL_get_peer_certificate() from ssl_engine_kernel.c

[Thu Apr 16 11:12:02 2009] [debug] ssl_engine_kernel.c(426): Changed client verification type will force renegotiation
[Thu Apr 16 11:12:02 2009] [info] Requesting connection re-negotiation
[Thu Apr 16 11:12:02 2009] [debug] ssl_engine_kernel.c(616): Performing full renegotiation: complete handshake protocol
<skip>
[Thu Apr 16 11:12:02 2009] [info] Awaiting re-negotiation handshake 


but if i compile apache with openssl.0.9.8e it works as expected:
[Thu Apr 16 11:48:40 2009] [debug] ssl_engine_kernel.c(426): Changed client verification type will force quick renegotiation
[Thu Apr 16 11:48:40 2009] [info] Requesting connection re-negotiation
[Thu Apr 16 11:48:40 2009] [debug] ssl_engine_kernel.c(549): Performing quick renegotiation: just re-verifying the peer
[Thu Apr 16 11:48:45 2009] [debug] ssl_engine_kernel.c(1770): OpenSSL: Write: SSL negotiation finished successfully
Comment 2 Mike 2009-04-20 05:56:52 UTC
Browser: FF 3.0.8.
1. FF3.0.x has 'Ask me every time' by default (Tools -> Options -> Advanced -> Encryption), that's pop-up window is the issue here.
2. IE8 automatic by default - no problem.
Comment 3 Mike 2009-05-15 06:45:36 UTC
How much costs the fix ?
Comment 4 Joe Orton 2009-05-17 02:27:50 UTC
It's not clear to me why this would fail.  mod_ssl calls SSL_set_session_id_context() to set the "session id context" for every new SSL * object, so this looks correct.

It would be useful if you could put some extra debugging in your OpenSSL 0.9.8f build, to help track this down:

fprintf(stderr, "CACHE MISS %u %u\n", 
   ret->sid_ctx_length, s->sid_ctx_length);

before the:

                goto err; /* treat like cache miss */

line - I'm presuming that is the branch being taken, otherwise you'd be seeing an error.  If that doesn't help, start sprinkling fprintf's around until you find the branch that is failing.

(If you need a specific patch to apply, let me know.)
Comment 5 Mike 2009-05-17 22:22:14 UTC
Thank you, i will reply ASAP.
Comment 6 Mike 2009-05-18 01:47:31 UTC
I can repeat it under RHEL5 too.
I tried write service request (1912050) but declined.
Comment 7 Mike 2009-05-18 02:11:30 UTC
I don't see the output from openssl.
i've put hello word in always execute branch.
Comment 8 Mike 2009-05-18 07:09:08 UTC
oops, i see the output :)
fflush() helps.
Comment 9 Mike 2009-05-18 08:08:24 UTC
Created attachment 23683 [details]
enable funny debug

this patch enable debug output. see description
Comment 10 Mike 2009-05-18 08:11:48 UTC
Apply the patch for openssl 0.9.8k (latest)

First scenario, get file from virtual host:
CACHE ret-len: 32, s-len: 32
CACHE ret-str: 529a40abf407766626d15b85c1627a5f,
      s-str: 529a40abf407766626d15b85c1627a5f
3
4
5
7

Second scenario, get file from LocationMatch:
Config related part
<LocationMatch ^/nike(.*)>
        SSLVerifyClient require 
        SSLVerifyDepth 3
        SSLOptions +OptRenegotiate
</LocationMatch>

CACHE ret-len: 4, s-len: 32
CACHE ret-str: <4-byte-mess>, s-str: 529a40abf407766626d15b85c1627a5f
1
8
10
Comment 11 Mike 2009-05-18 08:18:44 UTC
Important, if i copy IF part from openssl 0.9.8e i see:
No warning:

CACHE ret-len: 4, s-len: 32
CACHE ret-str: <17-byte-mess>, s-str: 529a40abf407766626d15b85c1627a5f
3
4
5
7

it doesn't execute code inside IF that's why it works under 0.9.8e
Comment 12 Mike 2009-05-19 02:34:34 UTC
As you can see len and context corrupted between step 10 and 11:

[Tue May 19 12:30:29 2009] [debug] ssl_engine_kernel.c(620): Performing full renegotiation: complete handshake protocol
[Tue May 19 12:30:29 2009] [error] ssl_hook_Access-reneg 10: ssl-len: 32, ssl-str: 529a40abf407766626d15b85c1627a5f \x92\x8f\t\n
[Tue May 19 12:30:29 2009] [error] ssl_hook_Access-reneg 11: ssl-len: 4, ssl-str: 0\t\x8e\t40abf407766626d15b85c1627a5f \x92\x8f\t\n

Let's see the source:

ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server,
  "ssl_hook_Access-reneg 10: ssl-len: %u, ssl-str: %s\n" ,
  ssl->sid_ctx_length, ssl->sid_ctx);

SSL_set_session_id_context(ssl, 
  (unsigned char *)&id, sizeof(id));
                
ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server,
  "ssl_hook_Access-reneg 11: ssl-len: %u, ssl-str: %s\n" ,
  ssl->sid_ctx_length, ssl->sid_ctx);

"id" is not md5 of host - 529a40abf407766626d15b85c1627a5f
Thats why you can see this above:
CACHE ret-len: 4, s-len: 32
CACHE ret-str: <4-byte-mess>, s-str: 529a40abf407766626d15b85c1627a5f
1
8
10
Comment 13 Mike 2009-05-19 05:11:00 UTC
fix for wrong sid_ctx doesn't help.
the core of the issue is here:

if ((dc->nOptions & SSL_OPT_OPTRENEGOTIATE) &&
    (verify_old == SSL_VERIFY_NONE) &&
    ((peercert = SSL_get_peer_certificate(ssl)) != NULL))
   {
        renegotiate_quick = TRUE;
        X509_free(peercert);
   }

SSL_get_peer_certificate() returns NULL and renegotiate_quick doesn't set TRUE
and apache doesn't do *quick* renegotiation and client auth.


keep having fun...
Comment 14 Mike 2009-05-19 05:38:47 UTC
config contained wrong "SSLOptions -OptRenegotiate" that's why i was failed.
now i have a workaround for the bug.

problem is here. there is should be md5 string:
SSL_set_session_id_context(ssl, (unsigned char *)&id, sizeof(id));

like here:
if (!SSL_set_session_id_context(ssl, (unsigned char *)vhost_md5,
                                    APR_MD5_DIGESTSIZE*2))
    {
        ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c,
                      "Unable to set session id context to `%s'", vhost_md5);
        ssl_log_ssl_error(APLOG_MARK, APLOG_ERR, c->base_server);

        c->aborted = 1;

        return DECLINED; /* XXX */
    }

with workaround compare is always true and quick renegotiation always works.
if (ret->sid_ctx_length != s->sid_ctx_length
    || memcmp(ret->sid_ctx,s->sid_ctx,ret->sid_ctx_length))
	{
	goto err; /* treat like cache miss */
	}
Comment 15 Mike 2009-05-19 06:19:47 UTC
Created attachment 23689 [details]
patch
Comment 16 Mike 2009-05-20 00:22:25 UTC
Created attachment 23697 [details]
patch
Comment 17 Joe Orton 2009-05-20 02:49:26 UTC
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.
Comment 18 Joe Orton 2009-05-20 02:52:40 UTC
Sorry md5(request rec *) should simply read "request_rec *" i.e. a 4-byte sid context corresponding to the value of the pointer, per the existing code touched by your patch.
Comment 19 Mike 2009-05-20 03:17:50 UTC
Now, I want mention the history of the problem.
*Every* person in Estonia must have chip smartcard.
*Every* bank which works in Estonia market must implement integration between Internet banking and smartcards. Smartcard protected by PIN. Smartcard contain user's SSL cert. (sk.ee, id.ee)

Now supported two browsers: IE and FF. Every user have a smartcard reader.
User enter PIN, select the cert from the list for authorization and login to internet banking system. 

Now,
1. In FF2x user browse without popup windows with list of certs.
2. In FF3x user get popup window after *every* click, its boring and wrong.
3. IE works without popups.

Current workaround in FF3.0.x is select 'Select one automatically' in (Tools -> Options -> Advanced -> Encryption). This is not acceptable in practise.

Every admin in every bank in estonia have a headache to implement user's auth in <Location> or <Directory> not in the *whole* of the site.
Comment 20 Mike 2009-05-20 05:48:48 UTC
My scenario is trivial.
It's already known (no words about limitations) - 
http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html#arbitraryclients
Comment 21 Mike 2009-05-20 05:54:16 UTC
Joe:
1. I press F5 in FF3.0.x i see popup window only *once* with my patch, it will popup again after session expiration. 
2. You understand right the analisys.
3. I'm waiting for noise from somebody who understand the staff.
Comment 22 Joe Orton 2009-05-20 06:03:15 UTC
The fact that newer versions of Firefox do not remember client-cert/URL associations is a Firefox problem, which I understand they do plan to fix.

I will look into this in some more detail but please do appreciate that if mod_ssl cannot securely reuse cached sessions in this case, then this is expected behaviour and the correct fix is on the Firefox side.
Comment 23 Mike 2009-05-20 06:06:49 UTC
(In reply to comment #22)
> The fact that newer versions of Firefox do not remember client-cert/URL
> associations is a Firefox problem, which I understand they do plan to fix.
> 
how you know ? :/
Comment 24 Joe Orton 2009-05-20 06:12:32 UTC
OK, "acknowledge the need for improvement" would be better wording than "plan to fix".  The bug covering this is here:

https://bugzilla.mozilla.org/show_bug.cgi?id=32010
Comment 25 Joe Orton 2009-06-02 03:06:20 UTC
*** Bug 44858 has been marked as a duplicate of this bug. ***
Comment 26 juan-manuel.perez 2009-06-24 23:57:57 UTC
[About Bug 44858 marked as duplicated of this one]
This patch solves, indeed, the problem we reported. We have only these
comments:
- It worked properly only after adding the +OptRenegotiate option. Thus, we
  finally have this configuration (only relevant piece shown):
        SSLVerifyClient none
        <Location "/test">
          SSLVerifyClient require
          SSLVerifyDepth  10
          SSLOptions +OptRenegotiate
        </Location>
- There is only a little 'misbehaviour' we have found. If, after starting
apache, and firefox 3 (with clean cache), we first access 'https://localhost'
(which doesn't require client cert), and then we access 'https://test/', we are
prompted for the client certificate twice (this is the 'misbehaviour'). From
then onwards, we are not prompted any more (perfect!) Also, if we first access
'https://test/', we are prompted only once (perfect!).

I have only one more question. When is planned this patch to be included in an
official Apache release?
Comment 27 Mike 2009-06-29 06:58:32 UTC
I have had to insert "SetEnv nokeepalive" inside <LocationMatch> tag.
Without setenv staff i can still popup window in FF even with my patch.
Comment 28 rm4dillo 2009-09-09 04:38:59 UTC
Hi everybody,

Does anyone know if Mike's patch is going to be applied?
I've been experiencing the same bug because the context id is the memory address of "request_rec->id" which is different for each request. Is there any reason to use this "hacky" id, instead of a vhost id hash like in "ssl_init_ssl_connection()"?

Thanks in advance.
Comment 29 William A. Rowe Jr. 2009-09-09 05:23:32 UTC
Just for fun, would you try; 

        SSLVerifyClient optional
        SSLVerifyDepth  10

        <Location "/test">
          SSLVerifyClient require
          SSLVerifyDepth  10
          SSLOptions +OptRenegotiate
        </Location>

The first line ensures that the client-certificate accepted session will be
honored when the user navigates from /test, to say, /data and back again,
or when they start a new request that hasn't resolved to /test.

I'm a bit confused why the same session would not be reused until the session
expires, irrespective of the URL-path.  So I'm concerned that httpd may be 
handshaking, refusing their certificate, and renegotating for the session with
the certificate immediately afterwards.  This would be suboptimal.
Comment 30 rm4dillo 2009-09-09 06:14:34 UTC
Created attachment 24236 [details]
Light patch
Comment 31 rm4dillo 2009-09-09 06:20:53 UTC
Comment on attachment 24236 [details]
Light patch

SSL session id context is already correctly initialized in "mod_ssl.c:ssl_init_ssl_connection()". Hence, it is not useful to reset this session id context and we should keep the first one.

This is the reason why I came up with this patch.

I'll be thankful if you could apply this patch to the 2.2.14 release.
Thanks.

P.S.: Mike, does this patch work for you too?
Comment 32 Mike 2009-09-09 06:23:18 UTC
rm4dillo: Thank you the new version of patch.
I need more time to check it, i will try this week.
Comment 33 rm4dillo 2009-09-09 06:58:00 UTC
Created attachment 24237 [details]
Light Patch

Sorry, my first patch was not in unified format. It should be better now.
Comment 34 Mike 2009-09-10 01:08:42 UTC
rm4dillo: Your patch works for me.
Comment 35 rm4dillo 2009-09-10 01:11:50 UTC
(In reply to comment #34)
> rm4dillo: Your patch works for me.

Perfect!!!
Thanks for testing.
Comment 36 rm4dillo 2009-09-21 08:47:11 UTC
Hi all,

Is there anything I can do so this patch can be part of the next httpd release?

Thank you in advance.
Comment 37 William A. Rowe Jr. 2009-09-24 21:54:44 UTC
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.
Comment 38 rm4dillo 2009-09-25 01:29:53 UTC
Sorry, I did not see your first question.

In fact, the session id is correct and the problem is in the session id context.
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.
Comment 39 Joe Orton 2009-09-28 10:53:42 UTC
Let me restate my earlier comment: I think it must be true that either all the calls to SSL_set_session_id_context in mod_ssl are unnecessary, or, removing any of them is a security issue.  i.e. the proposed patch is either incomplete or insecure.

I would presume it is insecure until proved otherwise.  The session id context stuff is there to prevent a session in one security context (vhost, location context) being resumed in a different one.  Note that the mod_ssl ACL hooks may not occur after a session resumption since a client can initiate a ChangeCipherSpec independently of the what's happening in the app_data layer.
Comment 40 rm4dillo 2009-10-11 08:24:17 UTC
(In reply to comment #39)
> Let me restate my earlier comment: I think it must be true that either all the
> calls to SSL_set_session_id_context in mod_ssl are unnecessary, or, removing
> any of them is a security issue.  i.e. the proposed patch is either incomplete
> or insecure.
> 
> I would presume it is insecure until proved otherwise.  The session id context
> stuff is there to prevent a session in one security context (vhost, location
> context) being resumed in a different one.  Note that the mod_ssl ACL hooks may
> not occur after a session resumption since a client can initiate a
> ChangeCipherSpec independently of the what's happening in the app_data layer.

Hello, sorry for answering so late.

For the first part, maybe you're right and then we should use Mike's patch.
I don't have a deep knowledge of mod_ssl but I don't totally agree with you about the ACL hooks issue as for a particular request we keep using the same context as the context id is the request structure address and quick renegotiation has nothing to do with this. In addition to this "modssl_set_verify" is called in "ssl_hook_Access" so even if a resumption happens the verification will still be done, so what's the security issue if a ChangeCipherSpec happens?
Comment 41 Mike 2009-11-09 08:00:48 UTC
Joe, does config from first comment is vulnerabile to CVE-2009-3555?
Any comments?

p.s. Just started reading related links.
Comment 42 Ruediger Pluem 2009-11-09 08:28:23 UTC
(In reply to comment #41)
> Joe, does config from first comment is vulnerabile to CVE-2009-3555?

Yes it is. Even with the patch applied. You can only "fix" it with openssl 0.9.8l, but as soon as you use 0.9.8l this config will stop working at all.
Comment 43 Mike 2009-11-09 08:56:47 UTC
Ruediger, 

1. does the config still vulnerable if user redirects to "/mihailp1/www-secure/s" only after double authentication by soft (password-pin)?
2. why *this* config vulnerable if i disable renegotiation initiated by client?

Thank you.
Comment 44 Ruediger Pluem 2009-11-09 11:45:37 UTC
(In reply to comment #43)
> Ruediger, 
> 
> 1. does the config still vulnerable if user redirects to
> "/mihailp1/www-secure/s" only after double authentication by soft
> (password-pin)?

Yes. 

> 2. why *this* config vulnerable if i disable renegotiation initiated by client?

Server triggered renegotiations have the same problems as client triggered renegotiations. The only difference is that the MIM needs to know a request a URL from the server that triggers server triggered renegotiation in contrast to the client driven renegotiation where the client can decide this at will.
The only way to make your configuration safe is to move

    SSLVerifyDepth 3
    SSLVerifyClient require
    SSLOptions +OptRenegotiate

on the virtual host level and thus protect the whole virtual host.

For more details see:

http://extendedsubset.com/Renegotiating_TLS.pdf
http://extendedsubset.com/Renegotiating_TLS_pd.pdf
Comment 45 Mike 2009-11-09 12:16:31 UTC
Ruediger, thank you for reply.
Comment 46 Roger Waldner 2009-12-15 02:10:25 UTC
Hi,

we just ran into exactly the same problem. More analysis revealed that the impacts from this change ("be strict about session ID context matching") are stronger than anybody thought:

a) performance: The performance of the server may suffer because every access to a client cert protected directory now forces a full renegotiation without resuming the session

b) user annoyance: Users of browsers who cannot use a checkbox in the sense of "remember chosen certificate" are plagued with popups to confirm with the correct client cert

c) change of SSL session ID: applications relying on the SSL session ID now are constantly faced with changing SSL session ids.

Can anybody explain (eg. with an example) why this session ID context matching is now needed?

Thanks
  Roger
Comment 47 Joe Orton 2009-12-16 12:36:07 UTC
Nothing has changed in mod_ssl on this front.  It may be that the following change in OpenSSL 0.9.8f is shaking problems out of the woodwork here:

  *) In the SSL/TLS server implementation, be strict about session ID
     context matching (which matters if an application uses a single
     external cache for different purposes).  Previously,
     out-of-context reuse was forbidden only if SSL_VERIFY_PEER was
     set.  This did ensure strict client verification, but meant that,
     with applications using a single external cache for quite
     different requirements, clients could circumvent ciphersuite
     restrictions for a given session ID context by starting a session
     in a different context.
     [Bodo Moeller]
Comment 48 Roger Waldner 2009-12-16 23:02:09 UTC
Well, yes this could be the source of the problem.

OTH, my impression was that "Apache" (sorry I can't be more specific but I guess it is mod_ssl) defines what a "context" is and therefore uses this OpenSSL functionality.

In our tests it showed that entering or leaving (with a HTTPS request) a <Location> which requires client certificates, results in a new SSL session, enforced by the server.

BTW: Chasing this behaviour of getting a new SSL session ID revealed that Apache up to and including 2.2.11 did not have this behaviour and Apache versions from 2.2.12 onwards behave as written above.
Comment 49 Ruediger Pluem 2009-12-17 00:45:48 UTC
(In reply to comment #48)

> 
> BTW: Chasing this behaviour of getting a new SSL session ID revealed that
> Apache up to and including 2.2.11 did not have this behaviour and Apache
> versions from 2.2.12 onwards behave as written above.

Sounds like it has something to do with SNI support introduced in 2.2.12
Comment 50 Nikhil Kohli 2010-02-14 11:56:32 UTC
I think the problem here is introduced due the OpenSSL changes from 0.9.8e to 0.9.8f. Also, the below link describes the same problem in some more depth.

https://issues.apache.org/bugzilla/show_bug.cgi?id=44961

Since there is option for ssl session resumption from 0.9.8f onwards, won't it be better to commit the proposed patch to Apache?
Comment 51 Joe Orton 2011-07-15 10:41:19 UTC
*** Bug 44961 has been marked as a duplicate of this bug. ***
Comment 52 Gang Kessy 2016-08-29 19:47:08 UTC
Comment on attachment 24237 [details]
Light Patch

>--- modules/ssl/ssl_engine_kernel.c.orig
>+++ modules/ssl/ssl_engine_kernel.c
>@@ -718,17 +718,11 @@
>             }
>         }
>         else {
>-            request_rec *id = r->main ? r->main : r;
>-
>             /* do a full renegotiation */
>             ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
>                           "Performing full renegotiation: "
>                           "complete handshake protocol");
>
>-            SSL_set_session_id_context(ssl,
>-                                       (unsigned char *)&id,
>-                                       sizeof(id));
>-
>             SSL_renegotiate(ssl);
>             SSL_do_handshake(ssl);
Comment 53 Techiq 2018-05-08 00:03:29 UTC
Comment on attachment 24237 [details]
Light Patch

>--- modules/ssl/ssl_engine_kernel.c.orig
>+++ modules/ssl/ssl_engine_kernel.c
>@@ -718,17 +718,11 @@
>             }
>         }
>         else {
>-            request_rec *id = r->main ? r->main : r;
>-
>             /* do a full renegotiation */
>             ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
>                           "Performing full renegotiation: "
>                           "complete handshake protocol");

>
>-            SSL_set_session_id_context(ssl,
>-                                       (unsigned char *)&id,
>-                                       sizeof(id));
>-
>             SSL_renegotiate(ssl);
>             SSL_do_handshake(ssl);
Comment 54 William A. Rowe Jr. 2018-11-07 21:08:35 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.