Hi Lukas, On Sun, May 24, 2015 at 12:41:12PM +0200, Lukas Tribus wrote: > > For 1024, what we could do : > > > > - 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. > > For 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. > therefor > 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. > Also, 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. > As 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. > For the record, I don't think: > openssl 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----- > Its 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. > Btw SSLLabs already provides a test to check for "common DH prime" > numbers. That's nice at least :-) Cheers, Willy
