[Openvpn-devel] [PATCH 1/2] Add support for elliptic curve diffie-hellmann key exchange (ECDH)

[Steffan Karger]

This patch is based on Jan Just Keijser's patch from Feb 7, 2012.

When OpenSSL 1.0.2 or newer is used, lets OpenSSL do the heavy lifting.

Otherwise, tries the following things (in order of preference):
 * When supplied, use the ecdh curve specified by the user.
 * Try to extract the curve from the private key, use the same curve.
 * Fall back on secp384r1 curve.

Note that although the curve lookup succeeds, OpenSSL 1.0.0 and older do
*not* support TLSv1.1 or TLSv1.2, which means no that no EC-crypto can be
used.

This patch also bumps the minimum required OpenSSL version to 0.9.8,
because older version do not have all the functions used and would require
adding (more) #ifdefs.

Signed-off-by: Steffan Karger 
---
 README.ec  |  37 
 configure.ac   |   4 +-
 doc/openvpn.8  |  14 ++
 src/openvpn/init.c |   4 +-
 src/openvpn/options.c  |  11 +
 src/openvpn/options.h  |   2 +
 src/openvpn/ssl.c  |   4 ++
 src/openvpn/ssl_backend.h  |  15 +++
 src/openvpn/ssl_openssl.c  | 107 +
 src/openvpn/ssl_polarssl.c |  13 ++
 10 files changed, 208 insertions(+), 3 deletions(-)
 create mode 100644 README.ec

