Bug 44961 - SSL session resumption does not properly work with openssl > 0.9.8f
Summary: SSL session resumption does not properly work with openssl > 0.9.8f
Status: RESOLVED DUPLICATE of bug 47055
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.0-HEAD
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-09 02:50 UTC by keilh
Modified: 2011-07-15 10:41 UTC (History)
2 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description keilh 2008-05-09 02:50:33 UTC
In the method 'int ssl_hook_Access(request_rec *r)' the session id context will 
set again in case of a full renegotiation [1]. 
And since openssl/0.9.8f the context check of a SSL session has been restricted,
see [2].

That has the effect, that ssl session caching does not work, if the ssl session  
has been established by a full renegotiation. (unless a third party ssl session 
cache is used, that is correcting the session id context) 

I think the initial reason for changing the session id context was to avoid 
session resumption if a client cert is requested (SSL_VERIFY_PEER). 
But since the option SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION has been 
introduced, that is not longer necessary.

So it would propose the following change:

--- 617,627 ----
                           "Performing full renegotiation: "
                           "complete handshake protocol");

+ #ifndef SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION
              SSL_set_session_id_context(ssl,
                                         (unsigned char *)&id,
                                         sizeof(id));
+ #endif

              SSL_renegotiate(ssl);
              SSL_do_handshake(ssl);









[1] file ssl_engine_kernel.c line 620

request_rec *id = r->main ? r->main : r;

/* do a full renegotiation */
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r->server,
                         "Performing full renegotiation: "
                         "complete handshake protocol");
SSL_set_session_id_context(ssl,
                 (unsigned char *)&id,
                 sizeof(id));






[2] http://www.openssl.org/news/changelog.html

Changes between 0.9.8e and 0.9.8f  [11 Oct 2007]
...
...
*) 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 1 strodgers 2011-07-14 20:11:12 UTC
Is there anything that can be done to help get this some more attention?  The way HTTPD is currently assigning SSL session contexts during full renegotiation truly does appear to be broken.  This is preventing +OptRenegotiate (quick renegotiation) from working as designed and documented.  The customer base I support uses hardware-based client certificates which are noticeably slow when HTTPD forces full renegotiations for each object because of this bug.  There are workarounds that help, but this is an actual problem and a documented feature that is broken.

I started at bug #47055, and landed here.  I’ve applied each suggested patch along the way and this bug report explanation and patch seems to be the most elegant.  I’d be delighted to assist with testing in order to get an official fix signed off and committed.
Comment 2 Joe Orton 2011-07-15 10:41:19 UTC
Marking this as a dupe of 47055 since there is a more extensive analysis there and it's basically the same issue.

I've not seen anything to change my opinion at bug 47055 comment 39 but I would love to be convinced either way.  I'd also restate long-held truism:

-> design your sites to rely on per-location renegotiation at your own peril

If I was writing mod_ssl from scratch I would omit this misfeature entirely.

*** This bug has been marked as a duplicate of bug 47055 ***