[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 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 PolarSSL is used, lets the crypto library do the
heavy lifting. For OpenSSL builds, if a user specifies a curve using
--ecdh-curve, it first tries to override automatic selection using that
curve.

For older OpenSSL, 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 a curve lookup might succeed, OpenSSL 1.0.0 and older do
*not* support TLSv1.1 or TLSv1.2, which means no that no EC-crypto can be
used.

Signed-off-by: Steffan Karger 
---
 README.ec  |  35 ++
 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  | 116 +
 src/openvpn/ssl_polarssl.c |  26 ++
 9 files changed, 226 insertions(+), 1 deletion(-)
 create mode 100644 README.ec

diff --git a/README.ec b/README.ec
new file mode 100644
index 000..3293801
--- /dev/null
+++ b/README.ec
@@ -0,0 +1,35 @@
+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).
+
+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 lets the crypto library decide if possible, or falls back to the
+secp384r1 curve.
+
+An administrator can force an OpenVPN/OpenSSL 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/doc/openvpn.8 b/doc/openvpn.8
index 3a58317..b7d6a3d 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -4246,6 +4246,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
@@ -5027,6 +5034,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.
 .\"*
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index c2907cd..467b98a 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -871,7 +871,7 @@ print_openssl_info (const struct options *options)
 #ifdef ENABLE_CRYPTO
   if (options->show_ciphers || options->show_digests || options->show_engines
 #ifdef ENABLE_SSL
-  || options->show_tls_ciphers
+  || options->show_tls_ciphers || options->show_curves
 #endif
 )
 {
@@ -884,6 +884,8 @@ print_openssl_info (const struct options *options)
 #ifdef ENABLE_SSL
   if (options->show_tls_ciphers)
show_available_tls_ciphers (options->cipher_list);
+  if 

[Openvpn-devel] [PATCH v2] ECDH support (both OpenSSL and PolarSSL now)

[Steffan Karger]

Hi,

As discussed earlier today, updated patches for ECDH support. See
http://article.gmane.org/gmane.network.openvpn.devel/8308 for the previous
version.

These patches comprise two changes:
1) Because the PolarSSL 1.3 patches have been merged, I updated the code and
   docs to reflect that PolarSSL builds have EC-crypto support too. PolarSSL
   does not support forcing an ECDH curve like OpenSSL does, it can merely
   restrict the available curves.

2) Add #ifdefs around the OpenSSL EC-crypto code, because some distros
   (notably, RHEL) ship with OpenSSL libraries without EC-crypto.

-Steffan

Re: [Openvpn-devel] [PATCH 2/4] Added PIP_OPT_MASK for process_ip_header fast exit path.

[James Yonan]

On 23/04/2014 04:17, Arne Schwabe wrote:

Am 21.04.14 21:26, schrieb James Yonan:

On 21/04/2014 05:27, Arne Schwabe wrote:

On 21.04.2014 09:10, James Yonan wrote:

Define PIP_OPT_MASK to represent all flags of interest to
process_ip_header, so that it can have a fast exit path
if no flags are set.


I haven't look at the code but if remember  correctly, this method does
not get passed the actual flags but the flags should *potientially* be
checked.


Yes, the point is to aggregate the potential flags of interest to
process_ip_header under a single mask, i.e. PIP_OPT_MASK.

So instead of having "if (flags & (PIPV4_PASSTOS|PIP_MSSFIX|...|...))"
you just have "if (flags & PIP_OPT_MASK)".

The main issue for us is that we have an internal patch for one of our
services that adds an additional flag, and the previous usage is a
merge conflict attractor because all the flags of interest are
explicitly given on a single line.


I only wanted to point out my patch also exits. I looked at the code again.

I think to really get rid of the #ifdef here we also need to
unconditionally enable the other &= ~ statements:

Change

#if PASSTOS_CAPABILITY
   if (!c->options.passtos)
 flags &= ~PIPV4_PASSTOS;
