This document contains some information about the security of the software, more specifically: the configuration choices that were made.
The basic OpenVPN server (and client) crypto configuration:
tls-version-min 1.2 tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 dh none ncp-ciphers AES-256-GCM cipher AES-256-GCM tls-crypt /path/to/tls-crypt.key
TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 as TLS cipher because it is
listed in RFC 7525 (section 4.2). It was
the only cipher that could be used with RSA keys and AES-256-GCM. Furthermore,
ECDHE is faster than DHE.
For the data channel we chose to use
We do not specify the
auth OpenVPN configuration option as it is no longer
used when using an AEAD cipher like
tls-cipher option is only used with TLSv1.2. When a TLSv1.3
connection is established it is ignored. TLSv1.3 has a limited selection of
algorithms that are all secure, no need to put any restriction on it.
NOTE: vpn-user-portal >= 2.3.4 and vpn-server-node >= 2.2.4 add support for
ECDSA TLS cipher
TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 to support
ECDSA certificates on TLSv1.2 connections. It was already supported when a
TLSv1.3 connection was used.
Starting from vpn-server-api 2.1.1 there no longer is a “global”
key that is the same for all profiles. From this version on all new
installations will use a
tls-crypt key per profile.
NOTE: if you already installed your VPN server before the release of
vpn-server-api 2.1.1 you will continue to use the same
tls-crypt key for all
profiles. If you want to switch to using one key per profile you need to
To apply the configuration changes:
$ sudo vpn-maint-apply-changes
If the command is not available, install the
vpn-maint-scripts package first.
Please be aware that existing clients will need to fetch a new configuration, unless the eduVPN or Let’s Connect! apps are used where that will happen automatically.
CentOS 7 by default provides PHP 5.4. This is not without risks. This version is no longer maintained by the PHP project and depends fully on the Red Hat engineers that update it when (security) issues appear.
resources/ directory for PHP setting changes.
We use fkooman/secookie, a library to implement secure PHP sessions (and cookies).
The built-in OAuth server
uses public key cryptography signed JWT Bearer tokens of the type
implemented in php-jwt. The
JWT token in specified in RFC 8037.
The reason we are using public key cryptography for the Bearer tokens is that no “back channel” is needed between the services verifying the token and issuing the token. This is especially helpful in the case of Guest Usage.
The CA of the VPN service is “online” as it needs to generate valid certificates on the fly. The vpn-ca software is used as CA.
By default the CA uses
RSA with keys of length 3072 bits, and signs using
The CA also supports
ECDSA with the NIST P-384 (secp384r1) curve, and
Ed25519. Refer to the next section to see what is possible.
From vpn-server-api 2.3.0, ECDSA is the default. If the CA was initialized before the upgrade to 2.3.0, ECDSA will only be used for new server and client certificates. New installations of the server will use ECDSA for the CA as well.
TLS Algorithm Support#
From the point of view of the VPN server the following tables can help to figure out which algorithms are supported.
|Debian 10, 11||TLSv1.2, TLSv1.3|
Whenever possible, the client/server will use the highest TLS version. As for which types of keys are supported by the VPN server:
|CA||CentOS 7||Fedora||Debian 10, 11|
The client plays an important role here. In order to support
EdDSA the client
MUST support TLSv1.3, and support storing
EdDSA keys in its key store.
When using TLSv1.2, the server and client
tls-cipher option are consulted,
this option is ignored when using TLSv1.3. When introducing
ECDSA support, we
had to add an additional
tls-cipher just for the TLSv1.2 case to both the
client and server OpenVPN configuration, otherwise only
RSA was allowed. As
only TLSv1.3 supports
EdDSA, we did not need to modify anything for this
scenario, but using
EdDSA is restricted to “modern” VPN servers. Only servers
(and clients) using OpenSSL >= 1.1.1 support TLSv1.3 (and
NOTE in order to support
ECDSA on CentOS 7 you need to run
vpn-user-portal >= 2.3.4 and vpn-server-node >= 2.2.4 on your server.
Switching Key Type#
Switching to another key type from RSA is easy. Modify
/etc/vpn-server-api/config.php and set the
vpnCaKeyType option, as an
example we switch to ECDSA:
<?php return [ //'vpnCaKeyType' => 'RSA', 'vpnCaKeyType' => 'ECDSA', //'vpnCaKeyType' => 'EdDSA', 'vpnProfiles' => [ // ...
If you want your entire CA, including the Root CA to use the same algorithm,
you can “reset” your server’s data. Note that this is OPTIONAL. It works
perfectly fine just switching the
In case you want to continue with the reset, you can run the following command:
$ sudo vpn-maint-reset-system
This will re-initialize the VPN server and bring it back to “defaults”, it will
remove all data, but not the configuration and recreate the CA with the
NOTE: if you are using the default username/password authentication module,
all users will be lost on “reset” and you need to add them again using
$ sudo vpn-user-portal-add-user