openVPN with TLS 1.3 ?

[chemlud]

Hy!

I found this here

https://community.openvpn.net/openvpn/ticket/1080

and tried to establish a peer-to-peer with TLS 1.3, but got the same error as reported above (19.1.1). Is TLS 1.3 in sight for 19.7? Or any plans for the nearer future?

[fabian]

I don't know  if it is supported but LibreSSL should be able to support it. OpenSSL may not have the required update yet.

[chemlud]

Thanks for replying, but apparently openVPN needs to be recomplied with the correct crypto library. The error message in openVPN when trying to start with tls-version-min1.3 ("unknown parameter") supports this imho.

As posted some days ago re the error message with openVPN/LibreSSL, openvPN doesn't consider LibreSSL as supported. So apparently catch 22 so far re TLS 1.3...

https://forum.opnsense.org/index.php?topic=11724.msg53260#msg53260

[franco]

TLS 1.3 is OpenSSL 1.1.1 only which we do not have yet. FreeBSD 12.0 uses it.

LibreSSL doesn't support TLS 1.3 at all at the moment.

ETA is difficult to estimate, but easily as much as 6-12 months. We could try to build OpenSSL with 1.1.1 but that would require workarounds for LibreSSL or more support effort explaining the situation.


Cheers,
Franco

[fabian]

I have looked in the bug tracker - TLS 1.3 may be in 2.9 so let's see what will happen there. OpenSSL cannot be upgraded because of some dependencies.

[chemlud]

...sounds exciting. Maybe we get TLS 1.3 with openVPN for Christmas this year! :-D Or Eastern next year... Can hardly wait.

[newsense]

The more time it takes TLS 1.3 to become the de facto standard with TLS 1.{0,1} code being actually dropped from the major browsers and other critical SSL derivatives/libraries -- the more likely E-TLS will start to be 'mandated' in the same vein as it happened in the AUS...

[fabian]

The more time it takes TLS 1.3 to become the de facto standard with TLS 1.{0,1} code being actually dropped from the major browsers and other critical SSL derivatives/libraries

We currently prefer 1.1 and 1.2, 1.0 is disabled in the web interface and nginx due to vulnerabilities.
The nginx plugin will additionally enable 1.3 when it will be available.

When we upgrade to nginx 1.15 at some point, I already have a PR (https://github.com/opnsense/plugins/pull/1112) open for the new 0-RTT handshakes but without TLS 1.3 this feature cannot be added.  Also Frank is waiting for it to enable TLS 1.3 in HAProxy.

-- the more likely E-TLS will start to be 'mandated' in the same vein as it happened in the AUS...

1) you can send the session keys over a separate channel to the middle box if you don't want do put the key on it without affecting the TLS session (like firefox can dump the keys in a logfile which can be opened by wireshark)

2) you can terminate the TLS connection on the middlebox (and maybe re-encrypt the connection on it like it can be configured in nginx / haproxy plugins)

[newsense]

Thanks fabian, it will be interesting to see how it works on systems that specifically disable 0-RTT as it might be one of the best avenues to attack 1.3 connections for a while.

[fabian]

Thanks fabian, it will be interesting to see how it works on systems that specifically disable 0-RTT as it might be one of the best avenues to attack 1.3 connections for a while.

The 0-RTT must be explicitly enabled. The reason is that the web application must be able to handle replay attacks by itself when enabled.

[newsense]

Yeah..."the application must" ? Color me skeptical o_0

Found this recent research though you might not have seen yet, glad to see there's work being done still:

Session Resumption Protocols and Efficient Forward Security for TLS 1.3 0-RTT

https://eprint.iacr.org/2019/228