httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaspar Brand <>
Subject Re: [PATCH] mod_ssl: improving session caching for SNI configurations
Date Wed, 11 Nov 2009 08:05:48 GMT
Joe Orton wrote:
> 1) why do we need a new config directive for session ticket support?  
> I'm struggling to understand why any server admin would need/want 
> control over support for session tickets.

Session tickets are a relatively new thing (RFC 4507 is from May 2006),
and I'm not sure how well current TLS implementations interoperate with
each other. For situations like these, it seems desirable to me if the
admin can control this through a directive (it's not fundamentally
different form knobs like SSLHonorCipherOrder, SSLOptions
OptRenegotiate, SSLRenegBufferSize, and SSLStrictSNIVHostCheck, IMO).

> 2) I do not think we should be hacking around OpenSSL bugs as the code 
> for SSL_CTX_set_tlsext_ticket_keys() is.  People using buggy versions of 
> OpenSSL should upgrade to versions which are not buggy, if they are 
> affected.

OpenSSL versions 0.9.8f through 0.9.8l are probably going to stay around
for quite some time, so why not do these users a favor with a few
(conditionally compiled) lines? It could just be considered a special
case of OpenSSL "feature checking", like #ifdefs for
quite common in mod_ssl).

> At most here I'd do as your original patch does, to set the 
> SSL_OP_NO_TICKET flag if no session cache is enabled.  This is 
> sufficient to fix the issue in question, right?

My original patch disabled tickets only if a session cache *is*
configured (nSessionCacheMode != SSL_SCMODE_NONE), because in that case,
session tickets really make sense - there's no stateful cache, so leave
support for stateless resumption enabled.

Turning off ticket support when no cache is configured seems like a bad
idea to me - it will fix the issue for clients based on OpenSSL <=
0.9.8l, true, but at the cost of making it impossible to run mod_ssl
with stateless resumption only (which I think is a perfectly legitimate
use case).

> 3) The MD5 hash used in the session id context is just a hash.  It has 
> no cryptographic use AFAIK and MD5 is a perfectly fine hash, so I don't 
> see any need to change that.

Correct, the question is how likely a collision of two vhost_ids
(servername:port) is with MD5. Changing to SHA-1 for trunk shouldn't
hurt, however - and might obviate future questions as to why mod_ssl
(still) uses MD5 internally.


View raw message