Opened 2 years ago

Last modified 2 years ago

#1371 new Feature Wish

Allow TLS-Crypt-V2 keys to be password protected

Reported by: tct Owned by:
Priority: minor Milestone:
Component: Generic / unclassified Version: OpenVPN 2.5.0 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: tls-crypt-v2
Cc: Steffan Karger, Gert Döring, plaisthos, tct, David Sommerseth, Selva, Nair

Description (last modified by tct)

This is a standard security feature of all keys that I can think of, except this one.

Obviously, I can do this outside of openvpn using openssl but then the key has to be decrypted before openvpn can load it. So I am asking for openvpn to manage this task.

Openvpn would have to prompt for the password and users would also want to store passwords in plain text (because they always do..)

This may be a lot of effort for a tiny feature so maybe just a pipe dream.

Change History (10)

comment:1 Changed 2 years ago by tct

Description: modified (diff)

comment:2 Changed 2 years ago by tct

Cc: David Sommerseth added

comment:3 Changed 2 years ago by tct

Description: modified (diff)
Summary: Allow TLS-Crypt-V2 Server key to be password protectedAllow TLS-Crypt-V2 keys to be password protected

comment:4 Changed 2 years ago by David Sommerseth

What is is the threat model you think this will protect you against? I struggle to see the real benefit here. Yes, it is an encryption key, but --tls-auth as well as --tls-crypt uses also a (shared) encryption key to sign data and verify data. --tls-crypt-v2 isn't that much different except that it adds a "signature" to each user keys, so each user can have their own keys.

The purpose of --tls-crypt and --tls-crypt-v2 is also to make it harder to see the TLS handshake, which is going unencrypted by default, at least up to TLSv1.2. TLS handshake encryption is primarily discussed to "hide" the certificate exchange of public keys, where some traceable information can be extracted. So the --tls-crypt{,-v2} features can be more considered like a scrambling of the Control Channel (where the TLS handshake is happening). It was just chosen to use an encryption algorithm over other scrambling methods as it is harder to break encryption than various scrambling algorithms.

The security of the OpenVPN protocol itself and in particular the data channel isn't weakened if the --tls-crypt{,-v2} keys gets compromised. The only things such a key can be used for is to descramble the TLS handshake to extract the clear-text certificate information or to mount various forms of DoS attacks where OpenVPN would actually parse the payload instead of silently dropping it.

So I'm wondering what kind of threat model you imagine where password protecting the --tls-crypt-v2 keys would be beneficial.

Also worth noting, the 2.4.0 security audit did not mention anything related to the security of the --tls-crypt key itself. There were concerns about some IV collision possibilities, where the risks was considered acceptable (key rotation should happen at least every 8th year if you have 1000 connecting users doing negotiating over the control channel every minute - or tls-crypt key rotation every year if you have 8000 connecting clients). This issue is resolved by --tls-crypt-v2, where this IV collision possibility is reduced to a bare minimum (248 control channel packets per key, iiuc). But password encrypting the tls-crypt keys was not somthing I recall being mentioned in both performed security audits.

Last edited 2 years ago by David Sommerseth (previous) (diff)

comment:5 in reply to:  4 Changed 2 years ago by tct

Replying to David Sommerseth:

What is is the threat model you think this will protect you against?

If an attacker has access to a live Server TLS-Crypt-V2 key then the attacker can decode all TLS-Crypt-V2 client keys, created by that server key, with a rogue server, regardless of all X509 protection.

The attacker can also create unlimited, new and valid TLS-Crypt-V2 client keys to the server under attack.

By protecting the Server key with a password this vector is minimized.

If the server key can be encrypted then the client key could be as well.

Last edited 2 years ago by tct (previous) (diff)

comment:6 Changed 2 years ago by tct

I understand that this may not be regarded as a High Risk vector due to the other security measures in place but the server TLS-Crypt-V2 key is of particular importance because it can be used without any form of challenge by an attacker, if it is compromised stolen.

Thus: "New Feature Wish" not "Bug"

Last edited 2 years ago by tct (previous) (diff)

comment:7 Changed 2 years ago by tct

This may help lend some weight to my argument:

Openvpn uses two pre-shared keys: --tls-auth and --tls-crypt

These keys are shared amongst all nodes which access this VPN.

These keys cannot be compromised because they are public data.

However, --tls-crypt-v2 keys are not pre-shared keys.
(Technically, I may be wrong about the term 'pre-shared key' but the point about --tls-crypt-v2 and specifically the server key, is that all client keys can be decrypted by the server key. This is somewhat similar to a CA key, in the respect of its power over PKI certificates)

--tls-crypt-v2 keys are a unique OpenVPN feature.

These keys can be compromised because they are private data.

I am discussing improving their usability.

Last edited 2 years ago by tct (previous) (diff)

comment:8 Changed 2 years ago by tct

As people learn about --tls-crypt-v2 keys then $somebody, who knows more than I do, will probably come to the same conclusion.


Future Security "protocols" may simply mandate that protecting the TLS-Crypt-V2 Server key be at least optional.

I already wrote a script to do it!

Last edited 2 years ago by tct (previous) (diff)

comment:9 Changed 2 years ago by tct

Cc: Selva Nair added

CC: Selva, Nair .. was actually added.

Last edited 2 years ago by tct (previous) (diff)

comment:10 Changed 2 years ago by tct

Final word, for the sake of argument:

I accidentally copy/paste my TLS-Crypt-V2 Server key into a client profile.

And this 'introduction':

Last edited 2 years ago by tct (previous) (diff)
Note: See TracTickets for help on using tickets.