First off, I'd just like to say what a great and informative thread this is. Very helpful - thanks! I've used this thread as a reference now on two openvpn server installations :D So, has anyone tried compiling and installing the latest openvpn on Raspbian Stretch? I'm having issues with the --enable-systemd option for ./configure. I'm having the exact same problem compiling as matt2336 had [quote=matt3226 post_id=71780 time=1500344392 user_id=40679] When recompiling openvpn to use systemd, I get this: [code]checking for libsystemd... no checking for libsystemd... no configure: error: Package requirements (libsystemd-daemon) were not met: No package 'libsystemd-daemon' found [/code] I tried apt-get install libsystemd-daemon0, I thought it was a missing package/dependency? That didn't work.. [/quote] and running the 'sudo apt-get install libsystemd-daemon-dev' command doesn't work on stretch, as apparently the daemon-dev package is depreciated now. apt-get reports [code]Package libsystemd-daemon-dev is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source However the following packages replace it: libsystemd-dev[/code] I have libsystemd-dev installed, but the systemd error during compile is still occuring. Seems strange that they have depreciated the daemon-dev package because it is apparently not needed, but they failed to make the new package compatible with software that hasn't yet been updated to this change. Also, would chacha20 with poly1305 be better to use on a pi? And if so, what is the best ec curve to use when creating the certificates using easy-rsa? They don't seem to be options when I list available ec curves using [code]/opt/libressl/bin/openssl ecparam -list-curves[/code]

[quote=jimdoe post_id=73402 time=1507934187 user_id=42070] First off, I'd just like to say what a great and informative thread this is [/quote]which thread ? .. this thread: https://forums.openvpn.net/viewtopic.php?f=4&t=23227 The worse case of thread hijack so far ..

[quote=TinCanTech post_id=73403 time=1507940618 user_id=37053] [quote=jimdoe post_id=73402 time=1507934187 user_id=42070] First off, I'd just like to say what a great and informative thread this is [/quote]which thread ? .. this thread: https://forums.openvpn.net/viewtopic.php?f=4&t=23227 The worse case of thread hijack so far .. [/quote] :| I'm not sure exactly how it was the worst case of a thread hijack and why you moved my post? I am trying to set up openvpn servers to use ec. I am a beginner to openvpn and the whole reason I got interested in it was because I was interested in the EC crypto introduced in 2.4, so it was a natural starting place and it has some extremely useful posts. But mostly because I was running into exactly the same problem with systemd that other people in that thread had run into! From my perspective, since I'd been using that thread as a 2.4 reference guide to implementing ec when I started doing this in the summer (there wasn't much documentation on 2.4 or ec), it was just a continuation of the conversation about compiling that the thread had going on.

Perhaps this was not as bad as it first appeared .. this thread is linked both ways to the other thread. however: Your post is regarding compiling openvpn on Raspian Stretch. Your post is asking a specific question about systemd-dev. It is not about Elliptic Curve. [quote=jimdoe post_id=73402 time=1507934187 user_id=42070] I have libsystemd-dev installed, but the systemd error during compile is still occuring [/quote]I have just built openvpn on Debian9 (no access to raspian) with --enable-systemd and it works. There is some kind of issue with the systemd part though, perhaps it is related to what you are experiencing. For me [b]./configure --enable-systemd[/b] works but the resulting binary shows [i]enable-systemd=no[/i] Asking the devs for advice now ..

I am migrating my RPi to stretch so should have some feedback soon. Running stretch and openvpn on other machines was no problem at all. Compiling with all required options flawlessly. I will share my Raspbian Stretch findings soon.

After thorough testing, I can say that openvpn on debian 9 runs as expected with systemd.

Please ensure you have both pkg-config and libsystemd-dev (or systemd-devel, or the equivalent) installed. That should help ensuring ./configure detects the systemd library.

