GnuTLS support

From: Andreas Karlsson <andreas(at)proxel(dot)se>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: GnuTLS support
Date: 2017-08-31 17:52:43
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers


I have seen discussions from time to time about OpenSSL and its
licensing issues so I decided to see how much work it would be to add
support for another TLS library, and I went with GnuTLS since it is the
library I know best after OpenSSL and it is also a reasonably popular

Attached is a work in progress patch which implements the basics. I send
it the list because I want feedback on some design questions and to
check with the community if this is a feature we want.

= What is implemented

- Backend
- Frontend
- Diffie-Hellmann support
- Using GnuTLS for secure random numbers
- Using GnuTLS for sha2

= Work left to do

- Add GnuTLS support to sslinfo
- Add GnuTLS support to pgcrypto
- Support for GnuTLS's version of engines
- Test code with older versions of GnuTLS
- Update documentation
- Add support for all postgresql.conf options (see design question)
- Fix two failing tests (see design question)

= Design questions

== GnuTLS priority strings vs OpenSSL cipher lists

GnuTLS uses a different format for specifying ciphers. Instead of
setting ciphers, protocol versions, and ECDH curves separately GnuTLS
instead uses a single priority string[1].

For example the default settings of PostgreSQL (which include disabling

ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL' # allowed SSL ciphers
ssl_prefer_server_ciphers = on
ssl_ecdh_curve = 'prime256v1'

is represented with a string similar to


So the two libraries have decided on different ways to specify things.

One way to solve th issue would be to just let ssl_ciphers be the
priority string and then add %SERVER_PRECEDENCE to it if
ssl_prefer_server_ciphers is on. Adding the ssl_ecdh_curve is trickier
since the curves have different names in GnuTLS (e.g. prime256v1 vs
SECP256R1) and I would rather avoid having to add such a mapping to
PostgreSQL. Thoughts?

== Potentially OpenSSL-specific est cases

There are currently two failing SSL tests which at least to me seems
more like they test specific OpenSSL behaviors rather than something
which need to be true for all SSL libraries.

The two tests:

# Try with just the server CA's cert. This fails because the root file
# must contain the whole chain up to the root CA.
note "connect with server CA cert, without root CA";
test_connect_fails("sslrootcert=ssl/server_ca.crt sslmode=verify-ca");

# A CRL belonging to a different CA is not accepted, fails
"sslrootcert=ssl/root+server_ca.crt sslmode=verify-ca

For the missing root CA case GnuTLS seems to be happy enough with just
an intermediate CA and as far as I can tell this behavior is not easy to

And for the CRL belonging to a different CA case GnuTLS can be
configured to either just store such a non-validating CRL or to ignore
it, but not to return an error.

Personally I think thee two tests should just be removed but maybe I am
missing something.




Attachment Content-Type Size
gnutls-v1.patch text/x-patch 69.8 KB


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-08-31 17:57:38 Re: Proposal: Improve bitmap costing for lossy pages
Previous Message Robert Haas 2017-08-31 17:46:07 Re: Assorted leaks and weirdness in parallel execution