#endif

to

#if PASSTOS_CAPABILITY
   if (!c->options.passtos)
#endif
 flags &= ~PIPV4_PASSTOS;


Otherwise if the function is called with PIPV4_PASSTOS but not compiled
with PASSTOS_CAPABILITY the

flags & PIP_OPT_MASK will be always true.

Arne


Sure, that makes sense.

James

Re: [Openvpn-devel] Progress on Version negotiation

[Steffan Karger]

Hi,

On 23-04-14 17:36, Timothe Litt wrote:
> Just to confirm that the issue is 1.2, not the negotiation:
> 
> I added an unconditional
>   sslopt |= SSL_OP_NO_TLSv1_2;
>  in tls_ctx_set_options.
> 
> With this (and the context initialized to SSL_v23_*_method, so we
> negotiate), the tunnel comes up.
> Without it, the tunnel does not come up.
> 
> So it is the use of 1.2 that is the issue, not how it is selected.

Good, this gives us a better starting point (and can make a temporary
fix less intrusive).

> I generated a matching pair of traces of the failure (client and server)
> & posted a summary.
> 
> Let me know if you would like the full traces.

Yes please. You seem to have isolated the relevant parts, but just maybe
I can spot something.

> This is 100% reproducible here, so let me know if you need more
> instrumentation. (However, I can't build a windows client, so if that's
> necessary, you'll have to build it for me to run.)

I've been trying to reproduce the error. I grabbed my spare pi from the
desk drawer and built 2.3.3 from sources like you describe in #385. I
fired up a Windows 8.1 VM, and installed OpenVPN 2.3.3-I002 (x64). This
setup however happily connects with TLSv1.2. It's hard to get a hold on
this one...

-Steffan

Re: [Openvpn-devel] Progress on Version negotiation

[Gert Doering]

Hi,

On Wed, Apr 23, 2014 at 01:27:19PM -0400, Timothe Litt wrote:
> >now - does that sound like it could be the problem?  The initial handshake
> >packet "under some conditions" (like: the local OpenSSL build having
> >more available ciphers, depending on how it was built) being too big,
> >causing "surprises"?
> As I have noted, we're well past the client hello, so:
>You are right that the number of ciphers does effect the hello size.
>But if that was involved here, we should fail much sooner.

OK, right.  Sorry for wasting time here.  I said I'm not the crypto
expert...  just something I've come across before.

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


pgpLqCdaKx7Ws.pgp
Description: PGP signature

Re: [Openvpn-devel] Progress on Version negotiation

[Timothe Litt]

Gert,


while cycling home from $paidwork

Cycling while thinking about TLS might be as bad as texting while driving...


now - does that sound like it could be the problem?  The initial handshake
packet "under some conditions" (like: the local OpenSSL build having
more available ciphers, depending on how it was built) being too big,
causing "surprises"?

As I have noted, we're well past the client hello, so:
   You are right that the number of ciphers does effect the hello size.
   But if that was involved here, we should fail much sooner.

We're past the hellos, have done the certificate send from the server, 
the key exchange & the client cert request - which is where the client 
seems to be failing.  Perhaps the trace that I sent will tell someone 
what is being sent.


I have only one server set up.

I did previously try different ciphers -- no change.

But, I tested exactly as you requested (on the server only):
--tls-cipher AES128-SHA fails

--tls-cipher DHE-RSA-AES256-SHA

No cipher match

Set on both ends:
--tls-cipher AES128-SHA fails

Cipher list (Er, the "Deprecated DEFAULT, please use DEFAULT" should be 
fixed!)


Server
 openvpn --tls-cipher DEFAULT --show-tls
Wed Apr 23 12:53:49 2014 Deprecated TLS cipher name 'DEFAULT', please 
use IANA name 'DEFAULT'

Available TLS Ciphers,
listed in order of preference:

TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA
TLS-SRP-SHA-DSS-WITH-AES-256-CBC-SHA
TLS-SRP-SHA-RSA-WITH-AES-256-CBC-SHA
TLS-DHE-DSS-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
TLS-DHE-DSS-WITH-AES-256-CBC-SHA256
TLS-DHE-RSA-WITH-AES-256-CBC-SHA
TLS-DHE-DSS-WITH-AES-256-CBC-SHA
TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA
TLS-DHE-DSS-WITH-CAMELLIA-256-CBC-SHA
TLS-ECDH-RSA-WITH-AES-256-GCM-SHA384
TLS-ECDH-ECDSA-WITH-AES-256-GCM-SHA384
TLS-ECDH-RSA-WITH-AES-256-CBC-SHA384
TLS-ECDH-ECDSA-WITH-AES-256-CBC-SHA384
TLS-ECDH-RSA-WITH-AES-256-CBC-SHA
TLS-ECDH-ECDSA-WITH-AES-256-CBC-SHA
TLS-RSA-WITH-AES-256-GCM-SHA384
TLS-RSA-WITH-AES-256-CBC-SHA256
TLS-RSA-WITH-AES-256-CBC-SHA
TLS-RSA-WITH-CAMELLIA-256-CBC-SHA
TLS-PSK-WITH-AES-256-CBC-SHA
TLS-ECDHE-RSA-WITH-3DES-EDE-CBC-SHA
TLS-ECDHE-ECDSA-WITH-3DES-EDE-CBC-SHA
TLS-SRP-SHA-DSS-WITH-3DES-EDE-CBC-SHA
TLS-SRP-SHA-RSA-WITH-3DES-EDE-CBC-SHA
TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA
TLS-DHE-DSS-WITH-3DES-EDE-CBC-SHA
TLS-ECDH-RSA-WITH-3DES-EDE-CBC-SHA
TLS-ECDH-ECDSA-WITH-3DES-EDE-CBC-SHA
TLS-RSA-WITH-3DES-EDE-CBC-SHA
TLS-PSK-WITH-3DES-EDE-CBC-SHA
TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256
TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA
TLS-SRP-SHA-DSS-WITH-AES-128-CBC-SHA
TLS-SRP-SHA-RSA-WITH-AES-128-CBC-SHA
TLS-DHE-DSS-WITH-AES-128-GCM-SHA256
TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
TLS-DHE-RSA-WITH-AES-128-CBC-SHA256
TLS-DHE-DSS-WITH-AES-128-CBC-SHA256
TLS-DHE-RSA-WITH-AES-128-CBC-SHA
TLS-DHE-DSS-WITH-AES-128-CBC-SHA
TLS-DHE-RSA-WITH-SEED-CBC-SHA
TLS-DHE-DSS-WITH-SEED-CBC-SHA
TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
TLS-DHE-DSS-WITH-CAMELLIA-128-CBC-SHA
TLS-ECDH-RSA-WITH-AES-128-GCM-SHA256
TLS-ECDH-ECDSA-WITH-AES-128-GCM-SHA256
TLS-ECDH-RSA-WITH-AES-128-CBC-SHA256
TLS-ECDH-ECDSA-WITH-AES-128-CBC-SHA256
TLS-ECDH-RSA-WITH-AES-128-CBC-SHA
TLS-ECDH-ECDSA-WITH-AES-128-CBC-SHA
TLS-RSA-WITH-AES-128-GCM-SHA256
TLS-RSA-WITH-AES-128-CBC-SHA256
TLS-RSA-WITH-AES-128-CBC-SHA
TLS-RSA-WITH-SEED-CBC-SHA
TLS-RSA-WITH-CAMELLIA-128-CBC-SHA
TLS-PSK-WITH-AES-128-CBC-SHA
TLS-ECDHE-RSA-WITH-RC4-128-SHA
TLS-ECDHE-ECDSA-WITH-RC4-128-SHA
TLS-ECDH-RSA-WITH-RC4-128-SHA
TLS-ECDH-ECDSA-WITH-RC4-128-SHA
TLS-RSA-WITH-RC4-128-SHA
TLS-RSA-WITH-RC4-128-MD5
TLS-PSK-WITH-RC4-128-SHA
TLS-DHE-RSA-WITH-DES-CBC-SHA
TLS-DHE-DSS-WITH-DES-CBC-SHA
TLS-RSA-WITH-DES-CBC-SHA
TLS-DH-RSA-EXPORT-WITH-DES40-CBC-SHA
TLS-DH-DSS-EXPORT-WITH-DES40-CBC-SHA
TLS-RSA-EXPORT-WITH-DES40-CBC-SHA
TLS-RSA-EXPORT-WITH-RC2-CBC-40-MD5
TLS-RSA-EXPORT-WITH-RC4-40-MD5

Client (windows) that fails:
 openvpn --tls-cipher DEFAULT --show-tls
Wed Apr 23 12:53:49 2014 Deprecated TLS cipher name 'DEFAULT', please 
use IANA name 'DEFAULT'

Available TLS Ciphers,
listed in order of preference:

TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA
TLS-SRP-SHA-DSS-WITH-AES-256-CBC-SHA
TLS-SRP-SHA-RSA-WITH-AES-256-CBC-SHA
TLS-DHE-DSS-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
TLS-DHE-DSS-WITH-AES-256-CBC-SHA256
TLS-DHE-RSA-WITH-AES-256-CBC-SHA
TLS-DHE-DSS-WITH-AES-256-CBC-SHA
TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA
TLS-DHE-DSS-WITH-CAMELLIA-256-CBC-SHA

Re: [Openvpn-devel] Progress on Version negotiation

[Gert Doering]

Hi,

On Wed, Apr 23, 2014 at 11:36:28AM -0400, Timothe Litt wrote:
> Just to confirm that the issue is 1.2, not the negotiation:
> 
> I added an unconditional
>   sslopt |= SSL_OP_NO_TLSv1_2;
>  in tls_ctx_set_options.
> 
> With this (and the context initialized to SSL_v23_*_method, so we 
> negotiate), the tunnel comes up.
> Without it, the tunnel does not come up.
> 
> So it is the use of 1.2 that is the issue, not how it is selected.

Thinking through this, while cycling home from $paidwork, I remembered
something I saw when debugging something similar ("if I enable TLS1.2,
things explode") last time.

From Perl's IO::Socket::SSL:

# older versions of F5 BIG-IP hang when getting SSL client hello >255 bytes
# http://support.f5.com/kb/en-us/solutions/public/13000/000/sol13037.html
# http://guest:gu...@rt.openssl.org/Ticket/Display.html?id=2771
# Debian works around this by disabling TLSv12 on the client side
# Chrome and IE11 use TLSv12 but use only a few ciphers, so that packet
# stays small enough
# The following list is taken from IE11, except that we don't do RC4-MD5,
# RC4-SHA is already bad enough. Also, we have a different sort order
# compared to IE11, because we put ciphers supporting forward secrecy on top

now - does that sound like it could be the problem?  The initial handshake
packet "under some conditions" (like: the local OpenSSL build having
more available ciphers, depending on how it was built) being too big,
causing "surprises"?

(This question is more geared towards James, Arne and Steffan :-) )

Timothe, on your failing setup, could you try putting some variations of
"--tls-cipher" in your openvpn.conf?  I'm not really sure I understand
the variants, but "openvpn --show-tls" suggests that some of these might
work

  tls-cipher AES128-SHA
  tls-cipher DHE-RSA-AES256-SHA

what does "openvpn --tls-cipher DEFAULT --show-tls" list on your systems
(or, phrased differently, if you have a system that does *not* fail on
TLS 1.2, does it show a shorter list)?

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


pgpntZEnGLiV3.pgp
Description: PGP signature

Re: [Openvpn-devel] Progress on Version negotiation

[Timothe Litt]

On 23-Apr-14 06:56, Steffan Karger wrote:

Hi,

On 04/23/2014 10:10 AM, Gert Doering wrote:

On Tue, Apr 22, 2014 at 10:58:22PM -0400, Timothe Litt wrote:

It does not appear to be the negotiation, rather it's TLS1.2.

This is quite cool, thank you.  (I'm not enough of a crypto geek to
make real sense out of it, but it's quite useful to understand where
it is failing, and I appreciate that you took the time to dig into it)

Steffan, Arne, any ideas?

This sounds very plausible, yes.

I've seen situations in which an OpenSSL 2.3.3 client refuses to connect
to a PolarSSL 1.2.10 server. I tried to reproduce that in a test setup
last night, but did not manage make it break. So I'm still a bit in the
dark on the real cause.

For the 'fix the breaking asap', maybe we should add an
--tls-version-max if that really resolves the problem.

-Steffan



Just to confirm that the issue is 1.2, not the negotiation:

I added an unconditional
  sslopt |= SSL_OP_NO_TLSv1_2;
 in tls_ctx_set_options.

With this (and the context initialized to SSL_v23_*_method, so we 
negotiate), the tunnel comes up.

Without it, the tunnel does not come up.

So it is the use of 1.2 that is the issue, not how it is selected.

I generated a matching pair of traces of the failure (client and server) 
& posted a summary.


Let me know if you would like the full traces.

This is 100% reproducible here, so let me know if you need more 
instrumentation. (However, I can't build a windows client, so if that's 
necessary, you'll have to build it for me to run.)






smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Openvpn-devel] Progress on Version negotiation

[Timothe Litt]

This is quite cool, thank you.
You're welcome.  I don't like unsolved mysteries, and since I have a 
solid reproducer, thought I should do what I can.


Some more.  I looked into building on Windows, but the doc says one 
needs commercial tools; I'm not going to buy them for this.


However, I got verb 9 traces from the client and server side of a failure.

They're a bit too large to post here, but I can provide the full traces 
off-list.


I haven't backtracked to understanding what is being sent. Perhaps one 
of you has the magic decoder for the data in the messages...


Here's a summary of what I see that seems interesting:

Server:
SSL state: Read client hello B
  Write server hello A
  Write certificate a
  Write key exchange A
  Write certificate request A
  Flush data

This is the server sending the data that triggers the error, starting 
with the preceding read (that presumably triggers it):


Wed Apr 23 09:26:25 2014 us=505743 GET INST BY REAL: 
192.168.148.191:1194 [succeeded]
Wed Apr 23 09:26:25 2014 us=507179 192.168.148.191:1194 UDP READ [50] 
from [AF_INET]192.168.148.191:1194: P_ACK_V1 kid=0 sid=87209bbf d7d12aeb 
tls_hmac=03a350ad c3c8bd68 06aacaa0 148a74fd b7731036 pid=[ #38 / time = 
(1398259583) Wed Apr 23 09:26:23 2014 ] [ 30 sid=adda013b a627c847 ]
Wed Apr 23 09:26:25 2014 us=508665 192.168.148.191:1194 TLS: control 
channel, op=P_ACK_V1, IP=[AF_INET]192.168.148.191:1194
Wed Apr 23 09:26:25 2014 us=510704 192.168.148.191:1194 TLS: initial 
packet test, i=0 state=S_START, mysid=95747581 daf31aa7, 
rec-sid=87209bbf d7d12aeb, rec-ip=[AF_INET]192.168.148.191:1194, 
stored-sid=65fbeaf3 0672d359, stored-ip=[AF_INET]192.168.148.191:1194
Wed Apr 23 09:26:25 2014 us=511162 192.168.148.191:1194 TLS: initial 
packet test, i=1 state=S_START, mysid=adda013b a627c847, 
rec-sid=87209bbf d7d12aeb, rec-ip=[AF_INET]192.168.148.191:1194, 
stored-sid=87209bbf d7d12aeb, stored-ip=[AF_INET]192.168.148.191:1194
Wed Apr 23 09:26:25 2014 us=512181 192.168.148.191:1194 TLS: found 
match, session[1], sid=87209bbf d7d12aeb
Wed Apr 23 09:26:25 2014 us=513617 192.168.148.191:1194 PID_TEST [0] 
[TLS_AUTH-0] [01222] 1398259583:37 
1398259583:38 t=1398259585[0] r=[-2,64,15,0,1] sl=[27,37,64,272]
Wed Apr 23 09:26:25 2014 us=514591 192.168.148.191:1194 TLS: received 
control channel packet s#=1 sid=87209bbf d7d12aeb
Wed Apr 23 09:26:25 2014 us=515784 192.168.148.191:1194 ACK received for 
pid 30, deleting from send buffer
Wed Apr 23 09:26:25 2014 us=516298 192.168.148.191:1194 TLS: 
tls_multi_process: i=0 state=S_START, mysid=95747581 daf31aa7, 
stored-sid=65fbeaf3 0672d359, stored-ip=[AF_INET]192.168.148.191:1194
Wed Apr 23 09:26:25 2014 us=517260 192.168.148.191:1194 TLS: 
tls_process: chg=0 ks=S_START lame=S_UNDEF to_link->len=0 wakeup=604800
Wed Apr 23 09:26:25 2014 us=518489 192.168.148.191:1194 ACK 
reliable_can_send active=1 current=0 : [35] 34
Wed Apr 23 09:26:25 2014 us=518920 192.168.148.191:1194 ACK 
reliable_send_timeout 1 [35] 34
Wed Apr 23 09:26:25 2014 us=519836 192.168.148.191:1194 TLS: 
tls_process: timeout set to 1
Wed Apr 23 09:26:25 2014 us=521129 192.168.148.191:1194 TLS: 
tls_multi_process: i=1 state=S_START, mysid=adda013b a627c847, 
stored-sid=87209bbf d7d12aeb, stored-ip=[AF_INET]192.168.148.191:1194
Wed Apr 23 09:26:25 2014 us=522055 192.168.148.191:1194 TLS: 
tls_process: chg=0 ks=S_START lame=S_UNDEF to_link->len=0 wakeup=1
Wed Apr 23 09:26:25 2014 us=523328 192.168.148.191:1194 ACK 
reliable_can_send active=3 current=0 : [34] 33 31 32
Wed Apr 23 09:26:25 2014 us=523743 192.168.148.191:1194 BIO read 
tls_read_ciphertext 95 bytes
Wed Apr 23 09:26:25 2014 us=524649 192.168.148.191:1194 ACK mark active 
outgoing ID 34
Wed Apr 23 09:26:25 2014 us=525799 192.168.148.191:1194 Outgoing 
Ciphertext -> Reliable
Wed Apr 23 09:26:25 2014 us=526116 192.168.148.191:1194 TLS: 
tls_process: chg=1 ks=S_START lame=S_UNDEF to_link->len=0 wakeup=1
Wed Apr 23 09:26:25 2014 us=527049 192.168.148.191:1194 ACK 
reliable_can_send active=4 current=1 : [35] 33 34 31 32
Wed Apr 23 09:26:25 2014 us=528217 192.168.148.191:1194 ACK 
reliable_send ID 34 (size=99 to=5)

Wed Apr 23 09:26:25 2014 us=528542 192.168.148.191:1194 Reliable -> TCP/UDP
Wed Apr 23 09:26:25 2014 us=529436 192.168.148.191:1194 ACK 
reliable_send_timeout 2 [35] 33 34 31 32
Wed Apr 23 09:26:25 2014 us=530612 192.168.148.191:1194 TLS: 
tls_process: timeout set to 1
Wed Apr 23 09:26:25 2014 us=531584 192.168.148.191:1194 TLS: 
tls_multi_process: i=2 state=S_UNDEF, mysid= , 
stored-sid= , stored-ip=[AF_UNSPEC]

Wed Apr 23 09:26:25 2014 us=532955 PO_CTL rwflags=0x0002 ev=5 arg=0x0009377c
Wed Apr 23 09:26:25 2014 us=533939 PO_CTL rwflags=0x ev=4 arg=0x000936f0
Wed Apr 23 09:26:25 2014 us=535162 PO_CTL rwflags=0x0001 ev=3 arg=0x000936f4
Wed Apr 23 09:26:25 2014 us=536073 I/O WAIT Tr|Tw|Sr|SW [1/14229]
Wed Apr 23 

Re: [Openvpn-devel] Progress on Version negotiation

[Steffan Karger]

Hi,

On 04/23/2014 10:10 AM, Gert Doering wrote:
> On Tue, Apr 22, 2014 at 10:58:22PM -0400, Timothe Litt wrote:
>> It does not appear to be the negotiation, rather it's TLS1.2.
> 
> This is quite cool, thank you.  (I'm not enough of a crypto geek to
> make real sense out of it, but it's quite useful to understand where
> it is failing, and I appreciate that you took the time to dig into it)
> 
> Steffan, Arne, any ideas?

This sounds very plausible, yes.

I've seen situations in which an OpenSSL 2.3.3 client refuses to connect
to a PolarSSL 1.2.10 server. I tried to reproduce that in a test setup
last night, but did not manage make it break. So I'm still a bit in the
dark on the real cause.

For the 'fix the breaking asap', maybe we should add an
--tls-version-max if that really resolves the problem.

-Steffan

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

[Steffan Karger]

Hi,

On 04/23/2014 12:08 PM, Arne Schwabe wrote:
> ACK.

Thanks for reviewing. Yesterday evening I've been reworking these
patches a bit however. I want to have three things resolved:
1) PolarSSL 1.3 is already in master, and supports elliptic curve
crypto, so the --show-curves and --ecdh-curve options need to be
implemented for polarssl too.
2) Some distro's (notably, RHEL) ship without EC in openssl, so I needed
to add a number of #ifdefs to deal with that.
3) While I'm at it, improve the error reporting a bit.

