Opened 11 years ago
Closed 10 years ago
#410 closed Feature Wish (fixed)
Have to specify "dh" file when using elliptic curve ecdh
Reported by: | ambrice | Owned by: | Steffan Karger |
---|---|---|---|
Priority: | minor | Milestone: | release 2.4 |
Component: | Configuration | Version: | OpenVPN git master branch (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | |
Cc: | Steffan Karger |
Description
Using OpenVPN out of github master branch, commit cab6305b for elliptic curve support.
Created certificate using elliptic curve P-384 keys, using ecdsa-with-SHA384 signature algorithm.
According to README.ec, ECDH parameters are automatically initialized. So I wasn't sure what to do with the "dh" parameter in the config file. If I remove it entirely, I get:
Options error: You must define DH file (--dh)
I tried "dh /dev/zero" but I got an error at startup. I tried creating the file with "openssl ecparam -name secp384r1" and got an error at startup. I had to create a 2048 bit dhparam file to get OpenVPN to start up. On startup, the log shows:
Thu May 29 09:07:10 2014 us=510370 Diffie-Hellman initialized with 2048 bit key
Thu May 29 09:07:10 2014 us=639715 ECDH curve secp384r1 added
I need to make sure that ECDH is used, I'd like to be able to avoid specifying any dhparam file which is hopefully unused anyway..
Change History (5)
comment:1 Changed 11 years ago by
Cc: | Steffan Karger added |
---|---|
Milestone: | → release 2.4 |
Type: | Bug / Defect → Feature Wish |
comment:2 Changed 11 years ago by
Ah, yes. The --dh
option is for 'normal' DH only, it has nothing to do with ECDH. As cron2 said, this is kept required on purpose, because many users just copy a config file from somewhere and expect everything to be secure. Henceforth, it should be hard to misconfigure OpenVPN. So, at least for now, you'll have to feed in a valid dh-file.
To enforce ECDH currently, you could use for example --tls-cipher 'DEFAULT:!EXP:!SRP:!PSK:!kRSA:!DH'
or even enforce the few cipher suites you do trust, like --tls-cipher 'TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384'
(or whatever your client-sever combinations support). Do note that not all ciphers from --show-tls
can actually be used, OpenSSL is unfortunately not very cooperative in compiling a reliable cipher list.
This is indeed rather cumbersome, so I'll accept this ticket as a feature wish and see how we can combine 'fool proof' with 'expert configurable'.
comment:3 Changed 11 years ago by
Owner: | set to Steffan Karger |
---|---|
Priority: | major → minor |
Status: | new → accepted |
comment:4 Changed 11 years ago by
From my perspective of trying to disallow DH it seems like a bug that I'm required to generate dh parameters, and the log shows "Diffie-Hellman initialized with 2048 bit key" even though I have specified only ECDH tls-ciphers.. This does not give me a warm and fuzzy feeling that DH won't end up being used. If you're using AES256 you wouldn't want to see an entry in the log about a DES key being generated..
In that email thread it was suggested to be able to use "--dh none", which was seconded without complaint, so maybe that would be one way to go. It was also mentioned at the end of the thread that if you don't have DH or ECDH, openssl by default will not fall back to RSA key exchange and will instead fail the connection. So maybe it could just be optional then..
Either one of those options seems simple enough that I could post a patch if you'd like, I have the test setup..
comment:5 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
This feature wish has actually already been incorporated into master:
https://github.com/OpenVPN/openvpn/commit/bd9aa06
So, closing this ticket.
There was a lengthy discussion about this on the openvpn-devel list a few months ago. If I remeber things correctly, the end result was that we want to avoid people shooting off their feet by omitting the DH file and then a client doesn't use ECDH, for whatever reason, falling back to something weak in the end.
Copying in syzzer, he can phrase this better :-)
But it's definitely not a bug. We can file it as "feature request", though.