DHE ciphers should be disabled in Intermediate compatibility configuration

[makhomed]

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:

• Android < 3.0.0
• Java < 7
• OpenSSL < 1.0.0

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.

[tomato42]

improve overall server stablity

citation needed

and security.

except that even strongest ECDHE will be broken by quantum computers before the weakest (FF)DHE allowed by the guide

[makhomed]

improve overall server stablity

citation needed

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.

and security

except that even strongest ECDHE will be broken by quantum computers before the weakest (FF)DHE allowed by the guide

Please see carefully at Intermediate compatibility configuration. It has ssl_prefer_server_ciphers off; so this means what clients will choose cipher to use. And almost all supported clients will just ignore DHE ciphers and use ECDHE ciphers. Only one exception of this rule is IE11 client, which prefer to use DHE instead of ECDHE if both available. All other clients prefer to use ECDHE cihpers and ignore DHE ciphers. So your argument about "better" security of DHE ciphers compared to ECDHE from point of view of quantum computers is not applicable to current Intermediate compatibility configuration and the vast majority of clients.

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.

[tomato42]

improve overall server stablity

citation needed

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.

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

and security

except that even strongest ECDHE will be broken by quantum computers before the weakest (FF)DHE allowed by the guide

Please see carefully at Intermediate compatibility configuration. It has ssl_prefer_server_ciphers off; so this means what clients will choose cipher to use. And almost all supported clients will just ignore DHE ciphers and use ECDHE ciphers.

s/supported/explicitly listed/

the list of clients is not exhaustive

By the way, DHE is not quantum-resistant cryptography and it will be easy broken by quantum computers too.

that's not what I said

[tylerknott]

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.

[makhomed]

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:

• recommend to use ECDSA certificates (this provides support IE11 even on unsupported operating systems) and recommend completely disable DHE ciphers to avoid DoS vector through very expensive SSL handshakes on most systems.
• very rare situation, when system administrators need to support unsupported operating systems such as Windows 7 and Windows Server 2008 R2 and system administrators need to support IE11 on unsupported operating systems and system administrators can't use (why?) recommended ECDSA certificates - only in this special case enabling DHE ciphers can help.

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?

[april]

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.

For example, Google disable DHE ciphers even on Old backward compatibility configuration at site www.google.com.

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.

[makhomed]

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.

@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:

• Such nginx configuration is useless work, because DHE will be not used on server with ECDSA only certificate.
• Such nginx configuration is misleading, because system administrators after reading such recommendations will think what configuring ssl_dhparam file and DHE ciphers is required for normal server operation with ECDSA certificate.
• Such nginx configuration is dangerous in case if system administrator by error enable simultaneously ECDSA and RSA certificates on the server, because in this case server will be unprotected from additional DoS vector through very expensive SSL handshakes (if DHE enabled).

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):

• For ECDSA only configuration:

    ssl_certificate /path/to/signed_cert_plus_intermediates.ecdsa.pem;
    ssl_certificate_key /path/to/private.ecdsa.key;
    ssl_session_timeout 1d;
    ssl_session_cache shared:MozSSL:10m;  # about 40000 sessions
    ssl_session_tickets off;

    # intermediate configuration
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers off;

• For RSA only configuration:

    ssl_certificate /path/to/signed_cert_plus_intermediates.rsa.pem;
    ssl_certificate_key /path/to/private.rsa.key;
    ssl_session_timeout 1d;
    ssl_session_cache shared:MozSSL:10m;  # about 40000 sessions
    ssl_session_tickets off;

    # curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam.pem
    ssl_dhparam /path/to/dhparam.pem;
    # !!! DHE ciphers required to be enabled with RSA certificate for supporting IE11 on Windows 7, Windows Server 2008 R2 and Windows Server 2012 R2 !!!

    # intermediate configuration
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    # !!! DHE ciphers required to be enabled with RSA certificate for supporting IE11 on Windows 7, Windows Server 2008 R2 and Windows Server 2012 R2 !!!
    ssl_prefer_server_ciphers off;

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 openssl utility (openssl x509 -in certificate.pem -text -noout | less) or via excellent site https://decoder.link/result

[tomato42]

the whole point of a single configuration string is so that if the certificate changes, the configuration is not completely broken

