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
