4
$\begingroup$

Below is a short excerpt of available DH cipher suites available on a machine.

I understand EDH is ephemeral DH, and that ECDH is for Elliptic-Curve DH which is computationally faster. ECDHE is both of those aspects together. The confusing bit how there are EDH cipher suites and DHE suites. The wikipedia article says both acronyms can be used to describe Ephemeral Diffie-Hellman suites, but it also mentions that DHE can stand for "Diffie-Hellman Exchange" which would have no ephemerality. I am very interested in Perfect Forward Secrecy for my application and it is vital that I only use a suite with brief ephemerality. How can I be sure which is which?

ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA
DHE-DSS-AES256-SHA
ECDH-RSA-AES256-SHA
ECDH-ECDSA-AES256-SHA
ECDHE-RSA-DES-CBC3-SHA
ECDHE-ECDSA-DES-CBC3-SHA
EDH-RSA-DES-CBC3-SHA
EDH-DSS-DES-CBC3-SHA
ECDH-RSA-DES-CBC3-SHA
ECDH-ECDSA-DES-CBC3-SHA
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
DHE-DSS-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256
ECDH-RSA-AES128-GCM-SHA256
ECDH-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-RC4-SHA
ECDHE-ECDSA-RC4-SHA
ECDH-RSA-RC4-SHA
ECDH-ECDSA-RC4-SHA
EDH-RSA-DES-CBC-SHA
EDH-DSS-DES-CBC-SHA
EXP-EDH-RSA-DES-CBC-SHA
EXP-EDH-DSS-DES-CBC-SHA
$\endgroup$

2 Answers 2

4
$\begingroup$

Agreeing with @otus but adding more background and context than I think belongs in comments:

This is an OpenSSL question though you don't say so; all other SSL/TLS software I've looked at uses the RFC spellings DHE ECDHE DH_anon ECDH_anon, but OpenSSL was written yonks ago with EDH in some places (mostly the ones dating before ECC was introduced and there was no ECDH to confuse with EDH) and ADH and AECDH in all. You may not have observed the latter two because all unauthenticated suites are disabled by default and very rarely used. So far the devs have been reluctant to "fix" spelling because that could break config files, scripts, calling applications, etc. Especially since OpenSSL cipherstrings are so arcane there seems to be a whole stratum of websites confidently ordaining "the single good way to configure ciphers in openssl or $thing_using_openssl", nearly all of them different and many of them long out of date or completely wrong.

If you look at the cipher details with openssl ciphers -v [$cipherstring] you will see which key-exchange and authentication methods (and also data cipher and MAC) are used for a given ciphersuite. In recent versions if you use -V (cap vee) it also shows the code value sent on the wire, which you can match to the RFCs to be 100% certain it is really the same thing.

A few months ago there was discussion on the maillist about accepting the standard spellings while still preferring the OpenSSL ones. See http://rt.openssl.org/Ticket/Display.html?id=3203 (guest/guest for readonly access); it appears this made it into 1.0.2, currently in beta.

1.0.2 is also planned to add the NON-ephemeral (and non-EC) DH suites. It's not clear if anyone wants or ever used them -- I've certainly never seen any public CA offer DH certs. (Integer DH keys have slightly different encoding than DSA and thus need a different cert, whereas one EC key & cert can be used for either ECDH and ECDSA depending on KeyUsage and technically can be used for both although it is not considered best practice to use one key of any type for multiple purposes.) Adding to otus' correct statement about static-ECDH, static-DH also will not provide PFS.

A more glaring (but non-DH) spelling difference is that OpenSSL names entirely omit "RSA" for plain-RSA key-exchange (not something authenticated by RSA). Also it varies spelling of 3DES. E.g. standard TLS_RSA_WITH_3DES_EDE_CBC_SHA is OpenSSL DES-CBC3-SHA. (Technically EDE is redundant because EEE, the alternative originally considered, was rejected, but putting the 3 after CBC suggests "inner" CBC mode which also was considered but rejected in favor of "outer".)

$\endgroup$
2
$\begingroup$

According to RFC 5246 (and older standards), DHE means ephemeral Diffie–Hellman. EDH isn't a standard way to state it, but it doesn't have another usual meaning.

I.e. all but the ECDH-* ones should have perfect forward secrecy.

However, the export algorithms (EXP-*) are very weak, probably using only 40-bit keys. The other *-DES-CBC-SHA algorithms with 56-bit keys are weak as well, of course. And RC4 isn't the best either... This just to highlight that you shouldn't focus only on forward secrecy.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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