[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#762619: apache2: Don't let TLS session tickets botch PFS



Package: apache2
Version: 2.2.22-13+deb7u3
Severity: normal

Dear Maintainer,

As explained here[1], TLS session tickets can make Perfect Forward Secrecy
useless. The currently backported patches of openssl and apache on debian
stable don't provide any way to disable session tickets nor change the lifetime.

There are patches for apache 2.4 to disable session tickets, but they are not on
apache 2.2 and would require patches on openssl too (here[2] says it needs
openssl >=1.0.2). Session tickets, in apache 2.4 with OpenSSL 1.0.2 or later,
can be disabled using the SSLOpenSSLConfCmd directive, as documented here[2].

As stated here[1], restarting apache invalidates previous session tickets, so
that seems to be the only way to not render PFS useless (restart with some
frequency) on debian right now.

I tried to do some tests to see if maybe a reload was enough (doesn't cause
downtime :)) to re-generate the randomly generated session ticket key at
startup.  But let me be very clear about this: I'm not a security expert (far
from that) nor I have any deep knowledge of TLS, session resumption, etc. I
just did some tests that I'm not 100% sure what they mean.

I used sslyze and did a simple patch on top of it to print when the sesion
tickets resumption was being tested and added a sleep to give me time to reload
the apache server just in the middle. The patch I used is here[3]. So I just did
that: run the test until the "Trying to resume TLS tickets, waiting 10s" print
was done, then I reload the apache server and verify the next print wasn't
printed when apache finishes reloading (it didn't). And the result of the test
is that session tickets resumption is NOT supported. And, of course, if I run it
without reloading apache it says it is supported.

That's why I *think* that it *might* be enough to reload apache to invalidate
the previous session tickets and shorten the forward secrecy window. But, of
course, this should be verified.

In any case, it will be nice if in the README.Debian file this problem[1] is
mentioned and recommends some way to avoid it (using a reload if it is enough,
a restart -although not the very best solution-, backporting the patches from
apache 2.4 or whatever it needs to be done).


If I can help you with something, please let me know.




Thanks a lot,
Rodrigo


[1]: https://www.imperialviolet.org/2013/06/27/botchingpfs.html
[2]: https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslopensslconfcmd
[3]: https://github.com/rata/sslyze/commit/37a56bfa0f280869f6a17572c1726eda848c74bf


Reply to: