blog.mirabellette.eu

A blog about digital independence and autonomy

Warning, this article has been created more than 6 month ago. The information it contains may not be up to date.


A highly secure OpenVPN 2.4 configuration in 2018

Written by Mirabellette / / 16 comments

Hello everyone,

Introduction

Today I would like to talk about OpenVPN. For those who did not know, OpenVPN is a free and open-source software application that implements virtual private network (VPN) techniques to create secure point-to-point or site-to-site connections in routed or bridged configurations and remote access facilities * from Wikipedia. It is developed by OpenVPN Incorporation and they offered a service of VPN with the product privatetunnel.

Nowadays, there a plenty of OpenVPN tutorial which describe how to install and configure it. Contrary to them, I will try to choose the most secure configuration possible in 2018 of OpenVPN 2.4.0 with Debian 9.5. I will try to describe as much as possible each step of the tutorial in order to be clearly understood.

Preliminaries

First of all, we have to install the OpenVPN package and some extra tools with the user root

apt update
apt upgrade
apt install -y iptables-persistent openvpn vim sudo

Generate certificates

Downloads and configuration of EasyRSA

To generate certificates, we will use EasyRSA. EasyRSA is command line interface utility to build and manage keys and certificates. You can download the latest version for your desktop here EasyRSA is one the easiest tool to use to generate Certificate for OpenVPN. This article was focused on OpenVPN configuration and not the certificate part. That means I used the recommend certificate generation tool by OpenVPN, EASYRSA.

Unfortunately, it appears it does not allow to use the more secure cryptographic digest available today to generate a certificate. If you really want to use them, you need to use OpenSSL directly. An amazing tutorial is available here and could help you.

mkdir /tmp/openvpn
cd /tmp/openvpn/
wget https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.5/EasyRSA-nix-3.0.5.tgz
tar xf EasyRSA-nix-3.0.5.tgz
cd EasyRSA-3.0.5
cp vars.example vars
vim vars

You must now modify the vars file in order to enable elliptic curve mode and improves the hash algorithm uses. Regarding the elliptic curve choosen, it appears that curves and cryptographic tools provided by the National Institute of Standards and Technology (NIST) were deliberately weaken. That's why, I recommend the curve Curve25519 because it is similarly strong than secp256, faster, safer and was not create by the NIST. They are curve which are more secure but they are also dramatically slow.

# Enable elliptic crypto mode
set_var EASYRSA_ALGO ec

# Define the named curve - choose what you like and what is supported - openvpn --show-curves
# Impossible to choose Curve25519 with EasyRSA
set_var EASYRSA_CURVE secp521r1
# In how many days should the root CA key expire?
set_var EASYRSA_CA_EXPIRE 3650

# In how many days should certificates expire?
set_var EASYRSA_CERT_EXPIRE 3650

# In how many days should the control happen?
set_var EASYRSA_CRL_DAYS 3650

# Define the Cryptographic digest use, unfortunately, only the md5 and sha family is currently available with EasyRSA
set_var EASYRSA_DIGEST "sha512"

Generate certificates

Please write carefully about the Common name you choose for each certificate, especially for the server certificate. This one will be used by the client to verify the server certificate in order to avoid Man in the middle attack.

# generate a directory to store all files
./easyrsa init-pki

# generate an autority certificate
./easyrsa build-ca nopass

# create server key (server.key) and certificate signing request (server.req)
./easyrsa gen-req server nopass

# sign server certificate signing request by autority certificate (server.ca)
./easyrsa sign-req server server nopass

# create client key (client.key) and certificate signing request (client.req)
./easyrsa gen-req client nopass

# sign client certificate signing request by autority certificate (client.ca)
./easyrsa sign-req client client nopass

Directory structure

# we will now create a more easy to read directory tree
mkdir /tmp/openvpn/server/
mkdir /tmp/openvpn/server/certificates
cp /tmp/openvpn/EasyRSA-3.0.5/pki/ca.crt /tmp/openvpn/server/certificates/ca.crt
cp /tmp/openvpn/EasyRSA-3.0.5/pki/issued/server.crt /tmp/openvpn/server/certificates/server.crt
cp /tmp/openvpn/EasyRSA-3.0.5/pki/private/server.key /tmp/openvpn/server/certificates/server.key

