Hi Lukas,
Post by Lukas TribusPost by Willy Tarreau- in 1.6 : we wouldn't provide one anymore, which means that users could
only load it from a file they would generate if they need one ;
You are implying that we will provide 2048 bit dhparams, correct?
Yes I still think it has some benefits given *where* admins store their
files (ie: this dhparam is in the config part, it will not be updated
and they're not aware of vulnerabilities requiring an update). I'm not
seeing any other easy way to *distribute* fixes. Keep in mind that most
users simply use their distro's (auto-)update mechanism to stay up to
date and will never even know that a dhparam file lying in their config
directory *needs* to be regenerated.
Post by Lukas TribusPost by Willy TarreauFor 1.6, an alternative could be that we re-compute some groups and put
them into files, or provide the standard ones in files. But that's causing
more moving parts to be deployed and maintained and it could result in the
opposite effect of the desired one : users would store these files in the
config directory, and if one group becomes weak, we couldn't replace it
by delivering a code update, and most users who are not aware of these
issues would never replace their files.
And the problem is already present, because users had to either force 1024
in their config or put a 1024 dhparam into their cert files. All those who
opted for the second option will keep it as-is without ever fixing it, while
the ones who relied on 1024 being forced in the config will automatically
get a different param when they update.
And I'd rather not start to blacklist known fragile dhparams and end up
with a blacklist in the code like openssh does for weak keys...
Its unlikely that we will know when 2048 bit dhparams are broken,
Sure, but when we know it we can force an update on users via the regular
update channels (eg: distro updates). Those relying on their own file are
expected to know what to do.
Post by Lukas Tribustherefor
the best long-term solution imho would be to not include any pre-computed
groups at all.
That's where I disagree from a distribution perspective.
Post by Lukas TribusAlso, I'm not sure if a code upgrade to deal with a compromised dhparam group
is an efficient way to push a new group out there. We would have to see this
as security issue and assign CVE candidates to make package maintainers even
consider a backport.
But that's already how any SSL fix is deployed and I tend to consider
that it works reasonably well, simply because users don't have to care
about anything, they let their system update itself. If any SSL fix
would require a change to openssl.cnf instead of the code, you can bet
it would remain bogus for a much longer duration in field.
Post by Lukas TribusAs with many of the SSL/TLS problems lately, the admin needs to understand
and configure the server according to best pratices. I think we should push
in that direction, even if usability suffers a tiny little bit.
The problem is that SSL/TLS *is* complex and that most users are not
cryptography experts and do not understand a single concept of what is
behind with all those acronyms and numbers. For most people, 1024 is
better than 256 and that's all. From what I've read, an ECDSA-256 key
provides as good a protection as RSA with about 3kbit. Still, for most
readers, RSA-1024 will be 4 times better than ECDSA-256. So we cannot
just rely on the admin becoming skilled in this obscure area, we need
to help them stay safe to avoid the worst mistakes.
Also, lack of usability is always what leads to seek for help and pick
of the wrong solution for most users.
My point of view has always been that people who know must have the final
choice so we need a lot of configurability. But those who don't know
would better be correctly protected than poorly because they copy-pasted
something that was not made for them and that results in their config to
appear as valid.
Post by Lukas Tribusopenssl dhparam 2048>dhparamfile
#grep dh-param-file /etc/haproxy.cfg
tune.ssl.dh-param-file dhparamfile
is hard do document, understand and configure at all.
I know a number of environments where it is difficult to find the openssl
utility, and even worse in the correct version! I'm not kidding! Let alone
that it can take half an hour, you know what will happen ? While it's
running and displaying dots, a number of users will press Ctrl-C, type the
same command on google, find that it is normal that it can take that much
time (even more than they have available), and will lazily copy-paste the
output of the command they found on the page without knowing if there's
any risk in doing that (eg: I've read that if they're created with
-dsaparam, they're weaker and subject to sub-group attacks). And it's easy
to find such examples :
https://github.com/opnsense/core/blob/master/src/etc/dh-parameters.2048
https://github.com/endor/cobot_captive_portal/blob/master/etc/dh-parameters.2048
http://www.opensource.apple.com/source/OpenSSL097/OpenSSL097-16/openssl/crypto/dh/dh2048.pem
Others in 1024 clearly targetted at helping users who were lost in the
process :
http://shanit.blogspot.fr/2010/01/understands-openssl-and-public-key.html
https://forums.openvpn.net/topic13129.html
http://sandilands.info/sgordon/diffie-hellman-secret-key-exchange-with-openssl
And it's easy to add to the confusion, we just have to post here the
output of openssl dhparam -dsaparam 2048 to provide some dhparam 2048
allowing everyone to start their setup without having to wait half an
hour, and wait for it to be indexed, linked and reused :
-----BEGIN DH PARAMETERS-----
MIICDQKCAQEA2txUT4cyK7Y4BMj+M9YNXza0Ge2INzwjl2OaMMlUkaXdMJ7eAGkt
Q/I8QXP61BvC6+5s8Z0etM7obqLntAzRCeSCOXWz+zfmZt7GyjOuFAegXTYydaLD
aQmigcc7ifeXROvq6ouOUnk1p63jaQCkVFhWG8RMZ2CHk/fycCaxrj1nkZeHG0Gw
r5VUGs6nOkphWf4GxdkliwW5eIVSHQd8o2GJRRipGujs2qdRE6XTF6N4mTHofuQO
nsbvfzGopBfRf7MLvR1yF9zqpL5+4HWiI08w96aXI0hN7ACMWJDLYB70Puj5GL6a
yMofoKZ3XbPrHM0HBRfjR+tnAufRdXOllwKCAQA8g2yG3a4hLW2XqbxncMLRWulO
DULr0W7exoka1x1R92/P+VCJOJuStOuL7gLkvwZkdpzvz5iEQn8kMR2d+zlliZdg
89pFfp+i/EOKDig7903m2hRXk8P9+qufonijkHMpY4T1q+MAnZIpyYyGOPtd2+BM
9gl+4Egprj0NWeZ69V3fgcbrlGJjSnamUr8SNqa6anJ9/e/7WoONudsYWlRW0EuT
e+O2w/DdrEhCLdBthLpk1d9dQ8waUpHi42r3Ue1Ldlf01Bbdk2eK58h67s7t4Ydg
grRb1SSppijGdQz2yrbCLQDsyddZOG9vFYQq+WJqW65tAOx5VvEMmqNlj24nAgIA
oA==
-----END DH PARAMETERS-----
Post by Lukas TribusIts an additional
task the admin needs to do, thats correct. But in the long run its the
better thing to do.
I'm not opposed to adding extra tasks to admins provided that it
doesn't become an incentive for falling back to the google search
making things randomly worse. Keep in mind that my point is about
them not knowing that they must regenerate this key, and they'll
clearly not know it, yet alone risk it when they blindly apply a
painful process they don't understand.
On the other hand, I want users to have an easier method than today
when they want to provide their own params, the current process is
not necessarily painless when they have to modify all their PEM files.
Post by Lukas TribusBtw SSLLabs already provides a test to check for "common DH prime"
numbers.
That's nice at least :-)
Cheers,
Willy