[tomato42]

I've added to openssl speed ability to benchmark FFDH key exchanges.

The performance numbers I see are:

                       op     op/s
2048 bits ffdh   0.0005s   2181.4
3072 bits ffdh   0.0009s   1102.7
4096 bits ffdh   0.0019s    539.6
6144 bits ffdh   0.0041s    243.1
8192 bits ffdh   0.0085s    118.1
                              op      op/s
 224 bits ecdh (nistp224)   0.0006s   1777.4
 256 bits ecdh (nistp256)   0.0001s  18095.7
 384 bits ecdh (nistp384)   0.0012s    810.2
 521 bits ecdh (nistp521)   0.0025s    400.5
 256 bits ecdh (brainpoolP256r1)   0.0006s   1675.9
 256 bits ecdh (brainpoolP256t1)   0.0006s   1683.2
 384 bits ecdh (brainpoolP384r1)   0.0012s    808.0
 384 bits ecdh (brainpoolP384t1)   0.0012s    825.8
 512 bits ecdh (brainpoolP512r1)   0.0021s    484.5
 512 bits ecdh (brainpoolP512t1)   0.0020s    498.9
 253 bits ecdh (X25519)   0.0001s  18457.6
 448 bits ecdh (X448)   0.0028s    352.2

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

[makhomed]

I've added to openssl speed ability to benchmark FFDH key exchanges.

The performance numbers I see are:

                       op     op/s
2048 bits ffdh   0.0005s   2181.4
                              op      op/s
 253 bits ecdh (X25519)   0.0001s  18457.6

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:

echo | openssl s_client -connect ssl-config.mozilla.org:443 -cipher kEECDH | grep "Server Temp Key"
Server Temp Key: X25519, 253 bits

# echo |  openssl s_client -connect google.com:443 -cipher kEECDH | grep "Server Temp Key"
Server Temp Key: X25519, 253 bits

# echo | openssl s_client -connect youtube.com:443 -cipher kEECDH | grep "Server Temp Key"
Server Temp Key: X25519, 253 bits

# echo | openssl s_client -connect facebook.com:443 -cipher kEECDH | grep "Server Temp Key"
Server Temp Key: X25519, 253 bits

# echo |  openssl s_client -connect wikipedia.org:443 -cipher kEECDH | grep "Server Temp Key"
Server Temp Key: X25519, 253 bits

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.

the whole point of a single configuration string is so that if the certificate changes, the configuration is not completely broken

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.

[tomato42]

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?

[makhomed]

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.

• Diffie-Hellman Ephemeral (DHE) key-Exchange
• Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) Key-Exchange
  only DHE and ECDHE provide forward secrecy and recommended to use, not DH and ECDH.

Difference between DH and DHE from RFC5246:

DH denotes cipher suites in which the server's certificate contains
the Diffie-Hellman parameters signed by the certificate authority
(CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
parameters are signed by a signature-capable certificate, which has
been signed by the CA. The signing algorithm used by the server is
specified after the DHE component of the CipherSuite name.

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.

# openssl speed rsa2048 ecdsap256

                  sign    verify    sign/s verify/s
rsa 2048 bits 0.000886s 0.000040s   1128.4  25108.6

                              sign    verify    sign/s verify/s
256 bits ecdsa (nistp256)   0.0000s   0.0001s  23407.8   7308.4

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).

[tomato42]

Did you think what between DH and DHE no difference from performance point of view and DHE can be replaced by DH in benchmarks?

the calculation performed to derive shared secret in DH and DHE is exactly the same
the switch from non-ephemeral to ephemeral DH on server side has exactly same effect – it doubles the number of computations necessary, it won't change the relationships between the different groups

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".

ffdhe3072 is still faster than secp384p, your point?

Now you change your personal opinion, and now you think what DHE are much faster when ECDHE?

where did I say that?! I only stated that some combinations are faster or slower, not that DHE in general is faster or slower!

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.

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

[april]

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.

Yes, they recommend it. They don't require it. They very explicitly say:

Certificate type: ECDSA (P-256) (recommended), or RSA (2048 bits)

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.

[olmari]

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.

[april]

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.

[ghen2]

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.

[tomato42]

mozilla/ssl-config-generator#162 provided zero additional information compared what was discussed here already