[quote] Also, would chacha20 with poly1305 be better to use on a pi? And if so, what is the best ec curve to use when creating the certificates using easy-rsa? They don't seem to be options when I list available ec curves using [...] [/quote] I believe there are two questions here intertwined. The easy-rsa (please ensure you use easy-rsa 3 for the latest EC stuff to function, or another CA tool like XCA) is one thing and the certificate requirements are mostly "whatever your OpenSSL can deal with". These things relates to what is handled by the OpenVPN control channel traffic. To control the ciphers there is the --tls-cipher and --show-tls options. But you very seldom need to tweak this setting, as both the local and remote OpenVPN instance will negotiate the best cipher both sides supports. Pretty much a standard TLS handshake, so the control channel utilizes asymmetric encryption (pirvate/public keys) to establish a communication channel for the control messages. The tunnelled network traffic is a different side of things. If both sides runs OpenVPN 2.4, there is a limited type of negotiation of the --cipher option. To enlist all supported ciphers, you can use --show-ciphers. By default, if both sides run v2.4, the server expects the client to support and switch to AES-256-GCM. There is no EC cipher support on the data channel, and the data channel is symmetric (using a shared secret between the local and remote instance). So to bind these two things together. The control channel is used to derive a shared secret, where this happens over a TLS enabled communication channel. For v2.4, this is also where the server tells the client which cipher it wants the client to use. Once that is done, the shared secret and cipher parameters is activated and network traffic will now be passed over the data channel using these options - where the encryption is symmetric. And at regular intervals (unless disabled, default is 1 hour) this symmetric encryption key is rotated and replaced with a new one. And a final word about easy-rsa and the CA side of this. You don't need to use easy-rsa, but it is one of more tools which works fine. But [b][u]DO NOT[/u][/b] save the CA private key on any Internet connected device or host. If someone manages to grab that file, it is fairly trivial to issue new certificates without your knowledge. And this can be used to both act as a server or connecting to your own server as a valid client (couple these two together, and you have a "perfect" setup for a MITM attack, where the attacker can access the tunnelled traffic in clear text). So put your CA on a device not directly connected on the Internet, preferably on an offline device only to be activated when you need to do CA operations. If a kitten would be killed each time any one reads the various blog posts on the Internet where the CA is configured and installed on the OpenVPN server ... there would not be any kittens left in this world. Seriously. This is the most common error and misguided advices on OpenVPN on the interwebs, because those who wrote it obviously have not understood the full security impact of their "nice howto". So, if you do put your CA on the OpenVPN server ... think about those cute kittens.

Just a final remark, as I forgot a few details. First regarding the data channel (--cipher), AES-256-GCM (or AES-128-GCM) is by far the best performing ciphers which is considered secure in OpenVPN. the GCM variant gives less network traffic overhead and the decryption and authentication of the packet happens in a single crypto operation. Unless the RPi have the AES-NI instruction set (I doubt it has), the performance is not as good as some other ciphers. [b]But[/b] the majority of the alternatives are not as strong and secure as AES. And you should definitely not use the deprecated ciphers (like Blowfish/BF-CBC, DES, RC2 or CAST5). The alternative is AES-256-CBC (or AES-128-CBC) with SHA1 or SHA256 authentication. Here packets need to be decrypted and authenticated in separate crypto operations. In addition it increases each packet on the wire with 20-32 bytes. This is the overhead. And don't consider anything higher than SHA256. It does not provide much improved security for the tunnel itself, it will just slow it down considerably. For example SHA512 increases each data channel packet with 64 bytes. For the control channel (--tls-cipher), the gains here of tweaking it makes little impact on the overall performance. This can be tweaked if you fully understand the crypto used in TLS and want to avoid certain TLS ciphers, But otherwise, the default is mostly quite sane and good, at least in OpenVPN 2.4.

Compiling and installing the latest openvpn on Raspbian Stretch. I have installed this OS on RPi2 and then successfully compiled openvpn 2.4.4. ./configure --enable-systemd && make -j 4 && sudo make install results in compiled binary: openvpn --version [size=85]OpenVPN 2.4.4 armv7l-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Oct 17 2017 library versions: OpenSSL 1.1.0f 25 May 2017, LZO 2.10 Originally developed by James Yonan Copyright (C) 2002-2017 OpenVPN Technologies, Inc. Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=yes enable_fragment=yes enable_iproute2=no enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_management=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=no enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no[b] [color=#008040]enable_systemd=yes[/color][/b] enable_werror=no enable_win32_dll=yes enable_x509_alt_username=no with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_sysroot=no[/size] For you reference I've installed following additional packages - most of them are not needed for openvpn but it is my standard set I always install to compile some other programs as well sudo apt-get install libncurses5-dev texinfo libffi-dev gettext libmount-dev libpcre3-dev libsystemd-dev libssl-dev libpam0g-dev liblzo2-dev libprotobuf10 libprotobuf-dev protobuf-compiler libslang2-dev

I followed the above instructions and yet I am unable to start openvpn: # systemctl start openvpn.service Failed to start openvpn.service: Unit openvpn.service not found. Can someone please advise?

compiling and installing the latest openvpn on Raspbian Stretch

kptsky

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

jimdoe

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?

kptsky

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?

jimdoe

Sure.

Server.conf is:

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:

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

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

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

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

kptsky

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:

        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.

jimdoe

This is the output I got

$ 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?

kptsky

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.

kptsky

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.

TinCanTech

@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.

kptsky

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.

TinCanTech

dariusz wrote with secp384r1 it works

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

dariusz wrote 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.

jimdoe

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)

TinCanTech

jimdoe wrote So is this occuring because I’m employing BrainpoolP384r1 instead of one of the standard NIST curves?

Yes.

jimdoe wrote Does that mean I should change —ecdh-curve to secp384r1?

That is what I have to do ..

jimdoe wrote 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 ?

kptsky

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.

jimdoe

TinCanTech wrote
jimdoe wrote 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?

TinCanTech

jimdoe wrote 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 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.

kptsky

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:

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.

AarushaPatel

Great Information was very useful for me thanks for sharing...

DBA course in Ahmedabad

Aman Jain

This thread is incredible. It shares so much knowledge.

« Previous Page