| Message ID | 20181204120008.6115-1-andrew.shadura@collabora.co.uk |
|---|---|
| State | RFC |
| Headers | show |
| Series | [RFC] Disable TLSv1.0 by default, but allow enabling it | expand |
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.
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?
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.
On Dec 12, 2018, at 3:48 PM, Andrej Shadura <andrew.shadura@collabora.co.uk> 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.
Alan DeKok wrote: > On Dec 12, 2018, at 3:48 PM, Andrej Shadura <andrew.shadura@collabora.co.uk> 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...
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,
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"
diff --git a/src/crypto/tls_openssl.c b/src/crypto/tls_openssl.c index 0d5ebda..39994f7 100644 --- a/src/crypto/tls_openssl.c +++ b/src/crypto/tls_openssl.c @@ -2498,8 +2498,10 @@ static int tls_set_conn_flags(struct tls_connection *conn, unsigned int flags, #ifdef SSL_OP_NO_TLSv1 if (flags & TLS_CONN_DISABLE_TLSv1_0) SSL_set_options(ssl, SSL_OP_NO_TLSv1); - else + else { + SSL_CTX_set_min_proto_version(ssl, TLS1_VERSION); SSL_clear_options(ssl, SSL_OP_NO_TLSv1); + } #endif /* SSL_OP_NO_TLSv1 */ #ifdef SSL_OP_NO_TLSv1_1 if (flags & TLS_CONN_DISABLE_TLSv1_1) diff --git a/src/eap_peer/eap_tls_common.c b/src/eap_peer/eap_tls_common.c index 0de1315..d4fb454 100644 --- a/src/eap_peer/eap_tls_common.c +++ b/src/eap_peer/eap_tls_common.c @@ -151,6 +151,10 @@ static int eap_tls_params_from_conf(struct eap_sm *sm, struct eap_peer_config *config, int phase2) { os_memset(params, 0, sizeof(*params)); + + /* Debian change: disable TLSv1.0 by default but allow overriding it */ + params->flags |= TLS_CONN_DISABLE_TLSv1_0; + if (sm->workaround && data->eap_type != EAP_TYPE_FAST) { /* * Some deployed authentication servers seem to be unable to
From: Andrej Shadura <andrewsh@debian.org> 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: wpa_supplicant[523]: OpenSSL: pending error: error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error wpa_supplicant[523]: OpenSSL: pending error: error:140C800D:SSL routines:SSL_use_certificate_file:ASN1 lib wpa_supplicant[523]: OpenSSL: pending error: error:140C618E:SSL routines:SSL_use_certificate:ca md too weak wpa_supplicant[523]: TLS: Failed to set TLS connection parameters wpa_supplicant[523]: EAP-TLS: Failed to initialize SSL. wpa_supplicant[523]: wlp4s0: EAP: Failed to initialize EAP method: vendor 0 method 13 (TLS) 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. As I don't possess much knowledge of OpenSSL, and I would like to avoid a potential repeat of the weak security issue Debian had in the past, I'd like people here to have a look and comment on this. Thanks in advance. Andrej References: [1]: https://bugs.debian.org/907518 [2]: https://bugs.debian.org/911297