mkdir /tmp/openvpn/client/
mkdir /tmp/openvpn/client/certificates
cp /tmp/openvpn/EasyRSA-3.0.5/pki/ca.crt /tmp/openvpn/client/certificates/ca.crt
cp /tmp/openvpn/EasyRSA-3.0.5/pki/issued/client.crt /tmp/openvpn/client/certificates/client.crt
cp /tmp/openvpn/EasyRSA-3.0.5/pki/private/client.key /tmp/openvpn/client/certificates/client.key

Network configuration

Let's consider that the ssh server listens the 22 port and 443 for the VPN server.

Firewall rules

We have to define firewall rules in the file /etc/iptables/rules.v4:

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
# Forward the VPN traffic to eth0
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

COMMIT

*filter

# Allow all loopback (lo) traffic and reject anything
# to localhost that does not originate from lo.
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -s 127.0.0.0/8 -j REJECT
-A OUTPUT -o lo -j ACCEPT

# Allow ping and ICMP error returns.
-A INPUT -p icmp -m state --state NEW --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -p icmp -j ACCEPT

# Allow SSH.
-A INPUT -i eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 22 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state ESTABLISHED --sport 22 -j ACCEPT

# Allow TCP traffic.
-A INPUT -i eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 443 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state ESTABLISHED --sport 443 -j ACCEPT

# Allow DNS resolution and limited HTTP/S on eth0.
# Necessary for updating the server and keeping time.
-A INPUT -i eth0 -p udp -m state --state ESTABLISHED --sport 53 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m state --state NEW,ESTABLISHED --dport 53 -j ACCEPT

# Allow traffic on the TUN interface.
-A INPUT -i tun0 -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT

# then reject them.
-A INPUT -j REJECT
-A OUTPUT -j REJECT

COMMIT

Be sure to adapt these rules to your needs before applying them.

sudo iptables-restore < /etc/iptables/rules.v4

We can check if the rules are correctly implied:

sudo iptables -L

Enable ipv4 forwarding and disable ipv6

In the file /etc/sysctl.d/99-sysctl.conf, add the following lines to enable ipv4 forwarding and disable ipv6:

net.ipv4.ip_forward = 1

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1

and then apply the new configuration

sudo sysctl -p

Remove ipv6 lines in /etc/hosts:

#::1 localhost ip6-localhost ip6-loopback

Reject ipv6 traffic by editing the file /etc/iptables/rules.v6, it must contains:

*filter

-A INPUT -j REJECT
-A FORWARD -j REJECT
-A OUTPUT -j REJECT

COMMIT

and apply:

sudo ip6tables-restore < /etc/iptables/rules.v6

Examples of very secure configuration

In order to continue, we will use the highly secure configuration below. Be careful, you need to follow the tutorial until the end to make it workable.

Example of server configuration

Please copy the following code in /tmp/openvpn/server/server.conf. It is the OpenVPN server configuration. Don't forget to replace local IP_OF_YOUR_OPENVPN_SERVER by your server ip.

#/tmp/openvpn/server/server.conf
local IP_OF_YOUR_OPENVPN_SERVER
dev tun
topology subnet
proto tcp
port 443
server 10.8.0.0 255.255.255.0
tls-server

ca /etc/openvpn/server/certificates/ca.crt
# crl-verify /etc/openvpn/server/certificates/crl.pem
cert /etc/openvpn/server/certificates/server.crt
key /etc/openvpn/server/certificates/server.key
tls-crypt /etc/openvpn/server/certificates/tls_crypt.key

dh none
ecdh-curve ED25519
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
cipher AES-256-GCM
ncp-ciphers AES-256-GCM
tls-version-min 1.2
persist-tun
compress

persist-key
keepalive 10 120

user ovpn
group ovpn

status /var/log/openvpn-status.log
log /var/log/openvpn.log

push "redirect-gateway"
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option WINS 10.8.0.1"
push "route-ipv6 2000::/3"

Example of client configuration

Please copy the following code in /tmp/openvpn/client/client.conf. It is the OpenVPN client configuration. Don't forget to replace remote IP_OF_YOUR_OPENVPN_SERVER by your server ip and COMMON_NAME_OF_THE_SERVER_CERTIFICATE by the Common name you gave to the server certificate .cf Generating certificates.

# /tmp/openvpn/client
client
dev tun
remote IP_OF_YOUR_OPENVPN_SERVER 443
proto tcp
resolv-retry infinite
compress
nobind
verify-x509-name "COMMON_NAME_OF_THE_SERVER_CERTIFICATE" name
remote-cert-tls server
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
cipher AES-256-GCM
tls-version-min 1.2
auth-nocache
persist-key
persist-tun

status /var/log/openvpn-status.log
log /var/log/openvpn.log
verb 3

ca /etc/openvpn/client/certificates/ca.crt
cert /etc/openvpn/client/certificates/client.crt
key /etc/openvpn/client/certificates/client.key
tls-crypt /etc/openvpn/client/certificates/tls_crypt.key

Harden OpenVPN configuration

This part will describe most of the security parameters chosen in the final configuration.

TCP/IP protocol and port listening

In order to avoid most of firewall limit, it is highly recommended to switch from udp protocol to tcp. OpenVPN configured with TCP protocol is a little bit slower but it has more chances to be accessible from a network you do not control.

You also have to configure the OpenVPN server to listen the port 443. Port 443 is the usual port used by a web server configuration and it is most of the time open in firewall output. Moreover, it will also make your OpenVPN configuration harder to detect because it is not the standard OpenVPN port. The standard port is 1194.

proto tcp4
port 443

Diffie-Hellman

Diffie–Hellman key exchange is a method of securely exchanging cryptographic keys over a public channel. In OpenVPN, this protocol is used in the first steps of TLS establishment connection. With a key of 1024 bits and lower size, it is vulnerable to Logjam exploits. The authors of the vulnerability recommend using primes of 2048 bits or more as a defense or switching to elliptic-curve Diffie–Hellman. In this tutorial, we use elliptic-curve Diffie–Hellman

HMAC signature during TLS handshake

Since openVPN 2.4, it is recommended to replace tls-auth by tls-crypt. Mainly because tls-crypt will also encrypt the TLS control channel. That means, to add the following line in server.conf:

tls-crypt /etc/openvpn/certificates/ta.key 0

and generate the HMAC key file in the openvpn server directory and client directory:

openvpn --genkey --secret /tmp/openvpn/server/certificates/tls_crypt.key
cp /tmp/openvpn/server/certificates/tls_crypt.key /tmp/openvpn/client/certificates/tls_crypt.key

Persistent tun/tap device and key

While your connection might be interrupted and OpenVPN is trying to reconnect, you may be using the default network routes again, bypassing the tunnel. For accessing private networks this might not be a big issue as the network addresses may not be reachable from outside the tunnel, but it may expose information you'd rather keep private like an HTTP request containing cookies.

persist-key is not a security option but a problem solving in case OpenVPN restart and the OpenVPN user is not able to read the key file anymore. This parameter avoid this situation.

persist-tun
persist-key

Limited user

Probably one of the most important configuration setting. In order to limit the impact of an OpenVPN vulnerability, it is highly recommended to run it with a user with limited rights. To do that, we have to create a user for our OpenVPN applications. This user has limited privileges:

adduser --system --shell /usr/sbin/nologin --no-create-home ovpn
groupadd ovpn
usermod -a -G ovpn ovpn

and specify the user in the OpenVPN configuration:

user ovpn
group ovpn

Ciphers and digests

In the file /etc/openvpn/server.conf, we have to specify the ciphers and digest we want to use. It looks recommended to use GCM instead of CBC. More information about why here and here

tls-version-min 1.2
ncp-ciphers AES-256-GCM:AES-256-CBC
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
cipher AES-256-GCM
ecdh-curve ED25519
dh none

We will force to use SHA512 to manage the authentication mechanism. unfortately the best digest available is still sha family. Enabling the auth-nocache parameter will prevent to cache passwords in memory.

auth-nocache
auth SHA512

Compression algorithms

In the OpenVPN version 2.3, it was the LZ0 compression algorithm which was by default. Since OpenVPN version 2.4, the compression algorithm LZ4 is available. Contrary to what the documentation says, it is not the best one available. There is also the version 2, lz4-v2 of it which is available but not documented yet.

If security if your only criteria, you should disable this feature. Indeed, a family of vulnerability like Beast, Crime and Voracle exist . Those vulnerabilities could allow an attacker to gain information about an encrypted communication in very specific circumstances. To explain differently, if the attacker knows exactly what he is supposed to receive and capture enough packet with little predictable changes, this could help him to reduce the time required to break the encryption.

For me, in the real world, it is really complicated to use this kind of vulnerability. The OpenVPN company recommends to disable compression algorithm and already did it on their products. In the configuration files provide here, it is, of course, disable because we are only focused on security. Feel free to make some performance test with speedtest if you hesitate.

Pushing configuration to the client

OpenVPN is allowed to push some network rules to the server. The most important is push "redirect-gateway" which forces to route all the client traffic throw the vpn. This parameter replaces the gateway route in the client configuration.

A second very useful possibility is to push a route for ipv6 which does not work. This will avoid in case your client is configured to work with ipv6 to make it unusable.

push "route-ipv6 2000::/3"

Revoke and unrevoke a client

Revoke a client

Sometime, you want to revoke an access to the vpn to a client. OpenVPN uses Certification Revocation List (CRL) to determine if a certificate is revoked or not. You need to execute the following command:

./easyrsa revoke client
./easyrsa gen-crl

Those commands also modify the file index.txt in the directory of /tmp/openvpn/EasyRSA-3.0.5/pki. For our setup and since we had revoked client, this file should be like that.

V 893632988188Z CWGT67WFA9QLQ9YZ65VGB8FLJKUKV3JL unknown /CN=server R 943755258824Z Y9BFEB757EFV47Y9ENNBUGJLKGP9KQCD unknown /CN=client

As you can see,the first column is V or R. V means valide and R means Revoke. We also have a new file crl.pem in /tmp/openvpn/EasyRSA-3.0.5/pki. It is this file which contains the list of revoked certificate. We have to copy it in a place accessible for the OpenVPN application and modify server.confwith a command.

cp /tmp/openvpn/EasyRSA-3.0.5/pki/crl.pem /etc/openvpn/server/certificates/crl.pem
chown ovpn:ovpn /etc/openvpn/server/certificates/crl.pem
# in server.conf
crl-verify /etc/openvpn/server/certificates/crl.pem
systemctl restart openvpn

Unrevoke a client

The certificate revocation list contains is a unique value even if you revoke multiple client certificate. If you want to unrevoke a client, you need to generate a new certificate revocation list. To do that, you need to modify /tmp/OpenVPN/EasyRSA-3.0.5/index.txt and replace the R for the certificate by V then generate a new certificate revocation list and finally replace the crl.pem loaded by OpenVPN.

Tuning and performance improvement

OpenVPN could be tuned in a lot of way to improve performance. I will not talk a lot about that because it requires an article by his own. You could change for example, the encryption algorithm, the TCP/IP protocol or modify those parameters to improve it.

  • mssfix
  • fragment
  • tun-mtu
  • compression algorithm

Feel free to read this page to know more about tuning OpenVPN.

Deployement and cleaning

Congratulation! The most complicated part is over. We just have now to deploy each directory in the proper place.

Directory structure

You should have this directory structure in /tmp/openvpn/server/. The server will need the following files to run properly:

  • server.conf
  • certificates/ca.crt
  • certificates/crl.pem
  • certificates/server.key
  • certificates/server.crt
  • certificates/tls_crypt.key

You should now have this directory structure in /tmp/openvpn/client/. The client will need the following files to run properly:

  • client.conf
  • certificates/client.crt
  • certificates/client.key
  • tls_crypt.key

A reader made a very good comment about the client configuration file. You can summarize in client.conf all the cryptography data required to establish the connection to the OpenVPN server. It makes it easier to transport and manage. To do that, you should remove the line about ca, cert, key and tls-crypt and replace them with the following lines.

<ca>
--STRIPPED INLINE CA CERT--
</ca>
<cert>
--STRIPPED INLINE CERT--
</cert>
<key>
--STRIPPED INLINE KEY--
</key>
<tls-crypt>
--STRIPPED INLINE KEY--
</tls-crypt>

