|From:||Andreas Karlsson <andreas(at)proxel(dot)se>|
|Views:||Raw Message | Whole Thread | Download mbox|
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
- 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.
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
== 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";
# A CRL belonging to a different CA is not accepted, fails
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
|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|