[gnutls-devel] GnuTLS | Compiled-in, yet unsupported by default, TLS versions (!1157)

[Development of GNU's TLS library]

Nikos Mavrogiannopoulos commented:


> Yes the proposed implementation in this PR currently buggy, I will fix it up. The intention was for disabled-version to trump supported-version.

> "expectations in terms of minimum security" is never a one-way street. What may be universally viewed as secure/insecure, may not be viewed as such by someone else. For example, using "disabled-versions = tls1.3" is usually done out of distrust or lack of current compliance, rather than because tls1.3 is broken. Or disabling/enabling ECC/GOST/etc.

True. This is also the reason I think changing the approach is a slippery slope. The approach you are suggesting is not limited to protocol versions only, it will need to extend to hash algorithms (sha1, etc) as they become deprecated, or key exchange algorithms. That cannot be done with this patch set. The minimum bar configuration will still be there, however there will be some different config option for the protocols.

> Plus I want to introduce a distinction, between what is not compiled in (ie. the removed GPG support), and what is compiled in (TLS1.3) and what is compiled-in yet not enabled by default (i.e. TLS1.0 or GOST, or FIPS, or invest NOT-GOST). So yes, this is a soft-disable, to make it just enough annoying for people to move off TLS1.0. I cannot just drop TLS1.0 just yet, without allowing users to access it unfortunately, but I must start sunsetting it. TLSv1.2 is at 96.5% support in the SSl Pulse. Meaning 3.5% public sites (+ lots private ones) will be inaccessible if I just drop TLS1.0, thus an escape hatch is needed. Eventually I would want to stop compiling TLS1.0/1.1 support at all, but I envision that might only be viable in 2-4 years time.

> In Debian and Ubuntu, we currently do not ship a gnutls configuration file. Introducing a configuration file is cumbersome (this is to say users will be grumpy, given that previously it was not required). It can be bypassed with an environment variable. And one has to ensure that the configuration file is copied around into chroots/containers/initrd/snap along with the library. And any LSM confinements (apparmor,selinux,smack,etc) need to be adjusted to permit access to it. Overall, I wouldn't want to rely on neglecting to copy a config file around to enforce a particular distributor minimum requirements.

`chroot()` environments do not have an issue with the configuration because it is loaded at process load, before chroot. Containers the same as they are build from packages and you have direct control on the dependencies. You've got a point though with the fact that a specific confinement can restrict control of the configuration file and we have no way to enforce its reading.

> To contrast, Fedora, for example, compiles gnutls with default priority string set to "@system" meaning that the library has never worked, unless a config file that defines SYSTEM is available *or* the app specifies their own priority string.

There are few options that I see here.
 - One that you suggest is change the logic and have the built-in be the "default" level that a distribution may want. That would require though a re-framing of the config as it is now, to make it possible to raise/lower the default bar according to what is desired, in all algorithm sets.
 - The other is simpler, and is to add an option to error when the default configuration file is not present. That way a distributor can be assured that its configuration is used or the application fails.

@lumag @xnox What do you think?

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1157#note_268598770
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20200108/e85fb83b/attachment.html>