Last configuration and deployement

Before moving directories, we will make them available only for the root user in reading mode.

chmod 400 -R /tmp/openvpn/

We will also move the all public and private key to a safe place and move the server directory to the right place:

cp -r /tmp/openvpn/server /etc/openvpn/
cp -r /tmp/openvpn/ /etc/ssl/openvpn-pki
ln -s /etc/openvpn/server/server.conf /etc/openvpn/server.conf

In the client which should be another computer. You just have to copy and paste the directory /tmp/openvpn/client to /etc/openvpn/ and create a symbolic link from /etc/openvpn/client/client.conf to /etc/openvpn/client.conf

Running

To run OpenVPN with Systemd, you need to modify /etc/default/openvpn by uncommenting AUTOSTART="all" and replacing "all" by the name of configuration file. For example with in the server side, you should replace "all" by "server".

systemctl daemon-reload

You are now able to run it with systemctl and the following command:

systemctl start openvpn

You need to do the same thing for the client.

Cleaning

Be careful, do not forget to remove the directory /tmp/openvpn. It contains all your certificates.

Conclusion

Social media

Thank you for your reading, I hope this article was helpful for you. Don't hesitate to comment and if you think I made a mistake, it will be a pleasure to discuss it. If you find this article interesting, feel free to subscribe to the RSS flux of the blog and to follow me on Mastodon.

Sources

This article would not have been possible if other people does not share information about it. Their work help me a lot, thank you!

Updates:
  • 31/07/2019 : Replace TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 by TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384. As the root certificate was built with elliptic curve secp521, it is not possible to use it to sign a certificate with the RSA algorithme, only ECDSA.

16 comments

#1  - THOMAS J MUNN said :

If you were going to use ECC, I recommend using ED25519, as most of the nist curves are suspect.

Reply
#2  - Mirabellette said :

I agree, thank you for your reply :)

Reply
#3  - m said :

You go to the trouble of making a secure openvpn tutorial but don't verify the tool you use to create the keys?

Reply
#4  - Mirabellette said :

Most of the time, the main vulnerability is not using a not enough secure cipher but a misconfiguration. However, I trust without research about EasyRSA and I did not enough research about the curve offered here. It will be updated in a soon future.

Thank you for your reply :)

Reply
#5  - Richard Browler said :

Following your tutorial, the log file shows the following issue:

Failed to use supplied curve (UNDEF), using secp384r1 instead.
ECDH curve secp384r1 added.

Using OpenVPN 2.4.0.
ecdh-curve ED25519 is available in the config file.

What can be causing this problem?

Reply
#6  - donethisbefore said :

Run 'openvpn --show-curves' and pick one of those for your ecdh-curve. In most cases, ed25519 is NOT one of those choices, which is where you're running afoul.

Your next question will probably be "OK, now, which curve should I use?" Not my blog, but you can then google "difference between elliptic curves". Some of the curves were developed with the help of spooks, so they come with some suspicion (may be right, may be unfounded), yet are part of standards so have wide interoperability.

I have no advice here beyond "ed25519 is not a valid choice for ecdh, see --show-curves, pick something else."

Reply
#7  - PP1 said :

Hello,
thanks for the awesome tutorial, which I've followed step by step. I'm experiencing some difficulties though.

