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

[Sebastian Andrzej Siewior]

On 2018-10-19 21:26:13 [+0000], 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