Harden openvpn Tunnel

[stephdl]

Following this https://bettercrypto.org/static/applied-crypto-hardening.pdf we learnt that :

OpenVPN uses TLS only for authentication and key exchange. The bulk traffic is then encrypted
and authenticated with the OpenVPN protocol using those keys.
Note that while the tls-cipher option takes a list of ciphers that is then negotiated as usual with
TLS, the cipher and auth options both take a single argument that must match on client and
server.

We have more interesting informations from a openvpn dev at BetterCrypto/Applied-Crypto-Hardening#91 (comment)

In short for what he said, we cannot specify the option tls-version-min 1.0 (or 1.1/1.2) because it could break some configurations. Or of course we could test it as beta.

Hence we could give the cipher list as it is suggested in the documentation we follow

tls-cipher DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM-\
\SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-CAMELLIA256-SHA:DHE-RSA-AES256-SHA:DHE-RSA\
\-CAMELLIA128-SHA:DHE-RSA-AES128-SHA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:\
\AES128-SHA

we have also a good documentation to follow https://community.openvpn.net/openvpn/wiki/Hardening

[stephdl]

--tls-auth add a PSK that must be shared among all clients, it could be also a good hardened setting in openvpn

https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-auth

[stephdl]

Proposals and talk to harden openssl tunnel

Openvpn works with two channels, the control and the data, each one could be enforced like I will try to explain, the topology also gets its specific settings, for example the control channel could not be hardened for the p2p topology, only the data one could have an option more, It is the --tls-cipher that I will propose.

Please feel free to comment @DavidePrincipi and @gsanchietti.

First I would talk about the cipher option we have, used to encrypt the data channel, we propose to use weak cipher in the dropdown of the advanced settings (openvpn tunnel page), if you do openvpn --show-ciphers you will see that the first ciphers are strong, but the end of the list is weak and we are not encouraged to use them because they are deprecated (less than 128 bit). Maybe we need to remove them or of course let them here for backward compatibility with the mention deprecated.

If we need to remove or enforce settings we must think about backward compatibily between different openvpn version, we have a tools to know what version id used, crossing several distributions: https://pkgs.org/download/openvpn

Still relative to cipher, we list in the dropdown several ciphers which are not compatible with the P2P topology, this will drive to a crash of the openvpn service. You can check what ciphers are relevant by openvpn --show-ciphers. From my point of view, either we need two dropdown (one for each topology, or list in the dropdown what cipher are associated)

When no cipher is used, I mean cipher auto, the BF-CBC is used which is a 64 bit encryption, which is deprecated and no longer recommended (see man openvpn). We could either set a list of ciphers to negotiate ( --ncp-ciphers cipher_list) or specify a strong cipher per default.

the --auth setting is not used by Nethserver, if not specified, the default is SHA1 which is 160 bit, we could propose a stronger one ( see openvpn --show-digests) or a dropdown to choose it

• topology p2p

  • --auth alg(data channel)
    We can enforce the HMAC (message authentication algorithm), default is SHA1.
    For cipher available we could do openvpn --show-digests and for example we must do in both server and client conf auth SHA512

  • --cipher alg(data channel)
    for the cipher I have a big doubt, we do not filter the cipher list and some ciphers are incompatible with the topology p2p, it ends by the fail of the service start when you want to use a cipher, listed as incompatible
    do openvpn --show-ciphers and check AES-256-GCM (256 bit key, 128 bit block, TLS client/server mode only) and in log Sat May 19 10:44:06 2018 Cipher 'AES-256-GCM' mode not supported if you use the option cipher AES-256-GCM in the server configuration.
    If no cipher is set, then BF-CBC (an abbreviation for Blowfish) is used and it is not recommended by the man page,because of its 64-bit block size.

