wpasupplicant 2.6 w/ openssl 1.1.1 triggers TLSv1.3 version intolerance on WPA2-Enterprise networks on Cosmic and Disco

[Pascal Ernster]

Ubuntu 18.10 "Cosmic" and 19.04 "Disco" currently ship with both wpasupplicant 2.6 and openssl/libssl 1.1.1, although upstream only supports OpenSSL 1.1.1 starting with wpasupplicant 2.7.

OpenSSL 1.1.1 introduced support for TLS 1.3, and introduced new APIs to configure the parameters governing TLS connections using TLS >= 1.3. OpenSSL also decided that it would enable TLS 1.3 by default even for software that had only been built for libssl <= 1.1.0 and hence couldn't "know" about the new APIs. This leads to a situation where software that was designed/built for OpenSSL 1.1.0 and TLS 1.2 will also offer TLS 1.3, without any possibility for end users to disable such behavior.

One case where this causes problems is wpasupplicant: wpasupplicant 2.7 officially introduced support for OpenSSL 1.1.1, which mainly consists of disabling TLS 1.3 by default and adding a configuration flag allowing end users to selectively enable it for connections when they see fit. wpasupplicant 2.6, however, as shipped with Ubuntu 18.10 and 19.04, does not offer such a possibility, and hence tries negotiating TLS 1.3 (alongside with older versions all the way down to TLS 1.0).

Sadly, there are RADIUS servers which suffer from TLS version intolerance and will refuse authentication when the client offers TLS 1.3. I know of such a case with a German university's eduroam wifi, but I doubt this is the only case where this causes problems. As a dirty stopgap measure, I've installed the wpasupplicant 2.7 package from Debian Buster (https://packages.debian.org/buster/wpasupplicant), and I've asked the NOC at the affected university to upgrade/reconfigure their RADIUS server to make the version intolerance go away - but still, this is a bug that should be fixed in Ubuntu, preferably by backporting wpasupplicant 2.7.

[Frederic Van Espen (frederic-ve)]

It seems this is also applicable to ubuntu bionic since openssl 1.1.1 landed in bionic-updates. We have bionic clients that cannot connect to the enterprise wifi because they attempt TLS 1.3. Recompiling openssl with the "no-tls1_3" Configure option fixes the problem. See also https://github.com/FreeRADIUS/freeradius-server/issues/2385

[Alan DeKok (aland-freeradius)]

> Sadly, there are RADIUS servers which suffer from TLS version intolerance and will refuse authentication when the client offers TLS 1.3

This statement is completely missing the point. There are *no standards available* for using TLS 1.3 with *any* EAP method. The IETF is working on them, but they are in flux, and have not yet been published.

EAP-TLS and TLS 1.3 is being defined here: https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-05

TLS 1.3 for other EAP methods is being defined here: https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00

> still, this is a bug that should be fixed in Ubuntu, preferably by backporting wpasupplicant 2.7.

The bug is that the shipped versions wpasupplicant and FreeRADIUS allow negotiation of TLS 1..
 Even though the standards that defining TLS 1.3 with EAP didn't exist. This issue only happens in older versions of the software. For FreeRADIUS, it's 3.0.15 and before.

i.e. this was fixed two years ago in 3.0.16.

The solution for the distributions is one of two paths:

1. Upgrade to newer versions of the software that disable support for TLS 1.3 by default
2. Patch the older versions of the software to disable TLS 1.3 by default

[Sebastien Bacher (seb128)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. However, I am closing it because the bug has been fixed in the latest development version of Ubuntu.

This is a significant bug in Ubuntu. If you need a fix for the bug in previous versions of Ubuntu, please perform as much as possible of the SRU Procedure [1] to bring the need to a developer's attention.

[1]: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure