If you had the choice of these 2 ciphers which would you prefer?
DHE-RSA-AES128-SHA or AES128-SHA256?
Personally i would say that i would prefer Forward secrecy. Because this make sure that the message can not even decoded with the server key later on.
On the other side if the server key is leaked the better MAC does not help because with the server key the master secret can be calculated and so any
message can be encrypted and contain an valid mac.
As long as the MAC provides sufficient security then I would say it is more important to have PFS than to use the best MAC available. The security concerns of HMAC-SHA1 do not yet outweigh the benefits of PFS. The Mozilla TLS recommendations also rank DHE-RSA-AES128-SHA over AES128-SHA256 - Security/Server Side TLS - MozillaWiki
Currently, MD5 is OK as a MAC. There aren't any known attacks. There aren't any useful cipher suites which us MD5 as a MAC, but MD5 itself isn't a major issue. If you do the browser test for Chrome you'll see a distinct lack of SHA-2 MAC support for cipher suites which have both SHA-1 and SHA-2 variants. DHE is way more important than MAC strength. Also, ECDHE is better than DHE.
Interesting that people are focusing on PFS vs. MAC strength (or weakness, as the case may be). I'll offer a different perspective...
I'd also take into consideration the asymmetrical key size that will likely be negotiated between the client and server. When using AES128-SHA256 with a current certificate from a public certificate authority, you'll have a key size of 2048 bits or higher, which meets the 2048 bit minimum currently recommended. But with DHE-RSA-AES128-SHA, that may not be the case. Many/most implementations of this cipher suite didn't support a key size larger than 1024 bits until somewhat recently, which doesn't meet the 2048 bit minimum currently recommended. These older implementations are likely to be present in the real world for a long time.
In addition, the TLS protocol doesn't provide a good way for the client and server to know ahead of time what DHE key size the other side supports until they actually try to negotiate it. If it turns out that the other side doesn't meet your minimum key size threshold, your only option at that point is to either allow the negotiation to complete at below minimum security, or fail the negotiation which will likely cause the connection to fail entirely. Combine that with the fact that DHE handshakes at the recommended minimum 2048 bit key size (or higher) start to become quite slow, and I think you'll have some second thoughts about favoring DHE-RSA-AES128-SHA over AES128-SHA256.
I personally favor AES128-SHA256 over DHE-RSA-AES128-SHA due to the above, even though it doesn't support PFS. (Although if using a 1024 bit key size, I don't find PFS particularly reassuring.) Your mileage may vary based on what's important to you.
I disabled DHE on my Postfix mail transfer agent due to Comcast's email servers' use of 1024-bit DH parameters. I like the idea of PFS, but not when the implementation is crap. I'll prefer static RSA over weak DH in this case.
Do you have an list of supported cipher suites of "Comcast's email server" ?
Yes, here's the output from testssl.sh:
How is it possible that the server support 0x010080 SSL_CK_RC4_128_WITH_MD5 while he does not support SSLv2 ?
I Thought that the cipher suite id is 2 byte since SSLv3 and only SSLv2 support 3 byte ciphersuite id's.
Indeed, this is really confusing. Is it something to do with the SSL 2.0 handshake compatibility perhaps? Maybe if you've got the old-fashioned handshake and that cipher suite is enabled, even though it wouldn't be possible to use the cipher suite it's still offered? Highly confused...
Hi Troy, in one point i see it like you it is not valid to say PFS yes/no vs. SHA/SHA256.
I know that i am cheating with my test result SSL Server Test: suche.org (Powered by Qualys SSL Labs)
But it show that there are only really old clients that does not support ECDHE if you want to support them
too you have no SNI, SECURE_RENEG or even SSLv2_Hello support. So for me DHE is nothing that i would support at all.
Second if i think about risks:
a) Someone is able to compromise you server and get the private key.
b) Someone is able to break the DHE for each connection.
Personally i would rate (a) much higher and therefor prefer DHE2048 over no FS.
Thanks tlussnig, those are all great points. But I feel it's a somewhat web-centric view of the usage of TLS. Matthew brought up a great example of this with mail servers. I don't think Comcast is an outlier. I suspect there's a non-trivial number of SMTP servers out there that are still chugging along with older TLS implementations which may not support ECDHE, but do support DHE. (It's likely someone has done a scan recently and can provide hard numbers to prove or disprove this.)
The real world is filled with lots of clients and servers, and inertia is a powerful force. People are reluctant to change things that appear to be working fine as is. Over time older clients and servers get retired, but often because there was no other choice.
If you're sure your system will only connect to other systems that support DHE with a 2048 bit key size, or you think the other mitigations like ECDHE support make DHE and static RSA prioritization irrelevant, or if you just don't care that older implementations might fail to connect, then that's a perfectly reasonable choice to make. (Apache 2.2.31 was just released in July and is still supported, but I believe still has the 1024 bit DHE key size limitation.)
I'm less willing to make those assumptions, so I acknowledge the risks you describe but continue to prioritize static RSA over DHE. Both of those are prioritized below ECDHE, of course.
I would never use DHE on a mail server. I would also never use it on a web server. However, I would never use a web server that didn't provide ECDHE. If for some reason, say for a third party, I had to provide a TLS implementation on a web server which supported DHE but didn't support ECDHE, I would prioritise DHE over RSA and enforce 2048-bit DH parameters. If, for some reason, be it client support or server limitation, I was unable to enforce 2048-bit DH parameters, I wouldn't use DHE at all - it wouldn't be a case of RSA being prioritised over DHE, it would just be that RSA would be enabled and DHE wouldn't.
Apache 2.2.31 fully supports varying the DH parameter size - there is not 1024-bit limitation and there has not been for a long time. That said, I think 1024-bit remains the default.
Most things are insecure when configured badly enough. That doesn't mean that it's OK to always fall back on something that's less secure. DHE is more secure than RSA when correctly configured - that's why it exists. On the web, it's been supplanted by ECDHE due to its limitations and the difficulty of getting right. But it still has a place somewhere and you shouldn't just shun it by default - you should look at each case on its merits.
Retrieving data ...