Hacker News new | past | comments | ask | show | jobs | submit login

Is it safe to reuse the same Diffie-Hellman parameter across multiple domains with different certificates/keys?

Not that this generator does it but if you host more than one site, it's more convenient to specify ssl_dhparam (also stapling, ssl_ciphers, etc.) in http{}, and only add certificate/key in server{}.

With TLS, it's not safe not to! Let me explain:

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

This is a fantastic comment! Thank you for posting it.

I'd note that many of us don't have a choice and must still use 1024 bits DHE parameters because of java 6 clients. It's unfortunate, and we hope they go away very very soon so we can upgrade to 2048 bits.

AFAIK the ServerKeyExchange message is signed by the server, and this includes DHE params.

From what I read, yes. Your libssl already comes with a built-in one that's reused almost everywhere. If you want to generate your own, you can make it public, but realistically, if you don't trust your libssl to provide a good dhparam, why trust it to do anything else?

You can reuse the same diffie-hellman parameter. It's a public value anyway.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact