Bug#907518: [RFC] Disable TLSv1.0 by default, but allow enabling it
On Tue, Dec 04, 2018 at 01:00:08PM +0100, Andrej Shadura wrote: > In the Debian bug reports #907518 and #911297 (see below), people complained > that OpenSSL 1.1.1 disables TLSv1.0 and some other insecure settings by > default, but some older networks may still require their support: > wpa_supplicant[523]: OpenSSL: pending error: error:140C618E:SSL > routines:SSL_use_certificate:ca md too weak > Some of those issues can be overrided by adding > openssl_ciphers=DEFAULT@SECLEVEL=1 > to the wpa config, but e.g. Kurt Roeckx complained that the minimum TLS > version is still 1.2: > > ssl_choose_client_version:version too low > > Unlike ciphers, that cannot be overridden in the wpa config, since > tls_disable_tlsv1_0 only allows disabling TLS versions, not enabling > them back if the default version is too high. I intend to apply > the patch below to wpa in Debian, which will enable switching TLSv1.0 > back if necessary by adding tls_disable_tlsv1_0=0 to the config. tls_disable_tlv1_0=0 in wpa_supplicant has actually been defined to enable TLSv1.0. However, the implementation handled that only within wpa_supplicant itself and not in a manner that would be able to override this systemwide default in OpenSSL parameters. It looks like the safest approach is to allow this explicit enabling to be used in configuration to do that override so that distributions are free to do whatever systemwide enforcement they want to expose to their users to try to enforce security while the users have an option of overriding that if there is no way of fixing the issue at the other end of the exchange. The following hostap.git commit does this: https://w1.fi/cgit/hostap/commit/?id=cc9c4feccc5588137f66c40a4a6729476556853e And as an example, the following network profile parameters would undo the Debian systemwide restrictions: phase1="tls_disable_tlsv1_0=0 tls_disable_tlsv1_1=0" openssl_ciphers="DEFAULT@SECLEVEL=1" -- Jouni MalinenPGP id EFC895FA
Bug#907518: [RFC] Disable TLSv1.0 by default, but allow enabling it
On 05/12/2018 09:52, Andrej Shadura wrote: Hardcode a minimal version just for wpa-supplicant to TLSv1.0? What about ciphers? Anything else? Hi, In order to make it work with eduroam I have to change in ciphers too like this: MinProtocol = TLSv1.2 -> 1 CipherString = DEFAULT@SECLEVEL=2 -> 1 Best regards, -- Eugen
Bug#907518: [RFC] Disable TLSv1.0 by default, but allow enabling it
Alan DeKok wrote: On Dec 12, 2018, at 3:48 PM, Andrej Shadura wrote: On 05/12/2018 09:52, Andrej Shadura wrote: On 05/12/2018 00:09, Jouni Malinen wrote: Right, so what would you recommend for me to do in the meanwhile? Hardcode a minimal version just for wpa-supplicant to TLSv1.0? What about ciphers? Anything else? I would really appreciate some opinion from Jouni or other people on this list. My $0.02 is to have an "allow TLSv1.0" configuration option, but have it disabled by default. It's what we do in FreeRADIUS. It's arguably bad in minor ways to allow TLSv1.0. But preventing people from getting online is likely worse. I'll +1 this. It shits me no end that java and browsers have dropped SSLv2/3+TLSv1.0 in the name of security with no option to turn it on. I have some embedded hardware that is only accessible over VPN on a dedicated network that I have to run an old OS with old Java and old browsers to access. Sure it's a major security issue, but hell why can we not have options to force it on (even if the code is built to turn it back off after a set amount of time) for those that actually know what they are doing...? I'll go get coffee now... -- Michelle Sullivan http://www.mhix.org/
Bug#907518: [RFC] Disable TLSv1.0 by default, but allow enabling it
On Dec 12, 2018, at 3:48 PM, Andrej Shadura wrote: > > On 05/12/2018 09:52, Andrej Shadura wrote: >> On 05/12/2018 00:09, Jouni Malinen wrote: >> Right, so what would you recommend for me to do in the meanwhile? >> Hardcode a minimal version just for wpa-supplicant to TLSv1.0? What >> about ciphers? Anything else? > > I would really appreciate some opinion from Jouni or other people on > this list. My $0.02 is to have an "allow TLSv1.0" configuration option, but have it disabled by default. It's what we do in FreeRADIUS. It's arguably bad in minor ways to allow TLSv1.0. But preventing people from getting online is likely worse. Alan DeKok.
Bug#907518: [RFC] Disable TLSv1.0 by default, but allow enabling it
On 05/12/2018 09:52, Andrej Shadura wrote: > On 05/12/2018 00:09, Jouni Malinen wrote: > Right, so what would you recommend for me to do in the meanwhile? > Hardcode a minimal version just for wpa-supplicant to TLSv1.0? What > about ciphers? Anything else? I would really appreciate some opinion from Jouni or other people on this list. -- Cheers, Andrej
Bug#907518: [RFC] Disable TLSv1.0 by default, but allow enabling it
On 05/12/2018 00:09, Jouni Malinen wrote: > On Tue, Dec 04, 2018 at 01:00:08PM +0100, Andrej Shadura wrote: >> This patch is not intended to be merged into the upstream code, but I >> would still like to receive comments from people involved in development. >> >> In the Debian bug reports #907518 and #911297 (see below), people complained >> that OpenSSL 1.1.1 disables TLSv1.0 and some other insecure settings by >> default, but some older networks may still require their support: > > This is going to break lots of WLAN connections in practice.. > Unfortunately, enterprise authentication servers are something that do > not really get updated easily and when something is updated, things > tends to break horribly.. For that to change, I guess there would need > to be a change in significant number of client devices (or something > very widely used device) to start rejecting the connections with a clear > message indicating that the issue is in the server and not something > that the client device can fix on its own. > > In practice, though, wpa_supplicant may have to start overriding this > type of system-wide enforcement to prevent cases where the user has no > way of impact the authentication server operator, so something may need > to be merged into hostap.git to get more reasonable behavior than "not > working until server is updated (which may never happen)". > > It should also be noted that use of TLS in EAP is quite different from > other cases like HTTPS, i.e., EAP uses very limited amount of > application data (or even none of it in case of EAP-TLS), so the impact > of various TLS issues with past versions may be different as well. There > are some clear cases like not allowing too short DH keys to be used > which can certainly be justified from security view point, but fully > disabling TLS v1.0 by default may not be something that EAP world is > ready for yet.. Some ciphers might also be possible to disable without > losing too much interoperability with currently deployed authentication > servers. Right, so what would you recommend for me to do in the meanwhile? Hardcode a minimal version just for wpa-supplicant to TLSv1.0? What about ciphers? Anything else? -- Cheers, Andrej
Bug#907518: [RFC] Disable TLSv1.0 by default, but allow enabling it
On Tue, Dec 04, 2018 at 01:00:08PM +0100, Andrej Shadura wrote: > This patch is not intended to be merged into the upstream code, but I > would still like to receive comments from people involved in development. > > In the Debian bug reports #907518 and #911297 (see below), people complained > that OpenSSL 1.1.1 disables TLSv1.0 and some other insecure settings by > default, but some older networks may still require their support: This is going to break lots of WLAN connections in practice.. Unfortunately, enterprise authentication servers are something that do not really get updated easily and when something is updated, things tends to break horribly.. For that to change, I guess there would need to be a change in significant number of client devices (or something very widely used device) to start rejecting the connections with a clear message indicating that the issue is in the server and not something that the client device can fix on its own. In practice, though, wpa_supplicant may have to start overriding this type of system-wide enforcement to prevent cases where the user has no way of impact the authentication server operator, so something may need to be merged into hostap.git to get more reasonable behavior than "not working until server is updated (which may never happen)". It should also be noted that use of TLS in EAP is quite different from other cases like HTTPS, i.e., EAP uses very limited amount of application data (or even none of it in case of EAP-TLS), so the impact of various TLS issues with past versions may be different as well. There are some clear cases like not allowing too short DH keys to be used which can certainly be justified from security view point, but fully disabling TLS v1.0 by default may not be something that EAP world is ready for yet.. Some ciphers might also be possible to disable without losing too much interoperability with currently deployed authentication servers. -- Jouni MalinenPGP id EFC895FA
