Re: [HACKERS] GnuTLS support

On 01/17/2018 11:14 PM, Peter Eisentraut wrote:
> On 1/17/18 14:05, Tom Lane wrote:
>> Although these corner cases are starting to make me feel like
>> changing my original vote. Maybe we should forget the prefixes, in
>> particular renaming gnutls_priorities to ssl_priorities, and just
>> accept the need to document some parameters as only relevant to
>> some implementations.
>
> We could go the route of normalizing all implementation-specific
> settings to some set of atomic concepts and create separate settings
> for those, and then map them back to the actual APIs in code.
>

I think it's reasonable to expect that other SSL libraries implementing
the same crypto algorithms will have APIs with the same (or very
similar) concepts and parameters, so +1 to doing this.

> So we could take ssl_ciphers, ssl_prefer_server_ciphers,
> ssl_ecdh_curve and assemble internally something that we can pass to
> gnutls_priority_init().
>

I think the question here is how far we want to go. For example, the
various libraries are likely using different formats for the lists of
preferred cipher suites. Are we fine with that? The meaning of the GUC
will be the same, but the format (or cipher suite naming) will depend on
the library.

(I don't think we want to get into the business of inventing our custom
universal syntax, nor accepting OpenSSL syntax/naming as the right one
and translating everything to/from it.)

> But I think it would be more helpful in practice if the naming of
> the implementation-specific settings match with something you can
> look up in the documentation of that implementation. "GnuTLS priority
> string" is easy to look up and well documented. If instead we chop it
> up into something that is more like the OpenSSL settings, I think we
> are not helping anyone.
>

Meh. As long as there's something like "priority string" for that
particular library, I think we're fine. We can just say "This is a
priority string, the format depends on the SSL library used," and
perhaps even link to additional docs for each supported library.

What would be much worse is if a particular GUC did not have a matching
concept in the library. Say if an SSL library did not have a concept of
priority strings and instead used some other concept affecting cipher
suite choice (not sure how that would like). That would make our GUC
useless or confusing, possibly forcing us to translate the strings in
some strange way.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services