[Pkg-openssl-devel] Bug#911389: libssl1.1: loss of WLAN connectivity after upgrading; it's not the library's job to disable TLSv1.0

Fri Oct 19 14:30:36 BST 2018

Package: libssl1.1
Version: 1.1.1-1
Severity: grave
Justification: renders package unusable

I have the following stanza in my /etc/network/interfaces:

iface tarent-lan inet dhcp
	wireless-mode Managed
	wireless-essid tarent-lan
	wpa-ssid tarent-lan
	wpa-key-mgmt WPA-EAP
	wpa-identity tglase
	wpa-password XXX
#	wpa-eap PEAP TTLS
#	wpa-phase2 auth=MSCHAPV2 autheap=MSCHAPV2

Either without or with the last two lines, I can no longer use
“sudo ifup wlan0=tarent-lan” to connect to our WLAN:

[  106.016581] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/wlan0/00:1f:3b:0d:cb:b1
Sending on   LPF/wlan0/00:1f:3b:0d:cb:b1
Sending on   Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
[  110.435975] wlan0: authenticate with 34:fc:b9:60:71:52
[  110.447304] wlan0: send auth to 34:fc:b9:60:71:52 (try 1/3)
[  110.452025] wlan0: authenticated
[  110.460168] wlan0: associate with 34:fc:b9:60:71:52 (try 1/3)
[  110.465089] wlan0: RX AssocResp from 34:fc:b9:60:71:52 (capab=0x1011 status=0 aid=8)
[  110.498183] wlan0: associated
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9
[  115.610155] wlan0: deauthenticating from 34:fc:b9:60:71:52 by local choice (Reason: 3=DEAUTH_LEAVING)
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 12
[  128.126656] wlan0: authenticate with 34:fc:b9:60:71:42
[  128.135979] wlan0: send auth to 34:fc:b9:60:71:42 (try 1/3)
[  128.252372] wlan0: send auth to 34:fc:b9:60:71:42 (try 2/3)
[  128.360349] wlan0: send auth to 34:fc:b9:60:71:42 (try 3/3)
[  128.484364] wlan0: authentication with 34:fc:b9:60:71:42 timed out
[  128.679388] wlan0: authenticate with 34:fc:b9:60:71:22
[  128.679459] wlan0: send auth to 34:fc:b9:60:71:22 (try 1/3)
[  128.689598] wlan0: authenticated
[  128.700133] wlan0: associate with 34:fc:b9:60:71:22 (try 1/3)
[  128.708624] wlan0: RX AssocResp from 34:fc:b9:60:71:22 (capab=0x1431 status=0 aid=3)
[  128.737852] wlan0: associated
[  132.591116] wlan0: deauthenticated from 34:fc:b9:60:71:22 (Reason: 3=DEAUTH_LEAVING)
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 19

A colleague forwarded me the relevant RADIUS server logs:

Wed Oct 17 14:59:48 2018 : Error: rlm_eap: SSL error error:1408F10B:SSL
routines:SSL3_GET_RECORD:wrong version number

I’ve downgraded libssl1.1 (and openssl) to 1.1.0g-2 (temporarily breaking
Python 3.6 and 3.7 in the progress) and, voilà, I can connect.

┌─────────────────────────────────────────────────────────┐
│ IT IS *NOT* THE JOB OF THE OPENSSL *LIBRARY* TO DISABLE │
│ OLD PROTOCOL VERSIONS AS IT’S USED FOR *MORE* THAN JUST │
│ WEBSERVERS AND WEBBROWSERS!                             │
└─────────────────────────────────────────────────────────┘

Perhaps there may be reasons against using a number of older standards,
but most of them are only exploitable if the client is a webbrowser
capable of running ECMAscript. This is comparable with RC4 being bad
in WEP but not in aRC4random because of how it is used.

OpenSSL is not just used in webservers (and, to a lesser extent, HTTPS
clients), but also for things like SMTP (I *do* have much more trouble
with STARTTLS connections than a year or two ago), IMAP (had to manually
hack something there, too), and worst of all, WPA.

┌─────────────────────────────────────────────────────────┐
│ Especially in the WPA case, CONNECTIVITY IS *MUCH* MORE │
│ IMPORTANT THAN SECURITY because I run SSL, SSH or VPN   │
│ over wireless connections already *anyway*!             │
└─────────────────────────────────────────────────────────┘

Loss of being able to connect to arbitrary WLANs “out in the field”,
especially given no other solution to connect to them (even to down‐
load the older OpenSSL I had to connect to a different network first)
is a CATASTROPHIC LOSS OF FUNCTIONALITY. Protocol ossification is a
fact that we *have* to live with and accept.

What if I had been at a customer’s site? That would have utterly
blamed OSS and GNU/Linux. That could have caused my employer more
than just extra money.

What if I had needed to use the WLAN to send an emergency call?

tl;dr: Because OpenSSL is also used in non-Web scenarios, it absolutely
MUST NOT disable the older algorithms. Rather, end-user applications
(servers, clients, …) using OpenSSL need to provide knobs to configure
TLS versions, ciphersuites, etc. if they so wish, and the default MUST
be compatible.

Things like Apache etc. already contain the necessary knobs, have so
for decades, so it’s up to those packages to contain suitable settings.

Things like wpa_supplicant-run-via-ifupdown do not. (It was hard enough
getting it to work *at all* in the first place.)

This is *vital* to being able to continue using Debian in a professional
workplace environment.

Thank you for listening.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)