In determining TLS standards for my company, I have come to wonder why all recommendations still suggest the use of the Ephemeral Diffie-Hellman TLS ciphers starting in TLS_DHE_xxx
Background and research
After doing a lot of research, I have found the following.
- TLS_DHE_xxx cipher suites are not used much in the wild - Only one site (Wikipedia.org) in the top ten sites on
Alexa.comactually uses them. None of the others do, instead relying on TLS_ECDHE_xxx or TLS_RSA_xxx ciphers. From this, I can only deduce that there are not many browsers out there that are affected by not using these ciphers, otherwise these large sites would be cutting people off.
- "Enterprise" web server products that I have looked at do NOT support the TLS_DHE_xxx cipher suites. Oracle iPlanet Web server, Oracle HTTP Server(OHS) and IBM HTTP Server(IHS) do not support these suites. (Although OHS/IHS are both based off Apache, they both use their own TLS implementations instead of OpenSSL.) If support of these cipher suites was critical, these Enterprise offerings would surely need to support them.
- The 'de-facto' source for suggested cipher suites seems to be the Mozilla Server_Side_TLS guide, but the intent of this document is to help Mozilla sysadmins in configuring various Mozilla sites. It was NOT originally intended to be a general standard for the Internet-at-large, even though it has fallen into that role. Also, this document makes no mention of why the TLS_DHE_xxx ciphers are needed.
- Since the LogJam attack came into the wild, sysadmins have had to ensure that their DH parameters are correctly adjusted. If this cipher is not really needed, this is wasted effort. Simply removing the cipher would be a better solution that will not potentially cause problems later (Say someone creates a new TLS listener and forgets the DH parameters).
- Over the coming years, the Internet will be moving towards ECDSA certificates. There are no TLS_DHE_xxx cipher suites that support ECDSA certificates (Only TLS_ECDHE_xxx cipher suites do). It seems to me, given this, that these cipher suites will be going away anyway.
Looking at the supported cipher suites for browsers on ssllabs.com, it is apparent that there are no significant browsers that would choose TLS_DHE_xxx ciphers over the Elliptic Curve equivalents. Every browser, even on Wikipedia.org that supports TLS_DHE_xxx ciphers, will instead choose a TLS_RSA or TLS_ECDHE cipher suite.
Notable exceptions to this are Android 2.3.7 and below, IE 8 on XP, Java 6u45 and OpenSSL 0.9.8y. Of these, Android 2.3.7, OpenSSL 0.9.8y and Java 6u45 will choose a TLS_DHE cipher, and even then, the latter will not support DH parameters greater than 1024 bits (Which is recommended since the LogJam attack). IE 8 on XP will not even choose the TLS_DHE ciphers, so that browser is moot in this context.
Effectively, the above paragraph results in the fact that the only advantage to enabling TLS_DHE_xxx ciphers is that Android 2.3.7 and OpenSSL 0.9.8y clients are able to connect using Perfect Forward secrecy. It is my finding that these fringe-case clients are the only reason to support these ciphers. If this is indeed the case, it seems that going forwards, there is no purpose in including these cipher suites unless you explicitly wish to support PFS for these browsers. Note that all of these browsers will still connect using TLS_RSA_xxx ciphers if the correct ones are available, but without PFS.
After some great feedback from Mike and Michał, I have decided to add some further points to my research that I would like to be considered when answering this question.
Although they both raised valid points, in my opinion, they both point to somewhat 'fringe' cases when considered on the Internet in general as we know it today.
Trust Issues with EC ciphers.
I had considered this during my initial research, but forgot to add it to the original question. Some people do not trust the standard EC curves defined in RFC 4492. This could result in a number of possible outcomes to my question.
1. The server owner distrusts ECDHE ciphers but leaves them enabled along with DHE ciphers (As per the Mozilla TLS guide). In this case, the DHE ciphers will never be used by anything other than the fringe-case browsers mentioned above.
2. The server owner has no opinion on the trustworthiness of ECDHE ciphers and leaves the DHE ciphers there in case the client distrusts ECDHE. In this case, the only users that will have disabled ECDHE are likely advanced users that distrust them due to the NSA involvement. It could also be assumed that such a user would want Perfect Forward Secrecy and therefore be restricted to only using DHE ciphers. However half of the web servers on the internet are not using DHE ciphers so these users would have a hard time doing pretty much anything (And as they are advanced users, they would know why they cannot google or visit stack exchange or most top ranked sites).
This seems like a fringe case of users that do not need to be considered for the 'typical' web site.
3. If the server owner completely distrusts ECDHE ciphers, then she should simply not enable them, instead only enabling DHE ciphers. This is a good scenario for using DHE ciphers. However, I have not found any sites yet that only support DHE and not ECDHE.
This makes this seem like a 'fringe case' and not applicable to typical TLS setups. It could certainly be argued in any standard that if ECDHE trustworthiness is an issue, that DHE should be considered instead.
Curve Compatibility Issues
Having now learned about how the "Supported Elliptic Curves Extension" works, I can now see how this could be a consideration for using DHE ciphers. However, I still feel that this is a fringe case. Consider these scenarios:
1. The server owner wishes to use custom curves that are not widely supported in common browsers. She uses a TLS configuration that specifies the custom curve and leaves the standard curves in place also. In this case, browsers that do not support the custom curves will still connect using ECDHE and the standard curves. In no case, other than the outdated fringe-case clients mentioned above, would any browser connect using DHE so specifying them would not be necessary.
2. The server owner wishes to only use custom/nonstandard curves that are not widely supported in common browsers. She uses a TLS configuration that specifies the custom/nonstandard curve for ECDHE and not the standard curves. Most current browsers would not support the custom/nonstandard curve and would need to fall back to DHE to maintain PFS. This is a good scenario for supporting DHE ciphers as a fallback for those that do not support good ECDHE curves. I still feel that this is a fringe case as common TLS servers do not allow such configuration (yet).
This may become less of a fringe case in the future if more servers start supporting the option of specifying which curves you wish to use.
I have been searching for some time for reasons to include or to exclude these ciphers and have come up with nothing, other than my own research that I have done myself. I can't help feeling that I must be missing something, so my question is this:
- Is there a valid and current reason, given the above, that TLS_DHE_xxx ciphers should be used in a modern TLS configuration for general use in 2015 and going forwards?