[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALPTtNX4yFvjTY0jHGEGfMA8RK5LUCfu+MsJPFmt6WrHAbEa6g@mail.gmail.com>
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 [0] 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 [1] a while ago.
As for your earlier question, nginx has the same issue here [2]. Really all
comes down to OpenSSL not making it easy to do better.
~reed
[0] https://blog.twitter.com/2013/forward-secrecy-at-twitter
[1] https://www.imperialviolet.org/2013/06/27/botchingpfs.html
[2]
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 [1] ...
> >
> > 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 [1]. 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 [1] 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.
>
>
> [1]
> 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.