When connecting, on client, I'm getting:
Mon Jul 29 22:19:11 2019 OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 25 2019
Mon Jul 29 22:19:11 2019 Windows version 6.1 (Windows 7) 64bit
Mon Jul 29 22:19:11 2019 library versions: OpenSSL 1.1.0j 20 Nov 2018, LZO 2.10
Enter Management Password:
Mon Jul 29 22:19:12 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]123.456.789.012: 12345
Mon Jul 29 22:19:12 2019 Attempting to establish TCP connection with [AF_INET]123.456.789.012: 12345 [nonblock]
Mon Jul 29 22:19:13 2019 TCP connection established with [AF_INET]123.456.789.012: 12345
Mon Jul 29 22:19:13 2019 TCP_CLIENT link local: (not bound)
Mon Jul 29 22:19:13 2019 TCP_CLIENT link remote: [AF_INET]123.456.789.012: 12345
Mon Jul 29 22:19:13 2019 Connection reset, restarting [0]
Mon Jul 29 22:19:13 2019 SIGUSR1[soft,connection-reset] received, process restarting
Mon Jul 29 22:19:18 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]123.456.789.012: 12345
Mon Jul 29 22:19:18 2019 Attempting to establish TCP connection with [AF_INET]123.456.789.012: 12345 [nonblock]
Mon Jul 29 22:19:20 2019 TCP connection established with [AF_INET]123.456.789.012: 12345
Mon Jul 29 22:19:20 2019 TCP_CLIENT link local: (not bound)
Mon Jul 29 22:19:20 2019 TCP_CLIENT link remote: [AF_INET]123.456.789.012: 12345
Mon Jul 29 22:19:20 2019 Connection reset, restarting [0]
Mon Jul 29 22:19:20 2019 SIGUSR1[soft,connection-reset] received, process restarting
Mon Jul 29 22:19:24 2019 SIGTERM[hard,init_instance] received, process exiting

I checked log on server:
Mon Jul 29 22:17:07 2019 OpenVPN 2.4.7 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 20 2019
Mon Jul 29 22:17:07 2019 library versions: OpenSSL 1.1.1c 28 May 2019, LZO 2.10
Mon Jul 29 22:17:07 2019 TUN/TAP device tun0 opened
Mon Jul 29 22:17:07 2019 /sbin/ip link set dev tun0 up mtu 1500
Mon Jul 29 22:17:07 2019 /sbin/ip addr add dev tun0 10.8.0.1/24 broadcast 10.8.0.255
Mon Jul 29 22:17:07 2019 Could not determine IPv4/IPv6 protocol. Using AF_INET
Mon Jul 29 22:17:07 2019 Listening for incoming TCP connection on [AF_INET]192.168.2.202:12345
Mon Jul 29 22:17:07 2019 TCPv4_SERVER link local (bound): [AF_INET]192.168.2.202:12345
Mon Jul 29 22:17:07 2019 TCPv4_SERVER link remote: [AF_UNSPEC]
Mon Jul 29 22:17:07 2019 GID set to ovpn
Mon Jul 29 22:17:07 2019 UID set to ovpn
Mon Jul 29 22:17:07 2019 Initialization Sequence Completed
Mon Jul 29 22:18:44 2019 TCP connection established with [AF_INET]192.168.1.1:61143
Mon Jul 29 22:18:45 2019 192.168.1.1:61143 OpenSSL: error:1414D17A:SSL routines:tls12_check_peer_sigalg:wrong curve
Mon Jul 29 22:18:45 2019 192.168.1.1:61143 TLS_ERROR: BIO read tls_read_plaintext error
Mon Jul 29 22:18:45 2019 192.168.1.1:61143 TLS Error: TLS object -> incoming plaintext read error
Mon Jul 29 22:18:45 2019 192.168.1.1:61143 TLS Error: TLS handshake failed
Mon Jul 29 22:18:45 2019 192.168.1.1:61143 Fatal TLS error (check_tls_errors_co), restarting
Mon Jul 29 22:18:49 2019 TCP connection established with [AF_INET]192.168.1.1:61144
Mon Jul 29 22:18:51 2019 192.168.1.1:61144 OpenSSL: error:1414D17A:SSL routines:tls12_check_peer_sigalg:wrong curve
Mon Jul 29 22:18:51 2019 192.168.1.1:61144 TLS_ERROR: BIO read tls_read_plaintext error
Mon Jul 29 22:18:51 2019 192.168.1.1:61144 TLS Error: TLS object -> incoming plaintext read error
Mon Jul 29 22:18:51 2019 192.168.1.1:61144 TLS Error: TLS handshake failed
Mon Jul 29 22:18:51 2019 192.168.1.1:61144 Fatal TLS error (check_tls_errors_co), restarting

Any idea, what the issue might be?

Also, I've noticed two discrepancies between your copy-pastes for server.conf, client.conf against hardening section:
* missing auth SHA512
* tls_cipher

Thank you :)

Reply
#8  - PP1 said :

After ensuring, the auth SHA512 in both server.conf and client.conf, tls_cipher same as you advise in hardening (TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384) and
ncp-ciphers AES-256-GCM:AES-256-CBC, I'm getting following output log:

