Add/Test ECDSA support

[kylemanna]

Add/test elliptic curve support when upstream OpenVPN releases it. Upstream commit

EasyRSA 3.0-rc1 has the ability to generate certs with EASYRSA_ALGO=ec set in the environment.

[george-angel]

@kylemanna Is it possible to revisit this? Very keen on ed25519 support. Thank you.

[kylemanna]

Haven't looked, has ed25519 support been added?

[george-angel]

Apologies, looks like it hasn't ((

https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-cipher

Today, OpenVPN does not support TLS-ECDHE-* or more exotic cipher-suites as there is no elliptic curve support currently.

[kylemanna]

No worries, was hoping things had progressed!

[ragaar]

Just an FYI, I think this might have been updated^[1]:

To use ECDH(E) or ECDSA cipher-suites, both client and server must be OpenVPN 2.4.0 or newer.

I don't see anything on the page @george-angel shared that highlights elliptic curves are not supported.

 

REFERENCE:

1. https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-cipher

[andgeno]

I'd also like to have support for Elliptic Curves for TLS ciphers.

[chepurko]

OpenVPN has supported NIST P-384 curves since 2.4 or so. All you have to do is this:

$ docker run -e EASYRSA_ALGO=ec -e EASYRSA_CURVE=secp384r1 \ 
    --net=none --rm -it -v $PWD:/etc/openvpn kylemanna/openvpn ovpn_initpki

Note this is for the CA key. For clients, keep in mind that some devices, especially with hardware-backed storage, don't support ECC keys so for those you will have to generate good 'ol RSA keys. From my experience the Nexus 5 and Chromebook Pixel 2 hardware-backed storage only take RSA keys. You can always just stick the ECC keys on regular storage if you want and it should work fine.

Otherwise all other modern clients support ECC keys. If the client requires RSA keys just use:

$ docker run -e EASYRSA_KEY_SIZE=4096 \
    --net=none --rm -it -v $PWD:/etc/openvpn kylemanna/openvpn easyrsa build-client-full CLIENTNAME

An ECC CA key can sign an RSA key no problem and will give you the client certificate.

[chepurko]

I'm just confirming that this works when you use the alpine:edge image because the repository there uses OpenVPN 2.4.1.

[andgeno]

Works for me, too! 😃 Thanks @chepurko for pointing this out.

[chepurko]

I wonder if this image could be bumped to the latest stable OpenVPN, which is 2.4.1 by now, either by bumping up to the alpine:edge image or by doing a more complex download-and-compile of the OpenVPN source.

Openvpn 2.4.1 also has the cool --tls-crypt feature which encrypts instead of just authenticating the control channel (replacement for --tls-auth). Something that would go into the "Paranoid" documentation as well :smile:.

[kylemanna]

@chepurko Will anything break if we upgrade to 2.4.1 with existing installs? In particular I'm curious about your PR about double quotes.

We may need to provide a mechanism to hotpatch the existing configs at start-up.

[chepurko]

@kylemanna I'm working this fork live right now. Take out the bit about disabling IPv6 (this doesn't work on Kubernetes) and all I did was change the base image and add the quotes in the hacky way that I'll fix after correcting my PR.

As far I can see all current (v2.3) configs are compatible with v2.4. v2.4 shouldn't break any (except maybe double quotes in push options).

No errors on my setup whatsoever. But why don't I finish my current PR and make a new one bumping the base image to edge and we'll test step-by-step?

[andgeno]

I can confirm that all I had to do on my side was to add that double quoting fix. I implemented it directly into the process_push_config function.

[[ -n "$ovpn_push_config" ]] && echo "push \"$ovpn_push_config\"" >> "$TMP_PUSH_CONFIGFILE"

[kylemanna]

I think if we want to jump to OpenVPN 2.4.x ahead of Alpine, we should create a new git branch and Docker image tag so that the people in this issue can test (and report back issues) and then we can schedule to merge it in to master. I can get this rolling following @chepurko's updated PR with the revised quoting.

There are far too many people using this Docker image these days to change it on master without some testing.

[chepurko]

@kylemanna for sure

@andgeno thanks, I added that to the PR

[kylemanna]

Anyone wanting 2.4 support, please provide comments on issue #267