-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DHE ciphers should be disabled in Intermediate compatibility configuration #268
Comments
citation needed
except that even strongest ECDHE will be broken by quantum computers before the weakest (FF)DHE allowed by the guide |
For example, RFC 7457, section 2.13, Denial of Service. I already explained this: allowing DHE ciphers opens an additional DoS vector through very expensive SSL handshakes. So, servers with disabled DHE ciphers are more protected from DoS attacks at TLS layer and this is means what such servers are more stable.
Please see carefully at Intermediate compatibility configuration. It has By the way, DHE is not quantum-resistant cryptography and it will be easy broken by quantum computers too. DHE ciphers can help in only one very rare and very special case: if system administrator can't use ECDSA certificates and must use only RSA certificates and if system administrator must provide normal work of site with IE11 clients. Only in this special case enabling DHE ciphers can help as temporary workaround, because IE11 can't use ECDHE key exchange with RSA certificates and fail with error if server don't provide ECDSA certificates for ECDHE key exchange. Solution of this problem is easy - just provide ECDSA certificated in addition to RSA certificates and IE11 will work normally with such site even with completely disabled DHE ciphers in nginx configuration. So, I don`t see any reasonable reasons for enabling DHE ciphers in Intermediate compatibility configuration by default on all servers in internet, as it now recommented by https://ssl-config.mozilla.org/ site. For example, Google disable DHE ciphers even on Old backward compatibility configuration at site www.google.com. |
it's the server that selects the DHE parameters in the connection, if it can't use them, it shouldn't have selected them calling it "very expensive" is also dishonest, it's not like we are talking about orders of magnitude here
s/supported/explicitly listed/ the list of clients is not exhaustive
that's not what I said |
Hi, you can see the rationale for including the DHE-RSA-* cipher suites in the Intermediate configuration in the comments on issue #178. The tl;dr is the that IE 11 on Windows 7 only supports AES-GCM with an RSA certificate if you also use finite field DHE as the key exchange algorithm. As these guidelines are meant to be generic and widely-applicable they can not break compatibility with IE 11 for sites using RSA certificates (currently the most common type). If you use an ECDSA certificate (or you don't want to be compatible with IE 11 on Windows 7) you can safely disable those cipher suites. |
Windows 7 is EOL 14 Jan 2020 and it is not supported anymore. Also, Windows Server 2008 R2 is EOL 14 Jan 2020 and it is not supported anymore. So, all Windows 7 and Windows Server 2008 R2 users should migrate to more supported operating systems as soon as possible. Should Intermediate compatibility configuration support legacy and unsupported operating systems? I think no, because for legacy software exists Old backward compatibility configuration on site https://ssl-config.mozilla.org/ IE11 is not widely-used browser, it is mostly used just as downloader for Mozilla Firefox or Google Chrome installers. See statistics: IE11 has only 2.30% market share of all browsers, but Windows 7 has 32.74% market share of all desktop/laptop operating systems in December 2019. Also, current version of Server_Side_TLS wiki page recommends to use ECDSA type of certificate - in this case IE11 in Windows 7 works fine even with completely disabled DHE ciphers. If ECDSA certificates used - in this case DHE ciphers should/must be disabled to avoid DoS vector through very expensive SSL handshakes. We have the choice:
Majority of servers in internet can use ECDSA certificates and/or don't need to support IE11 on Windows 7. Only very small percent of system administrators need to support IE11 on Windows 7 and can't use ECDSA certificates (acmebot, acme.sh and dehydrated supports ECDSA certificates, even certbot plan to start supporting of ECDSA certificates after Jun 2020). May be only three configurations: Modern, Intermediate and Old is not enough and should be added fourth configuration: "legacy Intermediate with forced usage of RSA only certificates", located between true "Intermediate" and true "Old" configuration? And only this "legacy Intermediate RSA only" configuration should support servers with forced RSA only certificates and should enable DHE ciphers to support IE11 on unsupported operatings systems? True "Intermediate" configuration should recommend to use ECDSA certificates or dual ECDSA/RSA certificates (this provide full support for IE11) and must recommend to completely disable DHE ciphers to avoid DoS vector through very expensive SSL handshakes. @april, what you think about this? |
Intermediate aims for 99.99% compatibility or so. 2.3% of the market is far, far too large of a percentage to recommend killing DHE. While I agree that it's not great that people are still using unsupported operating systems, it is the reality of the world. And I have worked at too many large companies (and known too many people who have worked at them) to say "all you have to do is switch to or add ECDSA certs". There are massive legacy and monetary concerns with switching from RSA to ECDSA certificates for a lot of companies. I think it is very likely that we end up disabling DHE entirely with the next iteration of the Server Side TLS guidelines, but that probably won't happen for another couple of years. If your server is setup with an ECDSA certificate, then DHE won't be available for handshakes. There's not really any risk of leaving it there, but there is huge compatibility gain for administrators who don't know what certificate type they have, or can't switch to ECDSA.
Google is able to do this because they support RSA_RSA handshakes, which are not forward secret. They do this for the same reason as our guidelines recommend DHE: namely that there are still lots of systems out there that can't do ECDHE-RSA. |
@april, you are right. if server use only ECDSA certificate - DHE ciphers will be completely disabled by nginx, despite the fact that they are explicitly enabled in nginx configuration. As for me, current recommendations on wiki page Server Side TLS and site https://ssl-config.mozilla.org/ are misleading: they recommends to use ECDSA certificate and at the same time they recommends to explicitly enable DHE ciphers in nginx config and copy dhparam.pem file from https://ssl-config.mozilla.org/ffdhe2048.txt url. Several problems:
As I understand, dual ECDSA and RSA certificates nginx setup will be useless with Intermediate compatibility configuration when enabled only protocols TLS 1.2 and TLS 1.3 because in this case RSA certificate don't add any value and it should be considered legacy and completely removed from nginx configuration. May be it will be better to add switch/radiobox to page https://ssl-config.mozilla.org/ for generating two different Intermediate compatibility configurations: for ECDSA only and RSA only certificates? By default enabling recommended ECDSA only certificate type nginx configuration with ability of easy switch to RSA only nginx configuration? Something like this (configuration fragments with difference):
And add to wiki page Server Side TLS rationale why ECDSA certificates are recommended and should be preffered (DHE can be disabled and this closes additional DoS vector through very expensive SSL handshakes) and which drawbacks have RSA only server setup (DHE must be enabled if IE11 support is required in RSA only certificate setup and this opens additional DoS vector through very expensive SSL handshakes). Intermediate compatibility configuration recommended as highly secure configuration and may be it will be better to explain system administrators what is the drawbacks of decision to use RSA certificates from performance and security point of view compared to ECDSA certificates? Which type of certificate is used on the server - system administrators can easily detect by |
the whole point of a single configuration string is so that if the certificate changes, the configuration is not completely broken |
I've added to The performance numbers I see are:
given that we recommend nistp384, the server would need to be configured with 4096 bit keys for FFDH to be considered a bigger burden than ECDH, and even the most excessive FFDH key size is barely 4 times slower than the slowest ECDH curves as such, calling FFDH "very expensive" and "a DoS vector" is dishonest, please stop doing that |
About which recommendations you are talking? At wiki page Server Side TLS X25519 has the highest priority for all configurations (Modern, Intermediate and Old). X25519 is the default curve for ECDHE in Mozilla NSS. X25519 is the default curve for ECDHE in OpenSSL starting from version 1.1.0. Most widely used browsers are prefer X25519 for ECDHE by default. Most servers, used OpenSSL version 1.1.0 and newer are prefer X25519 for ECDHE by default. For example:
And you can see, what 2048 bit ffdh DHE is ~ in 8.5 slower then ECDHE with X25519 curve on your hardware. And yes, using RSA certificates with DHE enabled opens additional DoS vector through very expensive SSL handshakes.
As I already say in previous message, Intermediate compatibility configuration recommended as highly secure configuration and may be it will be better to explain system administrators what is the drawbacks of decision to use RSA certificates from performance and security point of view compared to ECDSA certificates? Currently wiki page Server Side TLS recommends system administrators to use ECDSA certificates and in the same time - recommends enable DHE ciphers in config. Many other sites in internet describes how to configure dual ECDSA and RSA certificates on nginx - such settings is useful only for Old compatibility configuration, with TLS 1.0 and TLS 1.1 enabled, but it is useless for Intermediane configuration, with only TLS 1.2 and TLS 1.3 enabled. Configured in such way, with dual ECDSA and RSA certificates and with DHE enabled - servers opens additional DoS vector through very expensive SSL handshakes. But current version of wiki page Server Side TLS does not contain warnings about such not highly secure configurations. |
So you're saying that supporting the very slow and generally unused secp384r1 is not a DoS venue, but supporting the faster 2048bit FFDH is? |
First, please pay attention, what in your previous message you provide benchmarks for FFDH and ECDH, but we talking here about DHE+RSA and ECDHE+ECDSA.
Difference between DH and DHE from RFC5246:
Did you think what between DH and DHE no difference from performance point of view and DHE can be replaced by DH in benchmarks? Second, as you probably already know, what ffdhe2048 not recommended to use by RFC7919: "forward-looking implementations ("future systems") should use FFDHE group sizes of at least 3072 bits". So ffdhe2048 is not recommended, and only ffdhe3072 and ffdhe4096 are recommended to use in TLS 1.2 and TLS 1.3 for "highly secure configuration". As I understand RFC7919, wiki page Server Side TLS and https://ssl-config.mozilla.org/ site should stop recommending to use ffdhe2048 and start recommending to use at least ffdhe3072 or even ffdhe4096 for DHE+RSA only configurations. At least, just such recommendations present in document IT Security Guidelines for Transport Layer Security (TLS) from National Cyber Security Centre of Netherlands. Third, in 2014 you test DHE and ECDHE performance and you make conclusions what "The ephemeral DH with matching key size gives a truly abysmal 800% drop in performance". Now you change your personal opinion, and now you think what DHE are much faster when ECDHE? And, fourthly, as far I understand, should be tested not plain DH/ECDH or DHE/ECDHE, but full combitation DHE+RSA and ECDHE+ECDSA, because ECDSA certificates transfer most of the work to client side, and server load in case ECDHE+ECDSA will be much lower when in case DHE+RSA.
The main benefit of ECDSA certificates is a significantly lower load on the server, and, accordingly, the ability to serve a significantly larger number of clients. But this difference in your DH/ECDH benchmark simply will not be visible at all. In order to get results of a performance test that are adequate for reality, you need to test one server and many clients through the network for each case of DHE+RSA server and ECDHE+ECDSA server. And only then it will be seen how many client connections this server can handle using DHE + RSA (weak ffdhe2048 or sufficient ffdhe3072 / ffdhe4096, RSA 2048 bit or 3072 bit or 4096 bit) and using ECHE + ECDSA (recommended X25519, prime256v1 and secp384r1 ECDHE curves with ECDSA certificates). |
the calculation performed to derive shared secret in DH and DHE is exactly the same
ffdhe3072 is still faster than secp384p, your point?
where did I say that?! I only stated that some combinations are faster or slower, not that DHE in general is faster or slower!
well, then run your own benchmarks that include all those variables, describe your methodology and show us the numbers and don't forget that ffdhe3072 group can be used with ECDSA in TLS 1.3 |
Yes, they recommend it. They don't require it. They very explicitly say:
How is that misleading? It has a recommendation, but it doesn't require ECDSA. In any case, DHE is not going away for probably a couple years. And all of these benchmark numbers are pretty useless, as being faster or slower or whatever is fairly irrelevant when we're talking the merest fractions of a second. |
Would this be any more "on-topic" for now middle 2024? AFAIK the "problem" I see with the current guide is not the performance thing that was debated, but the point @makhomed pointed out at some point: With TLS1.2 there is no "legacy burden" with DHE and as TLS1.2 has been long recommended as practical minimum anyway, DHE becomes moot point. There was an notion of "should support for special cases".. Well, There is always an special case, but the fact remains it doesn't affect anyone who follows the configurators best practices... Anyone needing the DHE will indeed specifically make it work instead of magic happening because it is there on the configuration now. This is the reason I'd like to see the DHE parms to be dropped from the current "modern" and "intermediate" configurator options; It plainly does not make any sense to exists for doing nothing. |
I think it's a much better time to remove DHE from the recommendations -- it was there to support versions of Windows that could not do forward secret handshakes when using RSA certificates. Pretty sure those are all dead now, and has been for a few years. That said, it should be made clear that they are unlikely to cause any security problems because only that old weird stuff would be negotiating it anyways. |
There is a potential DoS issue though, see #162. |
mozilla/ssl-config-generator#162 provided zero additional information compared what was discussed here already |
For current, 5.3 version of Intermediate compatibility configuration it is unclear what is rationale for enabling DHE ciphers. I talk about https://ssl-config.mozilla.org/ site and https://wiki.mozilla.org/Security/Server_Side_TLS wiki page.
Remember, Intermediate compatibility configuration force all clients to use only TLS 1.2 and TLS 1.3 protocols.
Do you know any clients, which are able to use TLS 1.2 (defined in RFC 5246 in August 2008) but not able to use ECDHE ciphers (defined in RFC 4492 in May 2006)? I don't know any such clients.
Achived version 4.0 of wiki page "Server_Side_TLS" describes which widely used clients lack support for ECDHE and must then rely on DHE to provide perfect forward secrecy:
But all these widely used clients did not understand TLS 1.2 protocol and they are in any case can't be used with servers configured with Intermediate compatibility configuration.
So, DHE ciphers should be completely disabled in Intermediate compatibility configuration to improve overall server stablity and security. If DHE ciphers are disabled on server side - in this case server will be protected from DoS attacks via very expensive SSL handshakes with DHE ciphers.
The text was updated successfully, but these errors were encountered: