Bug#911389: libssl1.1: loss of WLAN connectivity after upgrading; it's not the library's job to disable TLSv1.0
On 2018-10-19 21:26:13 [+], Thorsten Glaser wrote: > OndÅej Surý dixit: > > >Your initial bug report was inappropriate. > > No, it was not. I think it was. I don't care much about the tone here others might. From the technical point of view you used severity `grave' which is wrong because it does not break it for everyone. It only breaks enterprise setups where the remote site only supports a protocol version less than TLSv1.2. > >It is _absolutely_ job of the security library to set the system-wide > >security policies. > > It is absolutely *not* the job of the SSL *library* to *incompatibly* > change the behaviour of *all* applications depending on it, even those > that don’t have as high security requirements as javascript-HTTP combo, > especially when those *other* programs don’t even expose the knobs to > change the settings but the high security requirement ones *do*. The policy was and is to disable protocols and ciphers in unstable(+testing) if they turn out to be weak or are considered insecure for a reason. This will happen via security (for current (old-)+stable) for things that are considered very insecure. To give you an example: - SSLv2 + SSLv3 was disabled in stable (at the time) via security because it was determined that it is broken and must not be used anymore. While most applications worked fine (because they negotiated the latest possible protocol level) a few of them hardcoded to use SSLv2 or SSLv3. Those did not work until manual care/upload. Unstable lacked the SSLv2/v3 functions/macros and failed to compiled and required manual fixup. Not so stable. Should the radius server in question provide only SSLv3 or less then you would have the very same problem. - RC4 and 3DES was disabled due to `sweet32' if I recall correctly. The severity here was not serious enough to propagate the change to the stable release (at that time). After the Debian stable release, which included this change, we received a few bug reports from people that were not able to connect to their mail server because the mail server supported only the RC4 and 3DES cipher. In both cases it was the library's responsibility to ensure that sane security is provided. > >The Radius server in question needs to be fixed, not the OpenSSL options. > > Did you even understand a single thing I wrote? > > That particular RADIUS server might eventually be fixed, > but one at a customer’s site would have caused massive issues. The customer might need to be made aware that he runs old setup which needs to be touched once every few years. Now, on the productive site after that long letter. I intend to add an entry to the NEWS file about this and close this bug with this change. I think you suggested this somehwere in this bug report. I will ping Kurt to ack my wording because we don't want people blindly make those changes. Also, one thing you could try: Please try to use `iwd' instead of wpasupplicant. It supports various enterprise configs so it should work for you. As of now NetworkManager has an iwd backend and supports "personal" networks but "enterprise" configuration is still on the work. However providing the config file manually and using iwctl should work. iwd is using in-kernel crypto and does not rely on any SSL library. Do you mind testing it? Sebastian
Bug#911389: [Pkg-openssl-devel] Bug#911389: libssl1.1: loss of WLAN connectivity after upgrading; it's not the library's job to disable TLSv1.0
OndÅej Surý dixit: >Your initial bug report was inappropriate. No, it was not. >It is _absolutely_ job of the security library to set the system-wide >security policies. It is absolutely *not* the job of the SSL *library* to *incompatibly* change the behaviour of *all* applications depending on it, even those that don’t have as high security requirements as javascript-HTTP combo, especially when those *other* programs don’t even expose the knobs to change the settings but the high security requirement ones *do*. >The Radius server in question needs to be fixed, not the OpenSSL options. Did you even understand a single thing I wrote? That particular RADIUS server might eventually be fixed, but one at a customer’s site would have caused massive issues. So go back and read my initial mail. Now.
Bug#911389: [Pkg-openssl-devel] Bug#911389: libssl1.1: loss of WLAN connectivity after upgrading; it's not the library's job to disable TLSv1.0
Kurt Roeckx dixit: >To clarify, in the wpa config you can change the security level, >not the minimum TLS version. If you need to enable TLS 1.0, you >need to do it in openssl.cfg Ah. But, again, I don’t have a WPA config… I don’t even know if /etc/network/interfaces exposes that. It’s underdocumented, but it works and requires no other config, thankfully. bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!
Bug#911389: [Pkg-openssl-devel] Bug#911389: libssl1.1: loss of WLAN connectivity after upgrading; it's not the library's job to disable TLSv1.0
Kurt Roeckx dixit: >> files, including in your wpa config file for that specific connection? (actually, I do not have a WPA config file) >I misremembered, it was only the security level that you could >change. Nope: tglase@tglase:~ $ tail -2 /etc/ssl/openssl.cnf MinProtocol = TLSv1.0 CipherString = DEFAULT@SECLEVEL=1 With these two lines, it works. (I didn’t test which one of the two settings was needed, or if both were.) bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Bug#911389: [Pkg-openssl-devel] Bug#911389: libssl1.1: loss of WLAN connectivity after upgrading; it's not the library's job to disable TLSv1.0
Kurt Roeckx dixit: >You know you can just enable TLS 1.0 and 1.1 again in various config >files, including in your wpa config file for that specific connection? > >And that there are already open bugs about this issue? No, I didn’t. But I researched it now (it’s news to me that openssl.cnf is actually read by *all* users of the library now… since when is that?) and, yes, changing these two lines makes WLAN work again. >Anyway, get the radius server fixed instead. That’s not generally possible. In the specific case of the AP at $orkplace, it’s doable, but not my department, and may take a while. But consider the other scenarios I listed: at a customer’s site, or in distress. (I am not going to bo‐ ther our admins, although they’ve received a Cc of at least the ini‐ tial mail of this bugreport… X-Debbugs-Cc is broken and doesn’t send followups any more, AFAICT, so perhaps only that one.) If you please would step down from your cryptographic ideal world high horse, also considering XKCD#538, and join us in the real world now… I also think you did not understand that, in (perhaps also in others) the case of WLAN connectivity is more important than security, as the actual data connections all use SSL or SSH (or VPN) anyway. I’ve been in a lucky place to never have needed export ciphers, but I’d connect to a 40-bit DES-encrypted WLAN if the alternative was no network. Heh even to an unencrypted one. (My WLAN at home is actually unencrypted, but it’s only on when needed.) At the a̲b̲s̲o̲l̲u̲t̲e̲ very least, the libssl1.1 package needs a NEWS.Debian entry detailling these changes and the openssl.cnf way of getting the more compatible behaviour back. That will be read by people while up‐ grading to the new version, and then they’ll know it’s in NEWS.Debian on the local filesystem, and then, on the road, if needed, the change can be done locally without need for further online research. bye, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Bug#911389: [Pkg-openssl-devel] Bug#911389: libssl1.1: loss of WLAN connectivity after upgrading; it's not the library's job to disable TLSv1.0
I will enable SSLv2, SSLv3, 3DES, RC4, export ciphers, and so on again.
Bug#911389: libssl1.1: loss of WLAN connectivity after upgrading; it's not the library's job to disable TLSv1.0
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
