[RFC] Disable TLSv1.0 by default, but allow enabling it

Message ID 20181204120008.6115-1-andrew.shadura@collabora.co.uk
State New
Headers show
Series
  • [RFC] Disable TLSv1.0 by default, but allow enabling it
Related show

Commit Message

Andrej Shadura Dec. 4, 2018, noon
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

Comments

Jouni Malinen Dec. 4, 2018, 11:09 p.m. | #1
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.
Andrej Shadura Dec. 5, 2018, 8:52 a.m. | #2
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?
Andrej Shadura Dec. 12, 2018, 8:48 p.m. | #3
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.
Alan DeKok Dec. 12, 2018, 10:22 p.m. | #4
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.
Michelle Sullivan Dec. 12, 2018, 10:39 p.m. | #5
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...
Eugen Dedu Dec. 15, 2018, 11:29 a.m. | #6
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,

Patch

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