OpenVPN Support Forum

Posted: **Fri Mar 30, 2018 9:34 pm**

what ciphers you try to connect with? My existing configuration works without any issues with openssl 1.1.0

Posted: **Fri Mar 30, 2018 9:46 pm**

Well that’s the thing. It doesn’t work regardless of whether or not I use the tls-cipher option. So when there is no tls-cipher option in either, it doesn’t work, but when I include it in both config files, and I use TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 (which is what the control channel succesfully uses when employing 1.0.2o on the client side), it still doesn’t work. So I’m a bit confused by this. Is both your client and server using 1.1.0?

Posted: **Fri Mar 30, 2018 10:10 pm**

server openvpn 2.4.5 with openssl 1.1.0h, Client - macOS - tunnelblick either 1.1.0h or 1.0.2o work. Would you mind to share your both your server and client configs?

Posted: **Fri Mar 30, 2018 11:19 pm**

Sure.

Server.conf is:

Code: Select all

dev tun
proto udp
port 1198
plugin /opt/openvpn-2.4.5/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn
reneg-sec 36000
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server_###.crt
key /etc/openvpn/server_###.key
dh none
ecdh-curve brainpoolP384r1
topology subnet
server 10.8.0.0 255.255.255.0
push "dhcp-option DNS 192.168.100.1"
push "redirect-gateway def1"
client-to-client
keepalive 10 120
remote-cert-tls client
tls-version-min 1.2
tls-crypt /etc/openvpn/ta.key
cipher AES-256-CBC
auth SHA256
ncp-ciphers AES-256-GCM
compress lz4-v2
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn-status.log 20
status-version 3
log /var/log/openvpn.log
verb 3

and the client ovpn is:

Code: Select all

client
dev tun
proto udp
remote ### 1198
resolv-retry infinite
nobind
persist-key
persist-tun
auth-user-pass
auth-nocache
reneg-sec 0
remote-cert-tls server
tls-version-min 1.2
verify-x509-name server_### name
cipher AES-256-CBC
auth SHA256
ncp-ciphers AES-256-GCM
compress lz4-v2
verb 3
ca ca.crt
cert ###.crt
key ###.key
tls-crypt ta.key
explicit-exit-notify 5

Like I said, my client connects fine when using these exact configs when I employ openssl 1.0.2o on tunnelblick, with the log showing

Code: Select all

2018-03-30 23:28:32 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit EC, curve: brainpoolP384r1

but for some reason does not connect when I use 1.1.0h. Adding

Code: Select all

tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384

to both configs doesn't make a difference. Strange.

Posted: **Sat Mar 31, 2018 9:11 am**

for me both config files look valid.

your "openvpn --version" shows that it was compiled with 1.1.0h

but what about linked libraries? This is something I had issues with in the past. Can you try to run "ldd /usr/local/sbin/openvpn"? Below is its result for my server:

Code: Select all

        linux-vdso.so.1 (0x7eca1000)
        /usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76f8d000)
        libnsl.so.1 => /lib/arm-linux-gnueabihf/libnsl.so.1 (0x76f5b000)
        libresolv.so.2 => /lib/arm-linux-gnueabihf/libresolv.so.2 (0x76f36000)
        liblz4.so.1 => /usr/local/lib/liblz4.so.1 (0x76f05000)
        libcrypto.so.1.1 => /opt/openssl-1.1.0h/lib/libcrypto.so.1.1 (0x76d1b000)
        libssl.so.1.1 => /opt/openssl-1.1.0h/lib/libssl.so.1.1 (0x76cb8000)
        libsystemd.so.0 => /lib/arm-linux-gnueabihf/libsystemd.so.0 (0x76c3e000)
        libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76c2b000)
        libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76aec000)
        /lib/ld-linux-armhf.so.3 (0x76fa3000)
        libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76ac3000)
        libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 (0x76a90000)
        librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x76a79000)
        liblzma.so.5 => /lib/arm-linux-gnueabihf/liblzma.so.5 (0x76a48000)
        libgcrypt.so.20 => /lib/arm-linux-gnueabihf/libgcrypt.so.20 (0x76978000)
        libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x7694b000)
        libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0x768d2000)
        libgpg-error.so.0 => /lib/arm-linux-gnueabihf/libgpg-error.so.0 (0x768b2000)

if not linked correctly it is possible that libcrypto.so.1.1 and libssl.so.1.1 use different openssl version libraries - with results difficult to predict.

Posted: **Sat Mar 31, 2018 9:46 am**

This is the output I got

Code: Select all