diff --git a/README.ec b/README.ec
new file mode 100644
index 000..bea3ce1
--- /dev/null
+++ b/README.ec
@@ -0,0 +1,37 @@
+Since 2.4.0, OpenVPN has official support for elliptic curve crypto. Elliptic
+curves are an alternative to RSA for asymmetric encryption.
+
+Elliptic curve crypto ('ECC') can be used for the ('TLS') control channel only
+in OpenVPN; the data channel (encrypting the actual network traffic) uses
+symmetric encryption. ECC can be used in TLS for authentication (ECDSA) and key
+exchange (ECDH).
+
+Note: ECC is available in OpenSSL builds of OpenVPN only. ECC for PolarSSL
+builds will follow soon.
+
+Key exchange (ECDH)
+---
+OpenVPN 2.4.0 and newer automatically initialize ECDH parameters. When ECDSA is
+used for authentication, the curve used for the server certificate will be used
+for ECDH too. When autodetection fails (e.g. when using RSA certificates)
+OpenVPN falls back to the secp384r1 curve.
+
+An administrator can force an OpenVPN server to use a specific curve using the
+--ecdh-curve  option with one of the curves listed as available by
+the --show-curves option. Clients will use the same curve as selected by the
+server.
+
+Note that not all curves listed by --show-curves are available for use with 
TLS;
+in that case connecting will fail with a 'no shared cipher' TLS error.
+
+Authentication (ECDSA)
+--
+Since OpenVPN 2.4.0, using ECDSA certificates works 'out of the box'. Which
+specific curves and cipher suites are available depends on your version and
+configuration of the crypto library. The crypto library will automatically
+select a cipher suite for the TLS control channel.
+
+Support for generating an ECDSA certificate chain is available in EasyRSA (in
+spite of it's name) since EasyRSA 3.0. The parameters you're looking for are
+'--use-algo=ec' and '--curve='. See the EasyRSA documentation for
+more details on generating ECDSA certificates.
diff --git a/configure.ac b/configure.ac
index 380dcdb..4225343 100644
--- a/configure.ac
+++ b/configure.ac
@@ -744,7 +744,7 @@ PKG_CHECK_MODULES(

 PKG_CHECK_MODULES(
[OPENSSL_CRYPTO],
-   [libcrypto >= 0.9.6],
+   [libcrypto >= 0.9.8],
[have_openssl_crypto="yes"],
[AC_CHECK_LIB(
[crypto],
@@ -758,7 +758,7 @@ PKG_CHECK_MODULES(

 PKG_CHECK_MODULES(
[OPENSSL_SSL],
-   [libssl >= 0.9.6],
+   [libssl >= 0.9.8],
[have_openssl_ssl="yes"],
[AC_CHECK_LIB(
[ssl],
diff --git a/doc/openvpn.8 b/doc/openvpn.8
index d01c935..ce8d09c 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -4240,6 +4240,13 @@ included with the OpenVPN distribution.  Diffie Hellman 
parameters
 may be considered public.
 .\"*
 .TP
+.B \-\-ecdh-curve name
+Specify the curve to use for elliptic curve Diffie Hellman. Available
+curves can be listed with
+.B \-\-show-curves
+. The specified curve will only be used for ECDH TLS-ciphers.
+.\"*
+.TP
 .B \-\-cert file
 Local peer's signed certificate in .pem format \-\- must be signed
 by a certificate authority whose certificate is in
@@ -5021,6 +5028,13 @@ lowest.
 Show currently available hardware-based crypto acceleration
 engines supported by the OpenSSL library.
 .\"*
+.TP
+.B \-\-show-curves
+(Standalone)
+Show all available elliptic curves to use with the
+.B \-\-ecdh-curve
+option.
+.\"*
 .SS Generate a random key:
 Used only for non-TLS static key encryption mode.
 

[Openvpn-devel] [PATCH 2/2] Add an elliptic curve testing cert chain to the sample keys

[Steffan Karger]

Signed-off-by: Steffan Karger 
---
 sample/sample-keys/README|  6 ++--
 sample/sample-keys/ec-ca.crt | 13 +
 sample/sample-keys/ec-ca.key |  6 
 sample/sample-keys/ec-client.crt | 61 
 sample/sample-keys/ec-client.key |  6 
 sample/sample-keys/ec-server.crt | 61 
 sample/sample-keys/ec-server.key |  6 
 7 files changed, 156 insertions(+), 3 deletions(-)
 create mode 100644 sample/sample-keys/ec-ca.crt
 create mode 100644 sample/sample-keys/ec-ca.key
 create mode 100644 sample/sample-keys/ec-client.crt
 create mode 100644 sample/sample-keys/ec-client.key
 create mode 100644 sample/sample-keys/ec-server.crt
 create mode 100644 sample/sample-keys/ec-server.key

diff --git a/sample/sample-keys/README b/sample/sample-keys/README
index 1cd473a..9f4f918 100644
--- a/sample/sample-keys/README
+++ b/sample/sample-keys/README
@@ -1,7 +1,6 @@
-Sample RSA keys.
+Sample RSA and EC keys.

-See the examples section of the man page
-for usage examples.
+See the examples section of the man page for usage examples.

 NOTE: THESE KEYS ARE FOR TESTING PURPOSES ONLY.
   DON'T USE THEM FOR ANY REAL WORK BECAUSE
@@ -12,3 +11,4 @@ client.{crt,key} -- sample client key/cert
 server.{crt,key} -- sample server key/cert (nsCertType=server)
 pass.{crt,key}   -- sample client key/cert with password-encrypted key
 password = "password"
+ec-*.{crt,key}   -- sample elliptic curve variants of the above
diff --git a/sample/sample-keys/ec-ca.crt b/sample/sample-keys/ec-ca.crt
new file mode 100644
index 000..e190801
--- /dev/null
+++ b/sample/sample-keys/ec-ca.crt
@@ -0,0 +1,13 @@
+-BEGIN CERTIFICATE-
+MIIB4jCCAWmgAwIBAgIJALGEGB2g6cAXMAoGCCqGSM49BAMCMBUxEzARBgNVBAMT
+CkVDLVRlc3QgQ0EwHhcNMTQwMTE4MTYwMTUzWhcNMjQwMTE2MTYwMTUzWjAVMRMw
+EQYDVQQDEwpFQy1UZXN0IENBMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAE2S4AZT7j
+ZlPG/CXpT12CzCNSySyKmJt+fWyW/wzbRulVJpGHXRHpZZj2VNOUE72kqGUeshh6
+Um1o7lHGDSAkHOJpeW5FtryiKhwFc+4dsOCLTNLVFXQsEtY3gY14Uquio4GEMIGB
+MB0GA1UdDgQWBBS0mkFcuCZ8SLWZRAD/8LpBQcgGPDBFBgNVHSMEPjA8gBS0mkFc
+uCZ8SLWZRAD/8LpBQcgGPKEZpBcwFTETMBEGA1UEAxMKRUMtVGVzdCBDQYIJALGE
+GB2g6cAXMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMAoGCCqGSM49BAMCA2cA
+MGQCMHWlVTi0xNZstR8ZNH+7z0WlyIXyZe23ne3EXkO0thZLdv86kpxFMPW/llB+
+RMRKuQIweN97n7FQy5DTenr91U98KDFJ5Av4mDFRL1mkXiu3W1//4XD8yEYDQTRz
+/GARuOLL
+-END CERTIFICATE-
diff --git a/sample/sample-keys/ec-ca.key b/sample/sample-keys/ec-ca.key
new file mode 100644
index 000..51a72e1
--- /dev/null
+++ b/sample/sample-keys/ec-ca.key
@@ -0,0 +1,6 @@
+-BEGIN PRIVATE KEY-
+MIG2AgEAMBAGByqGSM49AgEGBSuBBAAiBIGeMIGbAgEBBDASU6X/mh2m2PayviL3
+teoml5soyIUcZfwZpVn6oNtnrLcAbIRsAJbM4xyGVp77G/6hZANiAATZLgBlPuNm
+U8b8JelPXYLMI1LJLIqYm359bJb/DNtG6VUmkYddEellmPZU05QTvaSoZR6yGHpS
+bWjuUcYNICQc4ml5bkW2vKIqHAVz7h2w4ItM0tUVdCwS1jeBjXhSq6I=
+-END PRIVATE KEY-
diff --git a/sample/sample-keys/ec-client.crt b/sample/sample-keys/ec-client.crt
new file mode 100644
index 000..9372800
--- /dev/null
+++ b/sample/sample-keys/ec-client.crt
@@ -0,0 +1,61 @@
+Certificate:
+Data:
+Version: 3 (0x2)
+Serial Number: 2 (0x2)
+Signature Algorithm: ecdsa-with-SHA256
+Issuer: CN=EC-Test CA
+Validity
+Not Before: Jan 18 16:02:37 2014 GMT
+Not After : Jan 16 16:02:37 2024 GMT
+Subject: CN=ec-client
+Subject Public Key Info:
+Public Key Algorithm: id-ecPublicKey
+Public-Key: (384 bit)
+pub: 
+04:40:d9:b9:a2:44:1b:01:39:2c:14:ee:aa:70:6b:
+31:98:28:44:c9:61:bc:b7:0b:b5:53:49:c2:c0:0a:
+43:b0:08:50:cd:80:2f:5d:a4:89:f1:ff:7d:11:78:
+f5:0c:b2:86:e2:59:f8:17:76:1b:22:f2:23:67:e7:
+55:90:ea:ce:0a:aa:da:05:f4:85:19:c9:ed:ae:6d:
+a3:ad:56:7a:f6:33:c6:cf:bb:c7:39:fa:e4:d3:67:
+df:f0:b8:4a:88:57:98
+ASN1 OID: secp384r1
+X509v3 extensions:
+X509v3 Basic Constraints: 
+CA:FALSE
+X509v3 Subject Key Identifier: 
+D8:E2:35:7B:CA:66:71:6B:D8:5B:F5:12:13:82:2D:ED:CD:E5:ED:7F
+X509v3 Authority Key Identifier: 
+
keyid:B4:9A:41:5C:B8:26:7C:48:B5:99:44:00:FF:F0:BA:41:41:C8:06:3C
+DirName:/CN=EC-Test CA
+serial:B1:84:18:1D:A0:E9:C0:17
+
+X509v3 Extended Key Usage: 
+TLS Web Client Authentication
+X509v3 Key Usage: 
+Digital Signature
+Netscape Comment: 
+Easy-RSA Generated Certificate
+Netscape Cert Type: 
+SSL Client
+Signature Algorithm: ecdsa-with-SHA256
+ 30:64:02:30:41:8b:1a:fd:97:a8:bb:7c:d0:eb:1c:a2:ba:c0:
+ ac:2f:6d:80:07:5b:5c:ef:55:59:1a:92:56:66:94:ce:49:6a:
+   

[Openvpn-devel] [PATCH] Add ECDH support for OpenSSL builds of OpenVPN

[Steffan Karger]

Hi,

Thanks to Piotr's contributions on the mailing list I picked up my earlier
ECDH work again. I believe they are ready to be reviewed and find their way
into master.

The following patches add support for ECDH(E) in OpenSSL builds, which in
practice means that people are able to use ECDSA certificate chains without
jumping through hoops, or just use ECDH(E) with their RSA certificates.

I started with the patch Jan Just Keijser posted (and reposted) to the
openvpn-devel list earlier, and worked from there to make the behaviour
TLS-compliant (i.e, extract the curve from the server key by default).

For OpenSSL 1.0.2+, we can let OpenSSL do the heavy lifting.

For older versions (which are at this moment used by almost everyone), we have
to select a curve ourselves. If dynamic selection fails, we fall back to the
strongest 'Suite B' curve: secp384r1.

For more details, check the commit messages from the patches, and README.ec.

A patch to add EC support for PolarSSL builds will follow soon.

Regards,
-Steffan

Re: [Openvpn-devel] [Patch] ECDH support

[Steffan Karger]

Hi,

On 25-02-14 22:49, Jan Just Keijser wrote:
> read up on the original ticket too:
>   https://forums.openvpn.net/topic8404-30.html
> 
> there's some useful commands/description in there on how to generate
> ECDSA certificates.

Thanks. I've added support for ECDSA to EasyRSA 3 a little while ago, so
that should simplify the certificate generation a lot.

-Steffan

Re: [Openvpn-devel] [Patch] ECDH support

[Jan Just Keijser]

Hi Steffan,

On 25/02/14 09:48, Steffan Karger wrote:

Hi,

On Tue, Feb 25, 2014 at 9:22 AM, Gert Doering > wrote:


> Although there is apparently more work to do to get more cipher
suites
> working, this does give us a start on working with EC-crypto.
Maybe this
> part can go in (once ACK'ed) as 'the start of EC-support', so more
> people can help improve the code. Any other opinions on this?

- easy to understand and a bit more detailed README
- ACK from a "trusted contributor" (read: someone who has worked
on the
  OpenVPN crypto code before and knows the pitfalls)

then I'm fine with it


As for the README part, I can probably cook up something 'tonight' 
(CEST). The ACK can obviously not come from me, but I'll try to make 
the patch as easy as possible to review.


- PolarSSL...?


ECDH and ECDSA will work upon upgrade to PolarSSL 1.3, for which I'll 
send patches soon.




read up on the original ticket too:
  https://forums.openvpn.net/topic8404-30.html

there's some useful commands/description in there on how to generate 
ECDSA certificates.


HTH,

JJK

Re: [Openvpn-devel] [Patch] ECDH support

[Steffan Karger]

Hi,

On Tue, Feb 25, 2014 at 9:22 AM, Gert Doering  wrote:

> > Although there is apparently more work to do to get more cipher suites
> > working, this does give us a start on working with EC-crypto. Maybe this
> > part can go in (once ACK'ed) as 'the start of EC-support', so more
> > people can help improve the code. Any other opinions on this?
>
> - easy to understand and a bit more detailed README
> - ACK from a "trusted contributor" (read: someone who has worked on the
>   OpenVPN crypto code before and knows the pitfalls)
>
> then I'm fine with it
>

As for the README part, I can probably cook up something 'tonight' (CEST).
The ACK can obviously not come from me, but I'll try to make the patch as
easy as possible to review.

- PolarSSL...?


ECDH and ECDSA will work upon upgrade to PolarSSL 1.3, for which I'll send
patches soon.

-Steffan

Re: [Openvpn-devel] [Patch] ECDH support

[Gert Doering]

Hi,

On Tue, Feb 25, 2014 at 01:39:11AM +0100, Steffan Karger wrote:
> > I added warning if DH isn't specified - old client may not support ECDH.
> > Autodetecting ecdh is a good idea - I made option ecdh=auto.
> 
> On the long run I agree that a warning should suffice, but for now I
> would really like to stick with forcing the DH-file to be present. Lots
> of people using OpenVPN do not understand the crypto or configuration
> options properly, but do rely on it for secure communication. As long as
> EC-crypto is not common, I prefer to make sure OpenVPN can always fall
> back on DH.

+1

[..]
> Although there is apparently more work to do to get more cipher suites
> working, this does give us a start on working with EC-crypto. Maybe this
> part can go in (once ACK'ed) as 'the start of EC-support', so more
> people can help improve the code. Any other opinions on this?

- easy to understand and a bit more detailed README
- ACK from a "trusted contributor" (read: someone who has worked on the
  OpenVPN crypto code before and knows the pitfalls)

then I'm fine with it

- PolarSSL...?

gert

-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgp4012OUpveL.pgp
Description: PGP signature

Re: [Openvpn-devel] [Patch] ECDH support

[Steffan Karger]

Hi Piotr,

On 24-02-14 01:28, pietrek -- wrote:
> Hi Steffan,
> I modified my patch again. And thanks for your code - it helped me.

Good to hear it helped you. But your new patch basically is my code now,
except that it accepts a configuration without a DH-file.

> 1) In such case server will set ecdh=auto.
> 2)That's a good idea.
> I added initializing both ECDH and DH on server side if they're
> specified in config.

Good.

> 3)It works for me without specifying anything on client side.
> I can also specify different curve for ECDH than used in certificates
> without any errors.

You're completely right, sorry for putting you on this side track.

> I added warning if DH isn't specified - old client may not support ECDH.
> Autodetecting ecdh is a good idea - I made option ecdh=auto.

On the long run I agree that a warning should suffice, but for now I
would really like to stick with forcing the DH-file to be present. Lots
of people using OpenVPN do not understand the crypto or configuration
options properly, but do rely on it for secure communication. As long as
EC-crypto is not common, I prefer to make sure OpenVPN can always fall
back on DH.

> Most of the curves secp, prime, sect work, but some of them ( eg.
> wap-wsg-idm-ecid-wtls10 ) cause ssl error 'no shared cipher'.
> 
> Working curves examples:
> ...
> 
> Failing examples:
> ...

Not all curves supported by OpenSSL are available for use in SSL/TLS,
wap-wsg-idm-ecid-wtls10 sounds like a perfect example of that.
Furthermore, the available curves depend on you version and
configuration of OpenSSL.

One of the things I do not completely grasp yet is why some cipher
suites succeed (e.g. TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA works for me),
but some slightly different ones do not (e.g.
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384 and
TLS-ECDH-ECDSA-WITH-AES-256-CBC-SHA do not work for me), even though all
the primitives for those suites are available from the version of
OpenSSL I'm using. Still, the behaviour is different for various OpenSSL
versions. Have you stumbled across this already?

> I also copied from your code option --show-curves, manual entries and EC
> curve autodetection.

Credits for those lines go to Jan Just actually. About the copying,
wouldn't it make more sense if you'd review my implementation, instead
of copying it? The bulk of it is my code now anyway.

Although there is apparently more work to do to get more cipher suites
working, this does give us a start on working with EC-crypto. Maybe this
part can go in (once ACK'ed) as 'the start of EC-support', so more
people can help improve the code. Any other opinions on this?

Regards,
-Steffan