Date: Wed, 04 Feb 2015 11:50:30 -0600 From: Mark Felder <feld@...d.me> To: oss-security@...ts.openwall.com Subject: Re: Apache 2.4 mod_ssl SSLSessionTickets -- others vulnerable? On Wed, Feb 4, 2015, at 10:55, Florent Daigniere wrote: > On Wed, 2015-02-04 at 10:35 -0600, Mark Felder wrote: > > From the 2.4.12 changelog: > > > > > > *) mod_ssl: New directive SSLSessionTickets (On|Off). > > The directive controls the use of TLS session tickets (RFC 5077), > > default value is "On" (unchanged behavior). > > Session ticket creation uses a random key created during web > > server startup and recreated during restarts. No other key > > recreation mechanism is available currently. Therefore using > > session > > tickets without restarting the web server with an appropriate > > frequency > > (e.g. daily) compromises perfect forward secrecy. [Rainer Jung] > > > > > > So if you use Apache 2.4 and care about PFS protecting your data, you > > should turn this feature off. This appears to be an implementation issue > > because there is no other way for Apache to recreate keys. I don't know > > a lot about the fine details of Session Tickets, but can anyone care to > > comment if there are other known bad implementations of session tickets > > out there? Does this affect Apache 2.2? Nginx? Lighttpd? > > > > > > Thanks > > I find this bizarre that a known security weakness like this is left > > "on" by default... > > You're right, it's "bizarre" > > I've tried to make some noise about it two years ago  ... > > IMHO it's OpenSSL's default that should be changed. The server > implementation shouldn't give a ticket if it's picked a PFS enabled > cipher (or a cipher which aims at providing better security than > AES128-CBC) unless explicitly told to do so (the case where there is > more than one server). > > Apache HTTPd's new setting (SSLSessionTicketKeyFile), allowing you to > set the ticket key is *DANGEROUS* as documented . It encourages users > explicitly to store the key on a forensically carvable medium... > "The ticket key file contains sensitive keying material and should be > protected with file permissions similar to those used for > SSLCertificateKeyFile." > Which is exactly what you shouldn't do! > Thanks for the details, Florent. After reviewing this blog post  it's much clearer now, but I'm still a bit fuzzy on if "session caching" and "session IDs" (RFC 5246, TLS 1.2) -- also as identified by Qualys SSLLabs line item "Session resumption (caching)" -- are the same; is the Session Cache caching session IDs? I only ask because I know that webservers have had SSL Session Cache features for years, but RFC 5246 is TLS 1.2 in its entirety and I believe I've seen this feature predate TLS 1.2. Was session caching / IDs always part of the SSL/TLS spec, now superseded by the newer TLS 1.2 RFC? If I'm understanding that correctly the following would be true: the use of session caching is not a known vulnerability, but the use of session tickets is a potential vulnerability. The design of the session tickets (RFC 5077) appears to solve a specific problem: reducing expensive TLS renegotiation when you have a cluster of servers and the session is not guaranteed to stick to a specific server/load balancer. Additionally OpenSSL lacks key rotation for session tickets, so it seems safe to assume all software using OpenSSL with session tickets enabled are likely not working around this problem by enforcing their own key rotation. This feels like a feature that should always be turned off unless your environment absolutely requires it; especially if you have measurable performance impact / negative client experience without it.  http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.