tls-crypt-v2

[Dadadadadaa 0]

OpenVPN 2.5 introduced tls-crypt-v2, which has client specific tls-crypt keys instead of a pre-shared group key that is in tls-crypt-v1. Compromise of only 1 client or server would leak the key and thus make the tls-crypt layer useless against anyone obtaining the key. For public VPN providers bypassing the tls-crypt layer is even easier, one could just subscribe to the VPN service to get the key, but with the unique keys in v2, that problem is solved.
https://github.com/OpenVPN/openvpn/blob/master/doc/tls-crypt-v2.txt

Will AirVPN implement tls-crypt-v2?

[Staff 9972]

@Dadadadadaa

Hello!

No doubts, it will be even more useful against flood. Anyway nothing changes for the customers under a security point of view, obviously, as the key is needed as TLS pre-auth (so OpenVPN can shut down immediately, before checking client certificate, and mitigate flood) and for TLS mode (so PFS etc. become possible), nothing else.

Kind regards
 

[Dadadadadaa 0]

12 minutes ago, Staff said:

@Dadadadadaa

Hello!

No doubts, it will be even more useful against flood. Anyway nothing changes for the customers under a security point of view, obviously, as the key is needed as TLS pre-auth (so OpenVPN can shut down immediately, before checking client certificate, and mitigate flood) and for TLS mode (so PFS etc. become possible), nothing else.

Kind regards
 

Thanks for your quick reply! I was under the impression that tls-crypt also helps against VPN blocking/censorship because it hides the OpenVPN protocol signature during the TLS handshake. Edited ... by Dadadadadaa

[Staff 9972]

@Dadadadadaa

Yes, that's correct.

Kind regards
 

[Dadadadadaa 0]

On 1/11/2021 at 10:14 AM, Staff said:

@Dadadadadaa

Yes, that's correct.

Kind regards
 

Ah thanks!

[CinnamonStick 0]

On 1/10/2021 at 3:05 PM, Staff said:

@Dadadadadaa

 Anyway nothing changes for the customers under a security point of view,

Actually tls-crypt-v2 does add security for a public VPN provider. tls-crypt and tls-auth can add security, depending on the use case:
"TLS Auth and TLS Crypt provide protection against TLS-level attacks with post-quantum resistance if the pre-shared keys are kept secret."
https://openvpn.net/vpn-server-resources/tls-control-channel-security-in-openvpn-access-server/
"The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS. It can protect against:
-Buffer overflow vulnerabilities in the SSL/TLS implementation."
https://openvpn.net/community-resources/hardening-openvpn-security/

As a real-world example, it also would have protected against the Heartbleed vulnerability. But as the first link states, IF the pre-shared keys are kept secret. And since anyone can subscribe to AirVPN to get the key, this is not the case. However, with tls-crypt-v2 bringing unique keys, it thus brings this protection for public VPN providers as well.

So I hope AirVPN will introduce tls-crypt-v2 soon, at least for some specific server first.

[Staff 9972]

@CinnamonStick

Again, the added protection against attacks is only on the server side, as you have just confirmed. Strangely tls-crypt v2 seems available on OpenVPN Access Server only, not on OpenVPN, or at least it is missing in the OpenVPN manual, we can find it only on OpenVPN AS manual.

Kind regards
 

[CinnamonStick 0]

9 hours ago, Staff said:

@CinnamonStick

Again, the added protection against attacks is only on the server side, as you have just confirmed. Strangely tls-crypt v2 seems available on OpenVPN Access Server only, not on OpenVPN, or at least it is missing in the OpenVPN manual, we can find it only on OpenVPN AS manual.

Kind regards
 

Maybe vulnerabilities can only be exploited on the server side, but for Heartbleed for example it was possible to extract private keys from the server. So even if the users machine is never attacked, if a vulnerability allows decryption of VPN traffic, the user is screwed anyway.

It is strange that that tls-crypt v2 is not mentioned in the OpenVPN manual, release notes for 2.5.0 mention tls-crypt v2 support:
https://openvpn.net/community-downloads/

[Staff 9972]

16 hours ago, CinnamonStick said:

Maybe vulnerabilities can only be exploited on the server side, but for Heartbleed for example it was possible to extract private keys from the server. So even if the users machine is never attacked, if a vulnerability allows decryption of VPN traffic, the user is screwed anyway.
 

Hello

Heartbleed exploit was made possible by the OpenSSL library on web servers and has been resolved since April 2014, more than 8 years ago.

Anyway, with OpenVPN working in TLS mode (like it always did in our infrastructure), the private key was never at risk (not to mention decrypting the client traffic, totally impossible with Heartbleed), not even with the vulnerable OpenSSL version: TLS Auth was sufficient.

