Date: Wed, 4 Feb 2015 09:59:59 -0800 From: Reed Loden <reed@...dloden.com> To: oss-security@...ts.openwall.com Subject: Re: Apache 2.4 mod_ssl SSLSessionTickets -- others vulnerable? ... or you could do something like what Twitter did  and write your own scripts to generate new session ticket keys regularly and store them only in a tmpfs or /dev/shm type environment. agl also talks about this problem on his blog  a while ago. As for your earlier question, nginx has the same issue here . Really all comes down to OpenSSL not making it easy to do better. ~reed  https://blog.twitter.com/2013/forward-secrecy-at-twitter  https://www.imperialviolet.org/2013/06/27/botchingpfs.html  http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key On Wed, Feb 4, 2015 at 9:50 AM, Mark Felder <feld@...d.me> wrote: > > > 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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