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

[Nikos Mavrogiannopoulos]

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.

> 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

> 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.

regards,
Nikos