5

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.com actually 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.

Edit:

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.

Summary:

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?
  • 1
    DHE (with reasonable key length) should be preferred over RSA as it provides Forward Secrecy! Also, limited usage of some Top-pages is not an argument against a cipher. The bettercrypto.org actually ranks DHE before ECDHE in the recommended ordered cipher string because of the still ongoing research and trust issues in this field. Also, new widely trusted curves have to be supported by clients, they need to be deployed. – sebix Aug 28 '15 at 18:28
  • Without DHE ciphers enabled (And with correct ECDHE ciphers enabled), none of the browsers on ssllabs.com will resort to RSA, with the exception of the very old Android 2.3.7, the XP stack (Which has no PFS at all anyway), Java6 and OpenSSL 0.9.8 clients. If a website owner only cares about current/recent compatibility, there is no need for DHE in a typically recommended (Mozilla) configuration, as it simply will not be used by any browsers - This was the crux :) +1 for the bettercrypto link though. The first time I have seen DHE chosen over ECDHE. I will study the doc more :) – Tom17 Aug 28 '15 at 22:57
  • XP does support DHE-DSS (which is PFS) but that's basically usable only on intranets or closed groups because no known public CA issues certs for DSA. Also, most letter versions of OpenSSL 0.9.8 actually did support ECDHE, but needed arcane knowledge to use it; 1.0.0 in 2010 supported it properly. However, RedHat/Fedora and derivative builds of OpenSSL before 2015 deleted all ECC including ECDHE, and that was (is?) a pretty big chunk of users. – dave_thompson_085 Jan 1 '17 at 5:18
4
  1. Some servers may use curves likes Curve25519, Curve448 or P-521. Clients not supporting it will need alternative key exchange methods.
  2. Some people don't trust NSA-blessed NIST curves like P-256 and P-384 (check out SafeCurves to see why) and might want to block ECDHE until safer curves get adopted.
  3. Some people don't trust ECC at all and DHE is (SFAIK) the only viable alternative to have PFS without ECC.
  4. LogJam is result of using weak dhparam, not a problem in DHE itself.
  5. I am not so sure if ECDSA will (or even should) replace RSA signatures. Creating RSA signature is slower, but signature validation is faster than in case of ECDSA. We've also had a few fails related to ECDSA implementations and resulting in private key disclosures (PS3, OpenSSL, Android). Not a problem from scientific point of view, but in real world it's a technology-related risk we should consider.

PS Both ECDHE and DHE will be useless in post-quantum world, so we should think about solutions like SIDH (PFS for post-quantum cryptography) when considering key exchange methods in a bit more distant future.

  • Regarding the trust issues, I replied about this in my comment on Mike Scotts answer. Regarding the curve compatibility - I need to get back to my learning. I'm not familiar with how the curve selection works between server and client so need to do more research there :) – Tom17 Aug 25 '15 at 19:14
  • I understand more about how the "Supported Elliptic Curves Extension" enables the server and client to decide upon a curve and fallback to another mutually supported cipher if one exists. However, for a 'typical' server and a 'typical' client, they are both likely to use the commonly supported P-256 and P-384 curves. If Curve25519 etc are used and the common curves are left in place, clients will still connect. If a server admin removes support for the commonly supported curves then yes, the client would need to fall back to DHE ciphers. I still don't see this to be a common everyday case. – Tom17 Aug 25 '15 at 22:21
1

Some people do not trust the curves that are used for ECDHE, believing them to have been compromised by the NSA or some other agency -- see for example this comment by Bruce Schneier stating that he now prefers classic discrete log crypto instead of ECC. If you don't trust ECDHE then DHE is the only algorithm that provides perfect forward secrecy, and so should be your preferred choice.

  • If you have the opinion that the ECDHE suites are untrustworthy, then surely you should remove them from your cipher-suite list in your server configuration? This would ensure that the client connects with a DHE suite. However, in the recommendations that I find (Specifically, the Mozilla guide mentioned in my question), the ECDHE suites are preferred over the DHE ones. In such cases, DHE would not be used except for the fringe cases I mention. This leads me to think that the ideal would be to either list ECDHE OR DHE depending on your trust levels, but not both. Does this make sense? – Tom17 Aug 25 '15 at 19:12
  • If you're using ECDHE, you might consider DHE as well, in case the user has disabled ECDHE at their end because they don't trust it. It's true that very nearly all users will end up using ECDHE rather than DHE if both are available. – Mike Scott Aug 25 '15 at 19:57
  • Is it possible to disable ECDHE in common browsers? And if it is, any user that did so would then not be able to go to any of the sites currently in the top 10 sites (And probably a lot more than that too). No 'googling' or 'stack exchange' for them!! It seems to me like a theoretically possible scenario, but a very unlikely scenario in the real world. I wonder if anyone actually does this. If they do, they will be advanced users that will know why half of the internet is not working for them. It seems like a user-base that the typical site owner does not need to concern themselves with. – Tom17 Aug 25 '15 at 20:07
  • @Tom17 Yes, you can disable specific ciphers in Chrome by passing them in a list as a command-line argument when you run it: fehlis.blogspot.co.uk/2013/12/…. And if you disable ECDHE it doesn't mean that most sites will fail, because you will fall back on RSA for sites that don't support DHE. – Mike Scott Aug 26 '15 at 5:24
  • If you disable ECDHE, would one not be a savvy security buff who would also insist upon PFS and thus disable the non-PFS ciphers? It seems illogical that one would care enough to disable ECDHE and then not care about needing PFS... Unless people consider ECDHE to be a far higher risk than not using PFS - could this be the case? – Tom17 Aug 26 '15 at 11:20
0

First a note on how the ciphersuite selection works.

  • The client sends a list of ciphersuites in order of preference.
  • The server picks one of them to use for the session.

According to the standard servers are supposed to respect the client's preference. In reality servers tend to ignore the clients preferences as server admins believe (rightly or wrongly) they know better than the clients which cipersuites are best.

Suppose I am a server admin with the following goals:

  1. I want forward-secrecy on all clients that support it.
  2. I want the best symmetric cryptography the client supports.
  3. I want to use one certificate on my server, not mess arround with seperate RSA and ECDSA certificates.

I don't think these goals are unusual for a privacy-minded server admin.

Given these critera and according to ssl labs DHE fills some gaps.

  • For some strange reason IE 11 on win7 and win8 is missing some cipher combinations. It supports RSA based authentication (which you want so you can use normal certificates), It supports AES GCM and it supports ECDHE but for some strange reason it apparently doesn't support the combination of the three.
  • Andriod 2.x (still depressingly common) supports DHE but not ECDHE.

Since there is no reason to believe DHE with sufficiently large primes is insecure I would therefore leave it enabled if supported.

If it is enabled you should make sure a sufficiently large prime is used. My general guideline would be to make your DSA prime the same size as your RSA keys.

I would generally place DHE ciphersuites just below the corresponding EDHE ciphersuites in the preference order.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.