
How to botch TLS forward secrecy - phenylene
https://www.imperialviolet.org/2013/06/27/botchingpfs.html
======
acabal
So posts about what you can screw up are nice, but what would be nicer is
posts about how to set up an ideal SSL configuration for various web servers.
(Perhaps there's no "perfect" configuration possible, but "strongest given
known limitations" would be fine too.)

With all the talk of PFS lately I've been trying to configure Apache to do it,
but either I'm dumber than I thought or there's no straightforward how-to
online at the moment.

Instead of telling us the various crazy pitfalls and edge cases, just give
dummies like me the best possible formula so we can configure things securely
and then get on with our lives. The first step towards defeating eavesdropping
is making the best possible SSL configuration a copy and paste affair instead
of an acronym guessing game.

Edit: If total security isn't really possible right now as this post suggests,
maybe a "best" configuration plus mailing list for when it's updated for
varios major platforms (ie LTS) would be a good stopgap.

~~~
ivanr
I think one of the biggest pitfalls of SSL/TLS (and many other security
technologies available now) is that they are so configurable and flexible. The
approach assumes everyone has the knowledge and the time to invest to tune
everything. In reality, few people do.

Going back to your request, it's impossible to do with server configuration
alone. Many other aspects, including the design of the web application, play a
significant role. The best we can do at this point is work on the body of
knowledge, hoping others can find the time to invest.

The best I was able to do so far is build the SSL Labs test[1], write the
SSL/TLS Deployment Best Practices guide[2], and start the SSL Research
Wiki[3], where I intend to add other un-structured information over time
(including example server configuration). I have also written a free OpenSSL
Cookbook[4] (requires registration, and you can opt out of email afterwards).

Apologies if this post comes across as self-promoting, but this is what I
spent a large amount of my time on. These are all genuinely useful and
important resources.

[1] [https://www.ssllabs.com/ssltest/](https://www.ssllabs.com/ssltest/)

[2] [https://www.ssllabs.com/projects/best-
practices/](https://www.ssllabs.com/projects/best-practices/)

[3]
[https://github.com/ssllabs/research/wiki](https://github.com/ssllabs/research/wiki)

[4] [https://www.feistyduck.com/books/bulletproof-ssl-tls-and-
pki...](https://www.feistyduck.com/books/bulletproof-ssl-tls-and-pki/)

~~~
pfg
Thank you very much for your great work, I've found both the SSL Labs test and
the best practice guide quite useful!

------
bcoates
The only purpose of session resumption is performance, right? I thought
someone published a report recently that real-world servers don't get enough
successfully resumed sessions for it to even be worthwhile, particularly in a
world with crypto hardware, SPDY and HTTP keepalive.

Wouldn't it be easier to just disable TLS resume than to figure out how to do
it right?

edit: It was another agl article,
[https://www.imperialviolet.org/2010/06/25/overclocking-
ssl.h...](https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html):

    
    
      Since the session information contains key material, 
      it's never cached on disk so the attempted client 
      resume rate, seen by Google, is only 50%.

~~~
pfg
That report sounds interesting, got a link by any chance?

I would think that session resumption should greatly increase performance for
clients returning to your site, because there's no need to do a complete
handshake (which is - relatively speaking - resource-intensive and IIRC also
requires more network round-trips).

------
pbsd
> Ideally the DH group would match or exceed the RSA key size but 1024-bit DHE
> is arguably better than straight 2048-bit RSA

So let's argue!

It depends on how you presume the attacker is gonna get you. Suppose the
attacker is well-funded enough to go after one RSA-1024 or DH-1024 instance.
Unlike RSA, however, DHE tends to work modulo the same prime over and over.
This has consequences for cryptanalysis: once the attacker has solved a single
DH instance, they can solve the next one much faster [2]. In the case of
1024-bit DH, the subsequent instances can be solved in about 2^55 time (versus
about 2^80 for the first log); this is not instant, but it's pretty quick for
a well-funded and skilled attacker.

Where 1024-bit DHE does shine versus 2048-bit static RSA is against other,
less Hollywood, types of key retrieval such as outright hacking.

[1]
[https://tools.ietf.org/html/rfc2409#page-22](https://tools.ietf.org/html/rfc2409#page-22)

[2]
[http://www.iacr.org/archive/pkc2006/39580175/39580175.pdf](http://www.iacr.org/archive/pkc2006/39580175/39580175.pdf)

------
dfc
The recent discussions of SSL/TLS on the server made me wonder about client
configuration. I looked around for a SSL Labs like tool for browser and asked
on security.SX[1] but I was unable to find anything comparable which was
troubling.

Am I missing something to think that an SSL Labs like tool for the client is
also important? Does anyone have any recommendations?

[1]
[http://security.stackexchange.com/q/38084/4564](http://security.stackexchange.com/q/38084/4564)

~~~
e12e
If you want to just test yourself, you get quite a lot of info from openssl's
s_servers's status-page, enabled with -www:

    
    
        openssl req -x509 -nodes -days 30 -newkey rsa:2048 -keyout localhost.key -out localhost.crt
        openssl s_server -www -debug -accept 4433 -key localhost.key -cert localhost.crt
    

Then open [https://localhost:4433](https://localhost:4433) in your browser and
temporarily ignore the cert-warning.

You'll get a list of ciphers supported by the server, and a list of ciphers
common between the server and the client (which, with all ciphers enabled
(default) on the server -- should be rather exhaustive).

See also:
[http://support.microsoft.com/kb/299520](http://support.microsoft.com/kb/299520)

------
marshray
Perhaps someone ought to add session ticket support to OpenSSL for using some
of the latest fast in memory-only databases.

If I were a company which made such a database, I'd think that kind of project
would give me very good exposure.

~~~
lifeisstillgood
I think there are two takeaways from this

1\. A timely reminder nothing is perfectly secure

2\. Don't use session tickets. Store nothing on the client except a random
key. You will cock it up.

------
Sami_Lehtinen
How to configure Apache to use stronger than 1024 bit DHE? Like group 14.

~~~
agwa
You can't. It hard codes 1024 bit parameters, which is highly annoying.
There's a patch to allow user-specified DH parameters but it hasn't been
merged:

[https://issues.apache.org/bugzilla/show_bug.cgi?id=49559](https://issues.apache.org/bugzilla/show_bug.cgi?id=49559)

I would just go with elliptic curve Diffie Hellman (which unfortunately
requires Apache 2.4) and then disable the non-EC Diffie Hellman ciphers if
you're concerned about using 1024 bit DH.

FWIW, nginx is a lot more flexible in configuring the cryptography.

~~~
yuhong
Elliptical curve is faster too.

------
mtgx
So if Google enables forward secrecy for Google searches, would that mean
every single Google search would be encrypted with a new key, or only the
"open session"? Would encrypting every search be possible with _perfect_
forward secrecy [1]? And if so, can't we get that for TLS 1.3, too?

[1]
[http://en.wikipedia.org/wiki/Perfect_forward_secrecy](http://en.wikipedia.org/wiki/Perfect_forward_secrecy)

~~~
willvarfar
Well Google is also a company that stores full history of everything and hands
over stuff to the NSA, so in the bigger picture the point is moot?