I expect to send out reworked patches later this week.

> I don't think that adding sample keys is a good idea. Having a script
> which generates sample dummy key is probably a much better idea. I am
> acking this on the basis that we do the same stuff for RSA.

I agree. Let's do that in a separate patch set.

-Steffan

Re: [Openvpn-devel] [PATCH 2/4] Added PIP_OPT_MASK for process_ip_header fast exit path.

[Arne Schwabe]

Am 21.04.14 21:26, schrieb James Yonan:
> On 21/04/2014 05:27, Arne Schwabe wrote:
>> On 21.04.2014 09:10, James Yonan wrote:
>>> Define PIP_OPT_MASK to represent all flags of interest to
>>> process_ip_header, so that it can have a fast exit path
>>> if no flags are set.
>>
>> I haven't look at the code but if remember  correctly, this method does
>> not get passed the actual flags but the flags should *potientially* be
>> checked.
>
> Yes, the point is to aggregate the potential flags of interest to
> process_ip_header under a single mask, i.e. PIP_OPT_MASK.
>
> So instead of having "if (flags & (PIPV4_PASSTOS|PIP_MSSFIX|...|...))"
> you just have "if (flags & PIP_OPT_MASK)".
>
> The main issue for us is that we have an internal patch for one of our
> services that adds an additional flag, and the previous usage is a
> merge conflict attractor because all the flags of interest are
> explicitly given on a single line.
>
I only wanted to point out my patch also exits. I looked at the code again.

