Public bug reported:

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.

** Affects: wpa (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: eap eduroam libssl openssl peap tls1.3 tlsv1.3 ttls wpa wpa-enterprise 
wpasupplicant

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to wpa in Ubuntu.
https://bugs.launchpad.net/bugs/1823053

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

Status in wpa package in Ubuntu:
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1823053/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to