$ ldd /opt/openvpn-2.4.5/sbin/openvpn
        linux-vdso.so.1 (0x7eeba000)
        /usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76f07000)
        libnsl.so.1 => /lib/arm-linux-gnueabihf/libnsl.so.1 (0x76ed5000)
        libresolv.so.2 => /lib/arm-linux-gnueabihf/libresolv.so.2 (0x76eb0000)
        liblzo2.so.2 => /lib/arm-linux-gnueabihf/liblzo2.so.2 (0x76e83000)
        liblz4.so.1 => /usr/lib/arm-linux-gnueabihf/liblz4.so.1 (0x76e62000)
        libcrypto.so.1.1 => /opt/openssl-1.1.0h/lib/libcrypto.so.1.1 (0x76c7c000)
        libssl.so.1.1 => /opt/openssl-1.1.0h/lib/libssl.so.1.1 (0x76c19000)
        libsystemd.so.0 => /lib/arm-linux-gnueabihf/libsystemd.so.0 (0x76b9f000)
        libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76b8c000)
        libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76a4d000)
        /lib/ld-linux-armhf.so.3 (0x76f1d000)
        libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76a24000)
        libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 (0x769f1000)
        librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x769da000)
        liblzma.so.5 => /lib/arm-linux-gnueabihf/liblzma.so.5 (0x769a9000)
        libgcrypt.so.20 => /lib/arm-linux-gnueabihf/libgcrypt.so.20 (0x768d9000)
        libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x768ac000)
        libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0x76833000)
        libgpg-error.so.0 => /lib/arm-linux-gnueabihf/libgpg-error.so.0 (0x76813000)

Libcrytpto and libssl are both poinitng to the correct libraries contianed in my compiled openssl 1.1.0h. Do you think I need to to file a bug report on this?

Posted: **Sat Mar 31, 2018 9:54 am**

something is not right. could you try to remove ecdh-curve parameter from your server config? if it does not change anything what about we try my setup with your keys? you can generate new server and client certs for me - later you can revoke them to maintain your setup security. Or generate all new cert just for this test.

Posted: **Sat Mar 31, 2018 9:58 am**

I can also generate my certs for you to see if they work on your end. I don't think I can do all these tests today - more likely tomorrow.

Posted: **Sat Mar 31, 2018 6:33 pm**

@Jimdoe .. I did a little testing myself and found the same problem as you.

@Daruisz .. what curve are you using ?

FTR there is a ticket for this https://community.openvpn.net/openvpn/ticket/1048

The essential problem seems to be that openssl does not use all curves automatically for TLS.

Posted: **Sun Apr 01, 2018 9:17 am**

with secp384r1 it works for latest tunnelblick (with both 1.0.2o and 1.1.0h openssl libs), iOS connect and latest OpenVPN Windows client. Server - RPi Debian Stretch with OpenVPN 2.4.5 with openssl 1.1.0h

is there any place to clearly list what curves are supported by what software? At the moment it is hit and miss game.

Posted: **Sun Apr 01, 2018 1:15 pm**

dariusz wrote: ↑
Sun Apr 01, 2018 9:17 am
with secp384r1 it works

That is one of the curves which is in the default openssl use set ..

dariusz wrote: ↑
Sun Apr 01, 2018 9:17 am
is there any place to clearly list what curves are supported by what software? At the moment it is hit and miss game.

The --show-curves option lists the curves supported by openssl but not necessarily used by ..

I don't have any further information, infact nobody does at this time because I do not believe the developers were aware of this when including EC into openvpn. The openssl library must have some default usage that openvpn has not included options for at this time to manipulate the usage. As it stands, this seems to only effect the client, the server actively uses --ecdh-curve while the client simply ignores it.

Posted: **Mon Apr 02, 2018 10:43 am**

So is this occuring because I’m employing BrainpoolP384r1 instead of one of the standard NIST curves?
Does that mean I should change —ecdh-curve to secp384r1? Does it matter if the CA and server and client certs were signed using brainpool?

Does this also mean I don’t need to run the tests dariusz wanted me to? (Thanks for the kind offer to send me some test certs btw)

Posted: **Mon Apr 02, 2018 4:33 pm**

jimdoe wrote: ↑
Mon Apr 02, 2018 10:43 am
So is this occuring because I’m employing BrainpoolP384r1 instead of one of the standard NIST curves?

Yes.

jimdoe wrote: ↑
Mon Apr 02, 2018 10:43 am
Does that mean I should change —ecdh-curve to secp384r1?

That is what I have to do ..

jimdoe wrote: ↑
Mon Apr 02, 2018 10:43 am
Does it matter if the CA and server and client certs were signed using brainpool?

In my tests, creating the PKI with brainpool EC results in no shared cipher no matter what settings are used.

Currently, I am not sure what the expected behaviour is. IE: Should it work with Brainpoolxx ?

Posted: **Mon Apr 02, 2018 4:47 pm**