• topology subnet

  • --auth alg(data channel)
    We can enforce the HMAC (message authentication algorithm), default is SHA1.
    For cipher available we could do openvpn --show-digests and for example we could do in both server and client conf auth SHA512
  • --cipher alg(data channel)
    From my point of view we could remove the weak cipher list, but of course it is a choice we must think for backward compatibility. If no cipher is set, then BF-CBC (an abbreviation for Blowfish) is used and it is not recommended by the man page,because of its 64-bit block size.
  • --tls-cipher cipherlist(control channel)
    this a method to determine which cipher are used to protect the control channel, available cipher are visible with openvpn --show-tls. you can see which list is recommended at https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-cipher
  • --tls-auth keyfile(control channel)
    see https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-auth. In short we could Add an additional layer of HMAC authentication on top of the TLS control channel to mitigate DoS attacks and attacks on the TLS stack. In a nutshell, --tls-auth enables a kind of "HMAC firewall" on OpenVPN's TCP/UDP port, where TLS control channel packets bearing an incorrect HMAC signature can be dropped immediately without response.
    The key must be in the opposite sens between server and client (eg o->1)
  • --tls-crypt keyfile(control channel)
    Encrypt and authenticate all control channel packets with the key from keyfile. It provides more privacy by hiding the certificate used for the TLS connection, it makes harder to identify OpenVPN traffic as such, but, but ONLY INTRODUCED FOR OPENVPN2.4

as a side note, comp-lzo is now obsolete, but with no removal date, we should use --compress. see https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#a--comp-lzo

[gsanchietti]

NS is not built for security gurus, we need to find a good balance between security and ease of use.

In short for what he said, we cannot specify the option tls-version-min 1.0 (or 1.1/1.2) because it could break some configurations.

Let's add it to the "Advanced" section.

Maybe we need to remove them or of course let them here for backward compatibility with the mention deprecated

I agree, let's mark them as deprecated.

If we need to remove or enforce settings we must think about backward compatibily between different openvpn version

We can just enforce safer defaults for new tunnel servers since they are often used with other NethServer.

From my point of view, either we need two dropdown (one for each topology, or list in the dropdown what cipher are associated)

I'd go for the latter solution: add a label inside the current dropdown. Something like "XXXX-XX (subnet only)", and eventually add a validator to check if the selected policy can work with the current topology.

When no cipher is used, I mean cipher auto, the BF-CBC is used which is a 64 bit encryption, which is deprecated and no longer recommended (see man openvpn). We could either set a list of ciphers to negotiate ( --ncp-ciphers cipher_list) or specify a strong cipher per default.

This is not entirely true: OpenVPN 2.4 automatically negotiate a stronger policy.
I'd prefer to not change this behavior.

the --auth setting is not used by Nethserver, if not specified, the default is SHA1 which is 160 bit, we could propose a stronger one ( see openvpn --show-digests) or a dropdown to choose it

I agree, let's add it to "Advanced" section.

Recap

• For both typologies: do not enforce --auth
• Cipher list:
  • mark old ciphers with "deprecated" label
  • label ciphers available only for subnet topology
  • add a validator to check if the selected cipher can work with current topology
• Add to "Advanced" section
  • auth
  • tls-version-min
• Disable compression by default

I think the following options are too complex (experienced users can use template-custom):

• tls-crypt
• tls-cipher
• tls-auth

[stephdl]

Testing case

Two new settings

• digest (need to be the same on the two end of the tunnel, else you will find a warning in log that the negociated cipher is TLSv1.2 and AES-256-GCM)
• tls-version-min Enforce a minimum TLS version
  only on the VPN server: accept a minimum tls policy for the control channel, option not set it is tls1.0

The digest part must be in the vpn client configuration that you can download.

Now you can see the digest and the cipher with a strong tag, at least 192 bit for cipher and 256 bit for digest. lower is tagged as weak.

• Verify that you cannot use a cipher not CBC for the topology P2P (only CBC for P2P)
• Verify that the change in tls-version-min are reflected in the vpn server configuration (templated file)
• Verify that the vpn is workable with different setting of tls-version-min
• Verify that you can create a tunnel with specific digest and cipher
• Verify that lzo-comp is disabled by default when you create a tunnel

[stephdl]

As a side note if you do not set the values, openvpn negotiates itself
TLSv1.2 and AES-256-GCM and also if the parameters auth and cipher are not identical at the two ends. This is readable in log

@gsanchietti was right :D

This is not entirely true: OpenVPN 2.4 automatically negotiate a stronger policy.
I'd prefer to not change this behavior.

[stephdl]

• think for translation

[stephdl]

@cotosso do you have some inputs

[nethbot]

in 7.5.1804/testing:

• nethserver-openvpn-1.6.11-1.3.g2153e31.ns7.noarch.rpm

