1
$\begingroup$

Or did it mostly get replaced by ecdh for key exchange and rsa for authentication ?

$\endgroup$
  • $\begingroup$ What do you mean by "simple" in "the simple DH KE"? Finite-Field DH with RSA authentication or (denoted DHE in TLS notation) or the static Finite-Field / EC DH with the server having a static DH key that is contained in the certificate (denoted DH or ECDH in TLS notation)? $\endgroup$ – SEJPM Sep 18 '18 at 12:02
  • $\begingroup$ Like if its used at all these days on websites? if i check the tls protocols of websites for example this one it always says that edch is used for keyexchange and never the normal diffie hellman key exchange algorithm $\endgroup$ – Crptoo33 Sep 18 '18 at 12:07
5
$\begingroup$

In TLS, Diffie-Hellman (non-EC) can be used in TLS_DH_* ciphersuites ("static DH"), and in TLS_DHE_* ciphersuites ("ephemeral DH").

Static DH occurs when the server's certificate contains a public DH key. This never gained traction; historically, the US federal government promoted use of DH for key exchange because, at that time, RSA was still patented. However, nobody in practice does that anymore, except maybe in some old, hidden systems in some US federal organizations, and not for general public consumption.

Ephemeral DH is quite widely supported. For instance, my own Web server uses the default SSL configuration of Apache+mod_ssl on Ubuntu 16.04, and offers the following protocol versions and cipher suites:

  TLSv1.0:
     server selection: uses client preferences
     3-- (key:  RSA)  RSA_WITH_AES_128_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_CBC_SHA
     3-- (key:  RSA)  RSA_WITH_AES_256_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_CBC_SHA
     3-- (key:  RSA)  RSA_WITH_CAMELLIA_128_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
     3-- (key:  RSA)  RSA_WITH_CAMELLIA_256_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_CBC_SHA
  TLSv1.1: idem
  TLSv1.2:
     server selection: uses client preferences
     3-- (key:  RSA)  RSA_WITH_AES_128_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_CBC_SHA
     3-- (key:  RSA)  RSA_WITH_AES_256_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_CBC_SHA
     3-- (key:  RSA)  RSA_WITH_AES_128_CBC_SHA256
     3-- (key:  RSA)  RSA_WITH_AES_256_CBC_SHA256
     3-- (key:  RSA)  RSA_WITH_CAMELLIA_128_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_CBC_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_CBC_SHA256
     3-- (key:  RSA)  RSA_WITH_CAMELLIA_256_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
     3-- (key:  RSA)  RSA_WITH_AES_128_GCM_SHA256
     3-- (key:  RSA)  RSA_WITH_AES_256_GCM_SHA384
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_GCM_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_GCM_SHA384
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_CBC_SHA256
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_CBC_SHA384
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_GCM_SHA256
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_GCM_SHA384

As you can see, there are quite a lot of DHE suites here. The server's certificate contains a public RSA key, so all the DHE suites are tagged DHE_RSA, which means: "the server sends DH parameters, signed with its RSA key".

Now, that the server offers DHE ciphersuites does not mean that they actually get used. As shown above, my server follows the client preferences, i.e. uses the first ciphersuite it knows of among the list sent by the client, during the initial TLS handshake. Thus, if the client supports DHE and ECDHE ciphersuites, but sends the ECDHE suites first, then the server will choose one of these ECDHE suites.

Moreover, modern Web browsers tend to drop DHE support. On my machine (a macOS Sierra laptop), I have three up-to-date browsers (Chrome, Firefox and Safari), and none of them offers DHE cipher suite support (all happily negotiate ECDHE_RSA if the server supports it, but fall back to plain RSA key exchange if the server does not support ECDHE). In that sense, DHE ciphersuites are an obsolescent feature. Take care that not all TLS is about Web browsers talking to Web servers; there are a lot of applications that also use TLS, and do not necessarily follow the browser trends. Moreover, modern Web browsers are automatically updated, so they are always "cutting edge", while servers and applications can lag for quite some time (many years even). Still, it can be expected that TLS libraries slowly deprecate DHE ciphersuites, or possibly drop support altogether, since ECDHE ciphersuites are more efficient (my own TLS library, for instance, supports ECDH and ECDHE but never supported DH or DHE).

Summary: DHE ciphersuites still work on a number of existing servers, but don't see much usage in practice when clients are Web browsers, and support is expected to dwindle and disappear over time. As you say, indeed, DHE was replaced by ECDHE.

$\endgroup$

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.