Mozilla SSL Configuration Generator (opens in new tab)

Diffie-Hellman requires the group order to have at least one large prime factor: if it has only small prime factors, Silver–Pohlig–Hellman could recover keys, and that'll make you a sad panda. The easiest way to ensure this is to select a Sophie Germain prime q with 2q+1 also being prime (a "safe prime"), of about the right size. Any base g can then be used - almost always 2 - which then generates a subgroup of large prime order q, problem solved.

The problem is that testing for safe primality is way too slow (as you may have noticed while running openssl dhparam!) for TLS clients to test DHE parameters presented to them. So… they don't. The risk is (I'm not totally clear if the Finished master-secret might prevent this, but there certainly isn't as much transcript hashing as I'd like!) an attacker could perhaps trick TLS parties into accepting bad parameters: too small; small factors; hell, maybe even composite.

The solution is currently in draft, and is to have carefully-selected, standard Diffie-Hellman parameters that are known safe primes, starting from 2048-bit and going up (don't use <2048-bit, just… don't - please don't use 1024-bit!), using essentially the same negotiation as that used with the supported-curves extension. https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-f... It's the same approach used by many other protocols, including SSH and IKE.

I gather TLS 1.3 will remove the ability for server-defined Diffie-Hellman parameters completely for this reason.

However, ECDHE is strongly technically superior to DHE: ECDHE using secp256r1 is at around ≈128-bit workfactor, equivalent to broadly ≈3072-bit DHE, but is much faster and smaller and doesn't have these problems (it can have different problems, but not these problems!).

And coming up soon (via the CFRG sausage-machine) hopefully TLS will soon have djb's Curve25519 (the curve, and the key agreement function now known as X25519), which is roughly the same ≈128-bit strength but really fast - and much simpler to safely implement, even in constant-time. You probably want to use that or ECDHE, not DHE, which is a little hairier than it sounds. Indeed, quite a few people are using it already (notably OpenSSH).

edit: i submitted issue #38 for a ui improvement. https://github.com/mozilla/server-side-tls/issues/38

Also: SSLv3 and TLSv1 are very similar: http://tim.dierks.org/2014/05/security-standards-and-name-ch...

Apache

SSLProtocol all -SSLv2 -SSLv3 -TLSv1

SSLCipherSuite ECDHE-RSA-AES1....

Nginx

ssl_protocols TLSv1.1 TLSv1.2;

ssl_ciphers 'ECDHE-RSA-AES....'

HAProxy

ssl-default-bind-ciphers ECDHE-RSA-....

    $ ./cipherscan jve.linuxwall.info
    ........................
    Target: jve.linuxwall.info:443

    prio  ciphersuite                  protocols              pfs                 curves
    1     ECDHE-RSA-AES128-GCM-SHA256  TLSv1.2                ECDH,P-384,384bits  secp384r1
    2     ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2                ECDH,P-384,384bits  secp384r1
    3     DHE-RSA-AES128-GCM-SHA256    TLSv1.2                DH,2048bits         None
    4     DHE-RSA-AES256-GCM-SHA384    TLSv1.2                DH,2048bits         None
    5     ECDHE-RSA-AES128-SHA256      TLSv1.2                ECDH,P-384,384bits  secp384r1
    6     ECDHE-RSA-AES128-SHA         TLSv1,TLSv1.1,TLSv1.2  ECDH,P-384,384bits  secp384r1
    7     ECDHE-RSA-AES256-SHA384      TLSv1.2                ECDH,P-384,384bits  secp384r1
    8     ECDHE-RSA-AES256-SHA         TLSv1,TLSv1.1,TLSv1.2  ECDH,P-384,384bits  secp384r1
    9     DHE-RSA-AES128-SHA256        TLSv1.2                DH,2048bits         None
    10    DHE-RSA-AES128-SHA           TLSv1,TLSv1.1,TLSv1.2  DH,2048bits         None
    11    DHE-RSA-AES256-SHA256        TLSv1.2                DH,2048bits         None
    12    DHE-RSA-AES256-SHA           TLSv1,TLSv1.1,TLSv1.2  DH,2048bits         None
    13    AES128-GCM-SHA256            TLSv1.2                None                None
    14    AES256-GCM-SHA384            TLSv1.2                None                None
    15    AES128-SHA256                TLSv1.2                None                None
    16    AES256-SHA256                TLSv1.2                None                None
    17    AES128-SHA                   TLSv1,TLSv1.1,TLSv1.2  None                None
    18    AES256-SHA                   TLSv1,TLSv1.1,TLSv1.2  None                None
    19    DHE-RSA-CAMELLIA256-SHA      TLSv1,TLSv1.1,TLSv1.2  DH,2048bits         None
    20    CAMELLIA256-SHA              TLSv1,TLSv1.1,TLSv1.2  None                None
    21    DHE-RSA-CAMELLIA128-SHA      TLSv1,TLSv1.1,TLSv1.2  DH,2048bits         None
    22    CAMELLIA128-SHA              TLSv1,TLSv1.1,TLSv1.2  None                None
    23    DES-CBC3-SHA                 TLSv1,TLSv1.1,TLSv1.2  None                None

    Certificate: trusted, 2048 bit, sha256WithRSAEncryption signature
    TLS ticket lifetime hint: 300
    OCSP stapling: supported
    Cipher ordering: server

A single core process won't be able to keep up with SSL handshakes though, since one core can only do around 500 RSA 2048-bit sign/s. Session resumption will help a lot, but I would still want to distribute RSA operations over multiple cores.

Unfortunately, mediawiki only support two levels of access control: fully locked or fully open, so I need to manually police changes as they happen...

(If it's intentional they could WONTFIX The bug)

That said, I have used them as a starting point to get A+ on the SSLLabs test.