Opened 3 years ago
Last modified 3 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 )
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 3 years ago by
Description: | modified (diff) |
---|
comment:2 Changed 3 years ago by
Cc: | David Sommerseth added |
---|
comment:3 Changed 3 years ago by
Description: | modified (diff) |
---|---|
Summary: | Allow TLS-Crypt-V2 Server key to be password protected → Allow TLS-Crypt-V2 keys to be password protected |
comment:5 Changed 3 years ago by
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.
comment:6 Changed 3 years ago by
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"
comment:7 Changed 3 years ago by
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.
comment:8 Changed 3 years ago by
As people learn about --tls-crypt-v2
keys then $somebody, who knows more than I do, will probably come to the same conclusion.
<--Things-change-->
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!
comment:10 Changed 3 years ago by
Final word, for the sake of argument:
I accidentally copy/paste my TLS-Crypt-V2 Server key into a client profile.
And this 'introduction':
https://github.com/OpenVPN/openvpn/blob/master/doc/tls-crypt-v2.txt
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.