Heartbleed was particularly dangerous for web servers, not for OpenVPN working in TLS Mode (with TLS Auth and PFS). Using tls-crypt has nothing to do with Heartbleed and vulnerabilities of the sort.

If a vulnerability is discovered on the SSL/TLS library, its exploit may or may not affect OpenVPN too, but if it does, tls-crypt and tls-crypt v2 probably will make no difference (it depends mainly on the parsers).
 

Quote

"The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS. It can protect against:
-Buffer overflow vulnerabilities in the SSL/TLS implementation."

This is already implemented in tls-auth. No need of tls-crypt or tls-crypt v2 for it. Strangely you quote features already implemented in tls-auth as advantages of tls-crypt over tls-auth, causing confusion. A clarification is due.

tls-crypt and tls-crypt v2 allow early connection abort, while tls-auth needs to expose TLS.X509 parser before dropping the connection, enlarging therefore the attack surface. Moreover, by not sending anything back and dropping all when metadata verification fails, tls-crypt makes the server slightly more robust against floods and DoS attacks in general.

This is of course great for the servers and tls-crypt is already implemented (on AirVPN servers entry-IP addresses 3 and 4), and we might also consider tls-crypt v2 in the future and dropping tls-auth (which we maintain on entry-IP 1 and 2 for backward compatibility), but you must not assume that it is useful more than tls-auth to defeat a class of attacks against the clients or aimed at decrypting the client traffic.

Another advantage of tls-crypt over tls-auth is that the Data Channel gets completely encrypted since the handshake, thus tls-crypt (and its version 2 of course) can more easily bypass ISP blocks triggered by detection of OpenVPN handshake "fingerprint".

Kind regards
 

[CinnamonStick 0]

7 hours ago, Staff said:

Hello

Heartbleed exploit was made possible by the OpenSSL library on web servers and has been resolved since April 2014, more than 8 years ago.

 

Hello,

I'm aware that Heartbleed has since been long fixed, but I used it as a real world example.
 

Quote

This is already implemented in tls-auth. No need of tls-crypt or tls-crypt v2 for it. Strangely you quote features already implemented in tls-auth as advantages of tls-crypt over tls-auth, causing confusion. A clarification is due.

I am aware of the fact that it is already implemented in tls-auth. However, to my knowledge the features of tls-auth/crypt only work if the pre-shared key of tls-auth/crypt is secret. Since tls-auth and tls-crypt v1 use a shared group key, it is not secret in the case of a public vpn provider, where an attacker can just subscribe and obtain the key. That is why I'm quoting it as advantage of tls-crypt-v2 over tls-auth/crypt in the case of a public vpn provider, as v2 finally introduced client specific keys instead of a shared group key. Since there is no tls-auth with client specific keys, I advocate for tls-crypt-v2 because to my knowledge it includes tls-auth functionality, and adds encryption of the control channel on top of that. Which it is why I believe it may also be useful in protecting against similar vulnerabilities in the SSL/TLS implementation.
 

Quote

Anyway, with OpenVPN working in TLS mode (like it always did in our infrastructure), the private key was never at risk (not to mention decrypting the client traffic, totally impossible with Heartbleed), not even with the vulnerable OpenSSL version: TLS Auth was sufficient.

Heartbleed was particularly dangerous for web servers, not for OpenVPN working in TLS Mode (with TLS Auth and PFS). Using tls-crypt has nothing to do with Heartbleed and vulnerabilities of the sort.

Heartbleed could actually extract private keys from OpenVPN in TLS mode:
https://news.ycombinator.com/item?id=7598616
tls-auth would indeed protect against this, but again, only if the pre-shared key is secret, which is not the case for a public VPN provider.

[Staff 9972]

@CinnamonStick
 

Quote

I am aware of the fact that it is already implemented in tls-auth. However, to my knowledge the features of tls-auth/crypt only work if the pre-shared key of tls-auth/crypt is secret. Since tls-auth and tls-crypt v1 use a shared group key, it is not secret in the case of a public vpn provider, where an attacker can just subscribe and obtain the key.

Hello!

The attacker can do exactly the same with tls-crypt v2: subscribe and get the TLS key to pass the first barrier and then perform the attack .

tls-crypt v2 is stronger against flood because the attacker, at least, must create more than one attacking account in order to keep flooding after a key gets blocked, while with tls-crypt it can keep flooding with just one key which remains valid (because we would block all the customers if we changed it). That's surely a strong reason to plan tls-crypt v2 implementation. To be effective, however, tls-auth must be dropped, otherwise the flooder can always point to the entry-IP addresses where OpenVPN in tls-auth responds.

Nothing changes on the client side security between tls-crypt and tls-crypt v2, while an important change over tls-auth is due to the fact, as we already wrote, that the parser is not exposed and the communication can be dropped sooner. This makes tls-crypt more robust than tls-auth against flood attacks and reduces the attack surface.

