OpenVPN's new tls-crypt option

Question

I've been reading about the new tls-crypt options for OpenVPN 2.4, but I'm not sure if I correctly understand it.

I've read the manual pages and the security overview for OpenVPN (which seems to be missing the tls-crypt option) and that's how I understood it.

In TLS mode with the use of tls-crypt, the connection between the two peers is established, encrypted and authenticated with the use of the key file defined with the tls-crypt option. Then the certificates are used to authenticate the peers, if successful the HMAC and encrypt/decrypt keys are generated and exchanged over the established TLS connection. All of this is still happening over the connection encrypted/authenticated with the tls-crypt key file.

And the additional privacy and protection against identification of the OpenVPN tunnel is achieved because the control channel's TLS connection is encrypted by the static tls-crypt key.

Is my understanding about the tls-crypt option correct?

Answer 1

The tl;dr reply is: Yes, your understanding is correct.

In TLS mode, OpenVPN establishes a TLS session to perform a key exchange over that TLS session to obtain the keys used to encrypt/authenticate the tunnel payload data. This is a normal TLS session, just as if you'd open a HTTPS website in your browser, except that it won't just perform server authentication but also client authentication and thus the client will require a cert with private key, too.

The TLS session exchange on itself should be secure, after all it's all that you have when you visit an online banking site for example but that's only the theory. In practice every protocol has weaknesses and even if the protocol would not have any, the protocol implementation can have weaknesses, too. To make it even harder for an attacker to make use of such weaknesses, you can use tls-crypt, which will encrypt and authenticate the TLS packets using keys from a static key file. Now an attacker would also need to get his hands on a copy of that key file, otherwise even knowing an usable attack and having the possibility to pull it off (e.g. being able to monitor traffic or perform a man-in-the-middle attach) won't help him.

With tls-crypt, all data running on the "TLS channel" is encrypted and authenticated with the same algorithms as the tunnel payload data and with the keys from the static key file. For the TLS payload data (user authentication, key exchange, config push, etc.) this means, this data is encrypted and authenticated twice. Once by tls-crypt and once by the TLS session itself, as a TLS session itself is used to encrypt and authenticate data and, of course, even if tls-crypt is not used, the user authentication, the key exchange, and the configuration push must be encrypted and authenticated; otherwise how would the whole protocol be secure if that wasn't the case?

Despite adding extra security for the paranoid VPN admin (albeit, considering the horrible SSL/TLS bugs found the last couple of years, these people appear much less paranoid as they used to), it also has another positive effect: It prevents certain kind of denial of service attacks. Even if an attacker cannot break into your VPN, he may still try to open thousands of TLS sessions at the same time. Not being able to provide a valid certificate, all of these sessions will fail in the end but until that is the case (will take 60 seconds by default), a TLS session object can use a significant amount of memory resources for a small embedded device and opening thousands of these can quickly bring such a device down. With tls-crypt, already the first packet sent will not authenticate/decrypt correctly and thus is immediately discarded. There is no need to even create a TLS session object in that case.