I switched to 'standard' curve secp384r1 as it was one I was able to make work with all clients (macOS, Windows, iOS and Android). Windows client is now compiled with openssl 1.1 so given the issue described here https://community.openvpn.net/openvpn/ticket/1048 I think the safest bet is to stick to default openssl 1.1 curves - secp256r1, secp521r1, secp384r1 (there is also default x25519 but it cant be used for ECDSA so it is irrelevant). I can confirm that secp256r1 and secp384r1 work. I have never tried secp521r1.

Posted: **Tue Apr 03, 2018 12:37 pm**

TinCanTech wrote: ↑
Mon Apr 02, 2018 4:33 pm

jimdoe wrote: ↑
Mon Apr 02, 2018 10:43 am
So is this occuring because I’m employing BrainpoolP384r1 instead of one of the standard NIST curves?
Yes.

Ok, I’ll give it a go. Excuse my ignorance though (I’m still quite new to all this) but, just to be clear, is this a bug with openssl 1.1.0, or openvpn? Or a combination of the two? Or is it not even a bug?

I’m just a bit confused. Seems strange that with an “updated” openssl the abilities of openvpn have regressed. As far as I can tell, brainpool is not an unsafe curve (in fact, from what I have read, there is more reason to suspect NIST curves as being potentially purposefully weakened than non-NIST curves). I know you said you weren’t sure what the intended behaviour was, but it would be great if you could point me in the right direction as to where I could find out more on this. Why has brainpool been removed as one of the standard curves in the hello, and can/should this be fixed on the openvpn end? Should I be reporting it to the openssl github?

Posted: **Tue Apr 03, 2018 1:11 pm**

jimdoe wrote: ↑
Tue Apr 03, 2018 12:37 pm
is this a bug with openssl 1.1.0, or openvpn? Or a combination of the two? Or is it not even a bug?

Good question .. so far I don't think it is a bug but openssl changed behaviour.

jimdoe wrote: ↑
Tue Apr 03, 2018 12:37 pm
I know you said you weren’t sure what the intended behaviour was, but it would be great if you could point me in the right direction as to where I could find out more on this

All I really know is in the links I posted.

The short story is this:
1. Openssl changed the default curves from all to only a few:

Rich Salz of Openssl wrote:*) Change the ECC default curve list to be this, in order: x25519, secp256r1, secp521r1, secp384r1.
[Rich Salz]

This means the Openvpn client currently cannot use any other curves.

2. Openvpn know of this problem and will address it when time permits. For now, those are the only curves openvpn can use because there is no way to configure the openvpn client to use any other curve.

Posted: **Tue Apr 03, 2018 1:32 pm**

This link sheds some more light on the nature of this issue

https://github.com/schwabe/ics-openvpn/issues/721

and even provide some potential "solution" if somebody is happy to tinker with client compilation:

Code: Select all

In case anyone cares, this is related to the way openvpn, openssl 1.1 and ECC are interacting:
*) Change the ECC default curve list to be this, in order: x25519,
secp256r1, secp521r1, secp384r1.
[Rich Salz]
Somehow openssl defaults to x25519 , and my certificates are using sect571r1, and passing
ecdh-curve to openvpn does not solve it.

I have added a line in src/openvpn/ssl_openssl.c:
SSL_CTX_set1_curves_list(ctx->ctx, "sect571r1");
just under
SSL_CTX_set_default_passwd_cb(ctx->ctx, pem_password_callback);

This seems to have fixed it.

As I understand it the openvpn client compiled with openssl 1.1.0 is not able to set the right curve if it is outside of openssl 1.1.0 default list. So we have to wait for openvpn/openssl dev to find the right way to handle it.

OpenVPN Support Forum

compiling and installing the latest openvpn on Raspbian Stretch

Re: compiling and installing the latest openvpn on Raspbian Stretch

Re: compiling and installing the latest openvpn on Raspbian Stretch

Re: compiling and installing the latest openvpn on Raspbian Stretch

Re: compiling and installing the latest openvpn on Raspbian Stretch

Re: compiling and installing the latest openvpn on Raspbian Stretch

Re: compiling and installing the latest openvpn on Raspbian Stretch

Re: compiling and installing the latest openvpn on Raspbian Stretch

Re: compiling and installing the latest openvpn on Raspbian Stretch

Re: compiling and installing the latest openvpn on Raspbian Stretch

Re: compiling and installing the latest openvpn on Raspbian Stretch

Re: compiling and installing the latest openvpn on Raspbian Stretch

Re: compiling and installing the latest openvpn on Raspbian Stretch

Re: compiling and installing the latest openvpn on Raspbian Stretch

Re: compiling and installing the latest openvpn on Raspbian Stretch

Re: compiling and installing the latest openvpn on Raspbian Stretch

Re: compiling and installing the latest openvpn on Raspbian Stretch

Re: compiling and installing the latest openvpn on Raspbian Stretch