Mon Jul 29 22:38:10 2019 TCP connection established with [AF_INET]192.168.1.1:61256
Mon Jul 29 22:38:11 2019 192.168.1.1:61256 TLS error: The server has no TLS ciphersuites in common with the client. $
Mon Jul 29 22:38:11 2019 192.168.1.1:61256 OpenSSL: error:1417A0C1:SSL routines:tls_post_process_client_hello:no sha$
Mon Jul 29 22:38:11 2019 192.168.1.1:61256 TLS_ERROR: BIO read tls_read_plaintext error
Mon Jul 29 22:38:11 2019 192.168.1.1:61256 TLS Error: TLS object -> incoming plaintext read error
Mon Jul 29 22:38:11 2019 192.168.1.1:61256 TLS Error: TLS handshake failed
Mon Jul 29 22:38:11 2019 192.168.1.1:61256 Fatal TLS error (check_tls_errors_co), restarting
Mon Jul 29 22:38:16 2019 TCP connection established with [AF_INET]192.168.1.1:61257
Mon Jul 29 22:38:17 2019 192.168.1.1:61257 TLS error: The server has no TLS ciphersuites in common with the client. $
Mon Jul 29 22:38:17 2019 192.168.1.1:61257 OpenSSL: error:1417A0C1:SSL routines:tls_post_process_client_hello:no sha$
Mon Jul 29 22:38:17 2019 192.168.1.1:61257 TLS_ERROR: BIO read tls_read_plaintext error
Mon Jul 29 22:38:17 2019 192.168.1.1:61257 TLS Error: TLS object -> incoming plaintext read error
Mon Jul 29 22:38:17 2019 192.168.1.1:61257 TLS Error: TLS handshake failed
Mon Jul 29 22:38:17 2019 192.168.1.1:61257 Fatal TLS error (check_tls_errors_co), restarting

Reply
#9  - Mirabellette said :

Hello,
I am happy you like it :)

If your read your log carefully, you can read "The server has no TLS ciphersuites in common with the client. ".

You have to set them in both server side and client side. You can verify the cipher suite you chose is well available on both side with the command `openvpn --show-curves`

Reply
#10  - PP1 said :

Hello, thanks for the fast response.
I've followed your steps provided in hardening precisely, exactly same setup.

Alternatively, please what is "correct" - recommended setting? The one in sample files at the top of the page, or one described in Ciphers and digests section.

Still, have no clue what could be wrong, since I followed your steps very precisely. Server is running on rasbpian buster, client is w7x64 with latest OpenVPN.

Reply
#11  - PP1 said :

Also, do you recommend using
TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
instead of TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384?

Reply
#12  - Mirabellette said :

From what I read and think, you can't use RSA (from the TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384) as signature algorithm when you have a root certificate which is a elliptic curve certificate. You have to switch to TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 or, if it is not available, generate a root certificate with RSA and use TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384. Thank you for your return, I fixed the mistake.

In this tutorial, all the certificate chain is built with elliptic curve (especially secp521).

sources https://security.stackexchange.com/questions/65623/ecdsa-rsa-certificates-and-cipher-selection/65629#65629

Reply
#13  - PP1 said :

So, I have double checked - both my server (rpi3 running buster) and my win7x64 list TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 as one of options when I run openvpn --show-tls

Reply
#14  - PP1 said :

Hello Mirabellette,
back from the holiday, trying to finish the vpn configuration.
Following your tutorial this time, vpn connection works, I had to open port 123 on rpi in order to keep date synchronized.

While I can access local network from vpn, e.g. my router by its IP (192.168.1.1), I cannot reach any website, nor by typing http://ip_address directly via vpn.

Please could you help?

Reply
#15  - PP1 said :

When I
push "dhcp-option DNS 192.168.2.1", internet works.
But if I understood it correctly, it's not the way it's meant to be.
By pushing 10.8.0.1, dns should be handled by openvpn, what doesn't seem to be the case.

Reply
#16  - Healt Care Medicine said :

very helpful article and informative also. thanks for sharing the article.

Reply

Rss feed of the article's comments

Write a comment

What is the second letter of the word sphll?