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 SSL_OP_CIPHER_SERVER_PREFERENCE or HAVE_SSL_X509V3_EXT_d2i (which are 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. Kaspar
