PFS support

[MartinNowak]

• make DH and ECDH configurable
• choose defaults
• select option to NOT reuse secrets

[s-ludwig]

Very nice, I'm going to test that in action right now! Not sure what the Travis error is caused by.

/but bah... that OpenSSL API is really one of the worst that I've ever seen. So much that you have to know and do by hand up front to get a secure system. Not even getting started with macro hell and that other stuff...

[s-ludwig]

Not sure what the Travis error is caused by.

Okay, was just an old version of the OpenSSL bindings still being picked up.

[s-ludwig]

And after some quirks unrelated to this PR have been resolved (ccf7fe1, 9a6fd1a), I'm now getting TLS 1.2 with PFS enabled and pretty good scores on https://www.ssllabs.com/ssltest/. Great!

The only issues listed there are now:

• Secure Client-Initiated Renegotiation: Supported DoS DANGER
• Session resumption (caching): No (IDs assigned but not accepted)
• BEAST attack: Not mitigated server-side

But PFS is chosen for any browser that supports it:

• Forward Secrecy: Yes (with most browsers) ROBUST

[MartinNowak]

We might even choose to only support EECDH and EDH, that is drop support for non-ephemeral diffie-helman, but the server will prefer the ephemeral versions already.

[MartinNowak]

/but bah... that OpenSSL API is really one of the worst that I've ever seen.

True, but I still have my mid term memory filled from updating the headers in case you have any questions.
update to OpenSSL 1.0.1g by MartinNowak · Pull Request #16 · D-Programming-Deimos/openssl

[s-ludwig]

Yeah, of all the clients tested on the ssllabs site, no client has chosen a non-ephemeral DH cipher (some older clients had to fall back to non-DH ones), so I guess it should be safe to drop them.

[s-ludwig]

Actually, I've overlooked some:

• Android 2.3.7 uses DH-RSA-AES128
• Old BingBot uses DH-RSA-AES256

So it's probably better to just keep the non-ephemeral ones as intermediate fallbacks. But I guess the (E)DH+3DES modes could be removed. Only old clients will use 3DES and those don't support DH at all (most notably IE on Windows XP).

[MartinNowak]

So it's probably better to just keep the non-ephemeral ones as intermediate fallbacks. But I guess the (E)DH+3DES modes could be removed. Only old clients will use 3DES and those don't support DH at all (most notably IE on Windows XP).

It probably doesn't matter, as we use the server preferred order. Not sure if exchanging the available ciphers has some sort of overhead though.