I think to really get rid of the #ifdef here we also need to
unconditionally enable the other &= ~ statements:

Change

#if PASSTOS_CAPABILITY
  if (!c->options.passtos)
flags &= ~PIPV4_PASSTOS;
#endif

to

#if PASSTOS_CAPABILITY
  if (!c->options.passtos)
#endif
flags &= ~PIPV4_PASSTOS;


Otherwise if the function is called with PIPV4_PASSTOS but not compiled
with PASSTOS_CAPABILITY the

flags & PIP_OPT_MASK will be always true.

Arne







signature.asc
Description: OpenPGP digital signature

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

[Arne Schwabe]

Am 26.02.14 00:28, schrieb 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(-)
>  
ACK.

I don't think that adding sample keys is a good idea. Having a script
which generates sample dummy key is probably a much better idea. I am
acking this on the basis that we do the same stuff for RSA.





signature.asc
Description: OpenPGP digital signature

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

[Arne Schwabe]

Am 26.02.14 00:27, schrieb 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.
>
ACK.

Arne



signature.asc
Description: OpenPGP digital signature

Re: [Openvpn-devel] Progress on Version negotiation

[Gert Doering]

Hi,

On Tue, Apr 22, 2014 at 10:58:22PM -0400, Timothe Litt wrote:
> It does not appear to be the negotiation, rather it's TLS1.2.

