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