On 11/04/2009 10:35 AM, Kaspar Brand wrote: > Kamesh Jayachandran wrote: >> Reasonable fix for this on the server side is to apply SSL_OP_NO_TICKET >> patch and enable SSLSessionCache. > > There is actually another reason why disabling TLS session tickets makes > sense at the present time: with OpenSSL's current stable version > (0.9.8k), session tickets only work properly for the first/default > vhost. For all other vhosts, mod_ssl will fail to decrypt a > previously-generated ticket, due to the order in which OpenSSL currently > deals with the SNI and ticket extensions (and their callbacks). The > consequence is that with 2.2.x and an SNI configuration, session caching > for clients supporting TLS tickets is not working for all but the first > vhost. > > The attached patch (for trunk, plus a backport for 2.2.x) includes two > proposed changes: > > 1) When configuring a new SSL context (in > ssl_engine_init.c:ssl_init_ctx_tls_extensions), it disables session > ticket support if a server-side session cache is configured. Enabling > both session tickets and a cache for stateful resumption at the same > time doesn't make that much sense anyway, IMO. This change will also > solve the issue with OpenSSL clients (as reported by Kamesh), provided > that a server-side cache is configured.
I guess your current patch fails on trunk since myModConfig(s))->nSessionCacheMode is no longer present in trunk > > 2) In the SNI callback, it adjusts OpenSSL's session id context - which > makes sure that the session can be properly resumed. (With the current > mod_ssl code, this context is always tied to the first vhost, possibly > resulting in incorrect resumption behavior.) Can you please elaborate in more detail why this shouldn't be done when we have done renegotiations so far? Regards Rüdiger