This is quite cool, thank you.  (I'm not enough of a crypto geek to
make real sense out of it, but it's quite useful to understand where
it is failing, and I appreciate that you took the time to dig into it)

Steffan, Arne, any ideas?

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


pgpE0xD5ca22z.pgp
Description: PGP signature

[Openvpn-devel] Progress on Version negotiation

[Timothe Litt]

It does not appear to be the negotiation, rather it's TLS1.2.

I debugged the client hello in OpenSSL - a bit tricky due to the 
timeouts, but I established that the server is picking TLS1.2.


I then switched the tls_ctx_{client,server}_new to use 
TLSv1_2_{client,server}_method in the call to SSL_CTX_new.


The connection failed.  So, we didn't negotiate, TLSv1.2 fails.

Next, I switched to TLSv1.1 (TLSv1_1_{client,server}method).  The tunnel 
comes up.


So, it appears that the issue has to do with TLSv1.2.  (Also, it is 100% 
reproducible here.)


Remember that the client log shows
Wed Apr 09 21:10:52 2014 us=748478 TLS_ERROR: BIO read 
tls_read_plaintext error: error:04066083:rsa 
routines:RSA_EAY_PRIVATE_ENCRYPT:invalid message length: 
error:14099006:SSL routines:SSL3_SEND_CLIENT_VERIFY:EVP lib
Wed Apr 09 21:10:52 2014 us=748478 TLS Error: TLS object -> incoming 
plaintext read error

Wed Apr 09 21:10:52 2014 us=748478 TLS Error: TLS handshake failed

I don't have development tools on my windows client, but perhaps someone 
can build me an instrumented version.  Here's what I think is happening:


The error is coming from ssl_openssl.c:key_state_read_plaintext, where 
bio_read is failing.


bio_read (same file) fails if openssl/crypto/bio/bio_lib.c: BIO_read 
fails with a hard error.  There are several possibilities:


1) bio_read will reduce the read to 'maxlen', which I think is 
TLS_CHANNEL_BUF_SIZE.

2) the data received is larger than the buffer.
3) the message length is corrupted.

According to the log, the client has received and verified the server 
certificate.  So the server hello has been processed successfully -- 
it's not the longer cipher suite in TLS1.2.


Interesting things to instrument:
  Is bio_read reducing the read size?  If so, from what to what?
  What is the actual data received size?
  What would happen if we built with larger TLS_CHANNEL_BUF_SIZE 
(common.h defines it as 2048; suppose it was doubled...)
  What is actually being read?  Is it  something else that we can 
reduce on the server end?


Let me know if there's more I can do.


--
Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.




smime.p7s
Description: S/MIME Cryptographic Signature