Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
enable automatic ECDH and DHE when possible (openssl 1.0.2) #1024
Openssl 1.1.0 and later are enabling ECDH automatically, but for older
Should fix issue #1023
referenced this pull request
Feb 2, 2018
Thanks for the contribution. I think we want ephemeral cipher suites to be enabled by default in general. Not only the elliptic curve variants but RSA-DHE and others. It will be better if your patch will be changed to support those. בתאריך יום ו׳, 2 בפבר׳ 2018 ב-20:14 מאת Enrico Tagliavini < firstname.lastname@example.org>:
Please note I tested this only on CentOS 7 and I was able to connect with cipher ECDHE-RSA-AES256-GCM-SHA384 from xfreerdp client on Fedora 27. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1024 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADTH1KfoWAVyrlAXk_HSniupwc0fgEJVks5tQzvagaJpZM4R3ddk> .
-- Idan Freiberg PGP FP: 8108 7EC9 806E 4980 75F2 72B3 8AD3 2D04 337B 1F18
I understand your point. I'll have a look if I can manage. Although keep in mind DHE and co. are not recommended any longer for modern setups. For example, Mozilla recommends ECDH only .
I have a significant maintenance going on until Tuesday, included, so I will start looking into this after that.
LGTM at least about ECDH.
v0.9.5 + FreeBSD 11-STABLE (OpenSSL 1.0.2k)
this PR + FreeBSD 11-STABLE (OpenSSL 1.0.2k)
Thank you for testing the change on so many platforms!
So I added the DHE (non EC based) support. I'll be honest and say am a bit confused by the docs on it, so I hope what I did is not a giant mistake. I forced the cipher list to be only DHE-RSA-AES256-GCM-SHA384 and I was able to connect after I applied this changes. I was not with the stock version.
There are at least 3 options for the DHE support:
I choose option 1. because it's the simplest for developers, for users and for admins. It just works out of the box without any additional human intervention and you don't risk forgetting a file and having a potential problem hard to sort out (as logs will not mention, it will be completely silent).
I don't like 2. for the reasons explained. I think this kind of stuff should be automatic and require no user intervention like in the case of ECDH, but it's easy to conditionally load the dhparam from the file if the user specify one in the config
Option 3. is the most elaborate solution and that's what apache httpd's mod_ssl uses as far as I understand. This adds a callback function the openssl library will call when it needs a dhparam and they call the standard openssl functions like get_rfc3526_prime_2048 (see  and ).
What do you think? Would that be good enough?
Also feel free to re-generate the key, I get you might not want to trust the first random person on the internet to generate a random safe key. No offense taken if you do :)
Sorry for the later review, but I think we should be 100% sure about this