TLS Control Channel Security in OpenVPN Access Server

Introduction

This document provides details about how TLS control channel security works in OpenVPN Access Server, how to change the TLS control channel security in use by the server and clients, and the impact of making these changes.

TLS Control Channel Security in OpenVPN Access Server

The OpenVPN protocol uses two communication channels during a VPN session: the control channel, which handles authentication, key negotiation, and configuration; and the data channel, which encrypts and transports packets.

OpenVPN Access Server version 2.9 and newer uses TLS Auth, TLS Crypt, or TLS Crypt v2 to secure the control channel. With TLS Auth, the control channel is secured by signing and verifying the packets with a shared group key. TLS Crypt improves upon TLS Auth by adding symmetric encryption to the control channel. This extra layer of encryption applies even to the key-exchange before the TLS session starts. TLS Auth and TLS Crypt provide protection against TLS-level attacks with post-quantum resistance if the pre-shared keys are kept secret. TLS Crypt v2 improves on TLS Crypt by using a unique key per connection profile.

OpenVPN Access Server 2.8 and previous versions use TLS Auth by default. When you upgrade to Access Server version 2.9, it continues to accept connection profiles with TLS Auth for backwards compatibility and generates new connection profiles, when possible, with TLS Crypt v2. This allows a graceful migration of an existing setup with older connection profiles to a more secure setup. For a new installation using OpenVPN Access Server version 2.9, TLS Crypt is used by default. While it may be preferable to use TLS Crypt v2 for security reasons, TLS Crypt is the default for compatibility reasons.

It is possible to run OpenVPN Access Server without additional control channel security — an example use case for this is connecting devices that don’t support TLS Auth or when it doesn’t provide added security, such as using a server-locked profile with a publicly distributed group key.

OpenVPN Access Server version 2.9 and newer can generate and accept TLS Crypt v2 connection profiles even if the TLS control channel security level is set to TLS Auth or TLS Crypt. OpenVPN Connect v2.7.111 and v3.2 and newer can use TLS Crypt v2, and the installers that Access Server provides for macOS and Windows contain TLS Crypt v2 profiles. OpenVPN Connect v3.3 and newer obtains TLS Crypt v2 profiles by default when importing a profile with the import from URL function in the app. For compatibility reasons, the default profile downloaded from the Client UI adheres to the TLS control channel security setting as configured in OpenVPN Access Server, because not all OpenVPN client versions support TLS Crypt v2.

Note: We don’t recommend disabling TLS control channel security, but if you need to do this for certain devices, note that it is not a user-specific setting. The signing and verification of packets works as a filter, similar to a software firewall, so unsigned packets that don’t pass the verification filter are dropped very early during packet processing.

Changing the TLS control channel security setting

You can configure the TLS control channel security in the Admin Web UI under Configuration > Advanced VPN, or you can configure it using the command line.

Beginning in Access Server 2.9.0, TLS Crypt is the default TLS control channel security setting. Prior versions of Access Server set TLS Auth as the default. OpenVPN Access Server 2.8 and previous use the configuration key vpn.server.tls_auth to turn on or off the additional TLS control channel security using the TLS Auth method. When Access Server 2.9.0 or newer detects the presence of this configuration value in your configuration database, it adheres to that setting. However, if the configuration value vpn.server.tls_cc_security is present, that takes precedence. If neither key is present, the default TLS Crypt setting applies.

You can choose from these values:

• none: No additional signing or verification is done on packets.
• tls-auth: Uses a shared group key to sign and verify packets.
• tls-crypt: The same as tls-auth, but also encrypts the TLS control channel (default).
• tls-cryptv2: The same as above, but uses a per-client key instead of a shared group key.

Note: If the TLS control channel security is set to tls-auth or tls-crypt either explicitly or through a default setting, Access Server continues to generate new connection profiles with TLS Crypt v2 when possible and accepts connections from those profiles. This is to ensure Access Server continues to use TLS Crypt v2 and retain compatibility with TLS Auth or TLS Crypt for existing connection profiles or older OpenVPN client programs.

Access Server 2.9+

Configure the TLS Crypt v2 setting from the command line:

./sacli --key "vpn.server.tls_cc_security" --value "tls-cryptv2" ConfigPut
./sacli start

Delete the configuration key to restore the default behavior:

./sacli --key "vpn.server.tls_cc_security" ConfigDel
./sacli start

Older Access Servers (versions 2.8.x and previous)

Enable TLS Auth (default):

./sacli --key "vpn.server.tls_auth" --value "true" ConfigPut
./sacli start

Disable TLS Auth:

./sacli --key "vpn.server.tls_auth" --value "false" ConfigPut
./sacli start

Consequences of changing the TLS control channel security setting

For new installations of OpenVPN Access Server, changing the TLS control channel security settings shouldn’t be a problem because there likely aren’t any existing VPN clients that are impacted. For existing installations with many VPN clients installed and configured, changing the TLS control channel security setting without updating the connection profiles on the client devices may result in connection failures. Whether or not connection failures occur depends on the type of connection profiles that are in use by the VPN clients. After changing the setting, VPN clients that can’t connect must get a new connection profile and/or update the VPN client software to a version that supports the level of TLS control channel security.

Compatibility of control channel security configured on Access Server with listed OpenVPN client programs

Note: OpenVPN Connect v3.2 can use TLS Crypt v2 type connection profiles, but importing a profile from URL from an Access Server that isn’t configured for TLS Crypt v2 control channel security results in an imported profile with that specific setting. OpenVPN Connect v3.3 and newer retrieves a TLS Crypt v2 connection profile if the server is Access Server 2.9 or newer when the import from URL function is used.

Compatibility of control channel security setting configured on Access Server with listed connection profile types

Notes: Server-locked profiles from Access Server 2.8 or older use the web service to retrieve a user-locked type profile from the server every time that type of connection starts. Therefore, this type of connection profile can establish connections no matter the control channel security configuration setting. Newer, server-locked profiles from Access Server 2.9 work differently and do not communicate through the web service, but function as any other type of connection profile. An advantage of the newer type of server-locked connection profiles is that they can function with any client, not just OpenVPN Connect.

Determining the TLS control channel security used in a connection profile

OpenVPN Access Server connection profiles are plain-text files that contain directives that tell the OpenVPN process how and where to connect. You can open these profiles in a text editor and refer to the directives below that define the control channel security behavior. In typical .ovpn profiles that contain inline certificates, the keys are stored in-line in text blocks in the connection profile itself. For externally referenced keys, the directives may be present in a slightly different form and refer to an external file that contains that particular key. Below is an example of an externally referenced key, with the in-line versions commonly used with OpenVPN Access Server listed after.

An example of TLS Auth enabled using an externally referenced key:

tls-auth my_ta.key

And as an in-line parameter:

<tls-auth>
(The TLS Auth group key will be here.)
</tls-auth>

TLS Crypt in-line:

<tls-crypt>
(The TLS Crypt group key will be here.)
</tls-crypt>

TLS Crypt V2 in-line:

<tls-crypt-v2>
(The TLS Crypt v2 key will be here.)
</tls-crypt-v2>

Server-locked type profile:

setenv GENERIC_CONFIG

Note: If none of the directives tls-auth, tls-crypt, tls-cryptv2, or setenv GENERIC_CONFIG exist in your connection profile, it doesn’t use additional control channel security. If setenv GENERIC_CONFIG is present it means it is a server-locked profile that uses the web service to obtain a new connection profile every time the connection starts; thus, it will simply use whatever setting your Access Server is configured to use.