However it's not yet time for us to drop tls-auth and break backward compatibility, because tls-auth it is still required by customers who run OpenVPN versions which don't support tls-crypt.
 

Quote

tls-crypt-v2 because to my knowledge it includes tls-auth functionality, and adds encryption of the control channel on top of that.

This has been always done by tls-crypt which we implemented several years ago. It's not something new of tls-crypt v2.

 

Quote

Heartbleed could actually extract private keys from OpenVPN in TLS mode:
https://news.ycombinator.com/item?id=7598616

A working proof of concept has never been published so we are dubious, but that's not important, because if the exploit had been able to work even against tls-crypt (let's assume for argument's sake that tls-crypt had been available at the time), then it would have worked even against tls-crypt 2. Strömberg says it very clearly: they did not attack servers with tls-auth, because it was just a useless over-complication, as anyone could get the tls-auth key in their (or our) service (and today anyone can get a specific tls-crypt v2 key, nohting changes).

 

Quote

tls-auth would indeed protect against this, but again, only if the pre-shared key is secret, which is not the case for a public VPN provider. 

The server key is always secret and in particular the DH key is unique to each server.

So tls-crypt 2 makes no difference again: if an attack successfully gets the server secrets to impersonate that one server in an attempt to have the target victim connect to it via some additional traffic hijack, it can work either with tls-crypt or tls-crypt v2, because the difference for this purpose is only that the tls-crypt key is common to all clients, while the tls-crypt v2 key may be unique to each client and/or server group, so it can be obtained anyway immediately. This is well explained in GitHub:
https://github.com/OpenVPN/openvpn/blob/master/doc/tls-crypt-v2.txt

Don't charge tls-crypt v2 with super-features which it doesn't have and has not been designed to have.

Kind regards
 

[CinnamonStick 0]

9 hours ago, Staff said:

@CinnamonStick
 
Hello!

The attacker can do exactly the same with tls-crypt v2: subscribe and get the TLS key to pass the first barrier and then perform the attack .

tls-crypt v2 is stronger against flood because the attacker, at least, must create more than one attacking account in order to keep flooding after a key gets blocked, while with tls-crypt it can keep flooding with just one key which remains valid (because we would block all the customers if we changed it). That's surely a strong reason to plan tls-crypt v2 implementation. To be effective, however, tls-auth must be dropped, otherwise the flooder can always point to the entry-IP addresses where OpenVPN in tls-auth responds.

Nothing changes on the client side security between tls-crypt and tls-crypt v2, while an important change over tls-auth is due to the fact, as we already wrote, that the parser is not exposed and the communication can be dropped sooner. This makes tls-crypt more robust than tls-auth against flood attacks and reduces the attack surface.

However it's not yet time for us to drop tls-auth and break backward compatibility, because tls-auth it is still required by customers who run OpenVPN versions which don't support tls-crypt.
 
This has been always done by tls-crypt which we implemented several years ago. It's not something new of tls-crypt v2.

 
A working proof of concept has never been published so we are dubious, but that's not important, because if the exploit had been able to work even against tls-crypt (let's assume for argument's sake that tls-crypt had been available at the time), then it would have worked even against tls-crypt 2. Strömberg says it very clearly: they did not attack servers with tls-auth, because it was just a useless over-complication, as anyone could get the tls-auth key in their (or our) service (and today anyone can get a specific tls-crypt v2 key, nohting changes).

 
The server key is always secret and in particular the DH key is unique to each server.

So tls-crypt 2 makes no difference again: if an attack successfully gets the server secrets to impersonate that one server in an attempt to have the target victim connect to it via some additional traffic hijack, it can work either with tls-crypt or tls-crypt v2, because the difference for this purpose is only that the tls-crypt key is common to all clients, while the tls-crypt v2 key may be unique to each client and/or server group, so it can be obtained anyway immediately. This is well explained in GitHub:
https://github.com/OpenVPN/openvpn/blob/master/doc/tls-crypt-v2.txt

Don't charge tls-crypt v2 with super-features which it doesn't have and has not been designed to have.

Kind regards
 

Ah yes, I somehow missed that if an attacker can extract the private key he could also extract the tls-crypt-v2 key of other users.
Anyway, thanks for taking the time explaining all this!

[cfinley 3]

Should we now be setting “TLS control channel security” to Encrypt Channel V2 rather than Encrypt Channel?

[OpenSourcerer 1435]

On 10/12/2022 at 3:19 AM, cfinley said:

Should we now be setting “TLS control channel security” to Encrypt Channel V2 rather than Encrypt Channel?

Where did you read that tls-crypt-v2 has been implemented? It wasn't.