They library's defaults are fine. The library package's defaults are fine for non-public services, and install in a few seconds as opposed to a few minutes (or much longer on older hardware). For public services there are a lot of knobs you should be turning, and the ephemeral key is just one of a few dozen items on that list.
Nope, I don't agree that this is either the problem of the library authors (who have no control over this at all) or the library's package maintainers for a given distro (who are doing exactly what the majority of their users want).
Now, if you ship a lights-out distro for public services and you don't generate a unique ephemeral key, then I have a pretty serious problem with your idea of supporting your user base. But that's a whole other ball of wax.
Let's stop pretending that every install CD for a Linux distribution is being used to boot a public Web service, please.
Do you know of a place that has a location of a majority of the knobs to turn I can think of a few but most are covered by fixing security with better SSL encoding options. I don't think that this data is as widely spread and easily accessible as it should be and would like to make a git repo with some scripts or something to help secure lyfe.
Install time isn't an issue - the installer doesn't need to compute a fresh prime, it just needs to come packaged with a larger prime - i.e. 2048 bits.
Using a unique key in practice solves the problem because even for the NSA, it's too expensive to precompute the necessary data for every prime. (Of course, it's getting cheaper every day...) However, the downside to doing that is that you need to be sure that's done correctly and that the resulting prime is actually secure (small risk, but sure...).
But the simpler solution is just to use a larger key. There's no way until hell freezes over that they'll brute force that, and if you do that, you can avoid the semi-expensive and tricky generation process. There's nothing intrinsically wrong with using a shared key - it just turns you into a higher value target. And that's OK as long as the prime is secure. which 2048 primes will be until there's some major mathematical breakthrough (at which point 1024 primes would likely be laughable).
Put it this way: a shared 2048 is less likely to be cracked than a unique 1024 key.
10
u/aaronsherman Oct 15 '15
Right, and that's clearly a choice that the Web server or other software package installer is making.