[stephdl]

Verification check post above

[cotosso]

I 've installed and tested the rpm.
Probably there is a mistake in a sentence of the test case:
Verify that you cannot use a cipher CBC for the topology SUBNET

In fact the SUBNET topology can use every cipher whereas p2p topology allows you only to use a small subset of ciphers (CBC). The validator of the web page correctly blocks you if you try to use "non CBC" cipher with p2p topology.

Said that everything seems to work flawlessy for every test case, when I tried to use specific digest and cipher it worked as expected:

Server Side:

Fri Jun 15 15:29:43 2018 192.168.5.115:1194 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Fri Jun 15 15:29:43 2018 192.168.5.115:1194 [cipher] Peer Connection Initiated with [AF_INET]192.168.5.115:1194 (via [AF_INET]192.168.5.113%ens32)
Fri Jun 15 15:29:43 2018 cipher/192.168.5.115:1194 OPTIONS IMPORT: reading client specific options from: ccd/cipher
Fri Jun 15 15:29:43 2018 cipher/192.168.5.115:1194 MULTI_sva: pool returned IPv4=10.151.173.2, IPv6=(Not enabled)
Fri Jun 15 15:29:43 2018 cipher/192.168.5.115:1194 MULTI: Learn: 10.151.173.2 -> cipher/192.168.5.115:1194
Fri Jun 15 15:29:43 2018 cipher/192.168.5.115:1194 MULTI: primary virtual IP for cipher/192.168.5.115:1194: 10.151.173.2
Fri Jun 15 15:29:43 2018 cipher/192.168.5.115:1194 MULTI: internal route 10.30.40.0/24 -> cipher/192.168.5.115:1194
Fri Jun 15 15:29:43 2018 cipher/192.168.5.115:1194 MULTI: Learn: 10.30.40.0/24 -> cipher/192.168.5.115:1194
Fri Jun 15 15:29:44 2018 cipher/192.168.5.115:1194 PUSH: Received control message: 'PUSH_REQUEST'
Fri Jun 15 15:29:44 2018 cipher/192.168.5.115:1194 SENT CONTROL [cipher]: 'PUSH_REPLY,topology subnet,route 10.20.30.0 255.255.255.0,route-gateway 10.151.173.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.151.173.2 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)
Fri Jun 15 15:29:44 2018 cipher/192.168.5.115:1194 Data Channel: using negotiated cipher 'AES-256-GCM'
Fri Jun 15 15:29:44 2018 cipher/192.168.5.115:1194 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

Client Side:

Fri Jun 15 15:29:43 2018 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Fri Jun 15 15:29:43 2018 [NethServer CA] Peer Connection Initiated with [AF_INET]192.168.5.113:1236
Fri Jun 15 15:29:44 2018 SENT CONTROL [NethServer CA]: 'PUSH_REQUEST' (status=1)
Fri Jun 15 15:29:44 2018 PUSH: Received control message: 'PUSH_REPLY,topology subnet,route 10.20.30.0 255.255.255.0,route-gateway 10.151.173.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.151.173.2 255.255.255.0,peer-id 0,cipher AES-256-GCM'
Fri Jun 15 15:29:44 2018 OPTIONS IMPORT: timers and/or timeouts modified
Fri Jun 15 15:29:44 2018 OPTIONS IMPORT: --ifconfig/up options modified
Fri Jun 15 15:29:44 2018 OPTIONS IMPORT: route options modified
Fri Jun 15 15:29:44 2018 OPTIONS IMPORT: route-related options modified
Fri Jun 15 15:29:44 2018 OPTIONS IMPORT: peer-id set
Fri Jun 15 15:29:44 2018 OPTIONS IMPORT: adjusting link_mtu to 1624
Fri Jun 15 15:29:44 2018 OPTIONS IMPORT: data channel crypto options modified
Fri Jun 15 15:29:44 2018 Data Channel: using negotiated cipher 'AES-256-GCM'
Fri Jun 15 15:29:44 2018 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

Control channel uses specified Digest and cipher, whereas Data channel uses AES-256-CGM cipher

[nethbot]

in 7.5.1804/updates:

• nethserver-openvpn-1.6.12-1.ns7.noarch.rpm

[stephdl]

relased as 1.6.12