[gnutls-help] "built-in" gnutls config, with optional-only config file on disk

[Dimitri John Ledkov]

On Fri, 3 Jan 2020 at 09:21, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>
> On Tue, Dec 31, 2019 at 4:48 PM Dimitri John Ledkov <xnox at ubuntu.com> wrote:
> > > > What about for the other overrides? I.e. can one somehow compile-in
> > > > default [overrides] that is used, unless system config specifies one?
> > > > I.e. built-in config specifying [overrides] disabled-versions=tls1.0,
> > > > with users able to turn it back on by creating the config and
> > > > specifying like empty [overrides] paragraph, or like using
> > > > reenable-versions=tls1.0.
> > > >
> > > > Maybe I am overthinking all of this, and what I really want is simply
> > > > support for
> > > >     [overrides]
> > > >     default-priority-string = NORMAL
> > > > Whilst the library itself is compiled with something stronger, i.e.
> > > > --with-default-priority-string='NORMAL:-VERS-TLS1.0'.
> > >
> > > That sounds like something reasonable. There is an ongoing coversation
> > > on how to handle national standards like GOST with a similar mechanism
> > > at:
> > > https://gitlab.com/gnutls/gnutls/merge_requests/1119
> > > Would you like to move that discussion there so that we combine the
> > > requirements?
> >
> > Possibly. At the moment I do not see any better way than to introduce
> > [overrides]default-priority-string in the config file. As I want
> > NORMAL:-VERS-TLS1.0:-VERS-TLS1.1:%PROFILE_MEDIUM as the compiled-in
> > default but a way for users to override this behaviour in a config
> > file, which I don't see a way to do at the moment.
>
> Please open an issue at our tracker to continue this discussion there.
>

ok.

> > Also there isn't a compiled-in default for the [overrides]
> > verify-profile key, nor for the compiled-in [overrides]
> > disabled-version key, nor a way to reenable compiled-in
> > disabled-versions.
>
> The configuration as it is now it sets the minimum bar that cannot be
> changed by applications. That's to provide assurance that no
> application opts out from that minimum bar. The goal is to use that
> bar to configure for inflexible requirements (e.g., compliance, or
> other legal ones).
>
> Nevertheless, the fact that we do not set a verification profile
> outside TLS is something that I missed as well. I've opened this to
> track for the next major update:
> https://gitlab.com/gnutls/gnutls/issues/895
>

Nice.

> > Imho, any library should have sensible compiled-in defaults, which can
> > be overridden with config files, such that one can have "available,
> > but disabled by default" algos / protocol version / profile levels /
> > etc, which users can opt-into anyway. This is separete to choosing to
> > not even compile unwanted protocol versions (i.e. just disable tls1.3
> > at build time, and not include that functionality in the library at
> > all).
>
> I believe the defaults provided by gnutls are sensible and quite
> conservative, even though TLS-focused. Of course a distribution can go
> better using the configuration file (see fedora crypto policies). If
> you refer to the certificate verification outside TLS defaults, indeed
> as I said that's something missing but it looks like me like an ABI
> break and I do not think we should not break ABI considerably outside
> a major update. Otherwise test suites and applications that worked
> before may break unexpectedly.

It's not an api/abi break in a classic sense, but a runtime break.
Debian has already did so with OpenSSL forcing all the reverse
dependencies to upgrade the certificates to stronger ones (key sizes /
signature hashes).

All major web browser are turning off TLS less than 1.2 by default
this year, yet still compiling it in and allowing users to enable it
back on.

I will be doing similar in Ubuntu too for all the major crypto libraries.

I am working on a patch that allows at configure time mark TLS
1.0/1.1, DTLS 0.9 / 1.1 versions struct supported = 0, and allow to
use overrides to force mark those back up as supported. It still
follows the minimum bar principle, i.e. if at configure time older tls
versions are marked as unsupported a system-wide config & app need to
both enable tls1.0 usage for it to succeed. I will post this as soon
as all the tests pass in all the configuration options.

-- 
Regards,

Dimitri.