GnuTLS support

On Thu, Aug 31, 2017 at 1:52 PM, Andreas Karlsson <andreas@proxel.se> wrote:

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

Thanks for working on this. I think it's good for PostgreSQL to have
more options in this area.

= 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
SSLv3)

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

SECURE128:+3DES-CBC:+GROUP-SECP256R1:%SERVER_PRECEDENCE

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

I think that what this shows is that the current set of GUCs is overly
OpenSSL-centric. We created a set of GUCs that are actually specific
to one particular implementation but named them as if they were
generic. My idea about this would be to actually rename the existing
GUCs to start with "openssl" rather than "ssl", and then add new GUCs
as needed for other SSL implementations.

Depending on what we think is best, GUCs for an SSL implementation
other than the one against which we compiled can either not exist at
all, or can exist but be limited to a single value (e.g. "none", as we
currently do when the compile has no SSL support at all). Also, we
could add a read-only GUC with a name like ssl_library that exposes
the name of the underlying SSL implementation - none, openssl, gnutls,
or whatever.

I think if we go the route of insisting that every SSL implementation
has to use the existing GUCs, we're just trying to shove a square peg
into a round hole, and there's no real benefit for users. If the
string that has to be stuffed into ssl_ciphers differs based on which
library was chosen at compile time, then you can't have a uniform
default configuration for all libraries anyway. I think it'll be
easier to explain and document this if there's separate documentation
for openssl_ciphers, gnutls_ciphers, etc. rather than one giant
documentation section that tries to explain every implementation
separately.

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
test_connect_fails(
"sslrootcert=ssl/root+server_ca.crt sslmode=verify-ca
sslcrl=ssl/client.crl");

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

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.

I don't know what we should do about these issues.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:

On Thu, Aug 31, 2017 at 1:52 PM, Andreas Karlsson <andreas@proxel.se> wrote:

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

Thanks for working on this. I think it's good for PostgreSQL to have
more options in this area.

+1. We also have a patch in the queue to support macOS' TLS library,
and I suppose that's going to be facing similar issues. It would be
a good plan, probably, to try to push both of these to conclusion in
the same development cycle.

I think that what this shows is that the current set of GUCs is overly
OpenSSL-centric. We created a set of GUCs that are actually specific
to one particular implementation but named them as if they were
generic. My idea about this would be to actually rename the existing
GUCs to start with "openssl" rather than "ssl", and then add new GUCs
as needed for other SSL implementations.

Works for me.

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.

I don't know what we should do about these issues.

Maybe the SSL test suite needs to be implementation-specific as well.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 01 Sep 2017, at 19:10, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@gmail.com> writes:

On Thu, Aug 31, 2017 at 1:52 PM, Andreas Karlsson <andreas@proxel.se> wrote:

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.

I don't know what we should do about these issues.

Maybe the SSL test suite needs to be implementation-specific as well.

To properly test the macOS Secure Transport support we will need to use
Keychain files on top of plain PEM files, so I think we have to. That being
said, we should probably define a (as large possible) minimum set which applies
to all to ensure compatability between different frontends and backends.

cheers ./daniel

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Sep 1, 2017 at 1:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@gmail.com> writes:

On Thu, Aug 31, 2017 at 1:52 PM, Andreas Karlsson <andreas@proxel.se> wrote:

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

Thanks for working on this. I think it's good for PostgreSQL to have
more options in this area.

+1. We also have a patch in the queue to support macOS' TLS library,
and I suppose that's going to be facing similar issues. It would be
a good plan, probably, to try to push both of these to conclusion in
the same development cycle.

The thing which I think would save the most aggravation - at least for
my employer - is a Windows SSL implementation. Relying on OpenSSL
means that every time OpenSSL puts out a critical security fix, we've
got to rewrap all the Windows installers to pick up the new version.
If we were relying on what's built into Windows, it would be
Microsoft's problem. Granted, it's not anybody's job to solve
EnterpriseDB's problems except EnterpriseDB, but users might like it
too -- and anyone else who is building Windows installers for
PostgreSQL.

Depending on macOS TLS instead of OpenSSL has similar advantages, of
course, just for a somewhat less common platform.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 01 Sep 2017, at 20:00, Robert Haas <robertmhaas@gmail.com> wrote:

On Fri, Sep 1, 2017 at 1:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@gmail.com> writes:

On Thu, Aug 31, 2017 at 1:52 PM, Andreas Karlsson <andreas@proxel.se> wrote:

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

Thanks for working on this. I think it's good for PostgreSQL to have
more options in this area.

+1. We also have a patch in the queue to support macOS' TLS library,
and I suppose that's going to be facing similar issues. It would be
a good plan, probably, to try to push both of these to conclusion in
the same development cycle.

The thing which I think would save the most aggravation - at least for
my employer - is a Windows SSL implementation.

In 53EA546E.6020404@vmware.com, an early version of SChannel support was posted
by Heikki. If anyone is keen to pick up the effort that would most likely be a
good starting point.

Relying on OpenSSL
means that every time OpenSSL puts out a critical security fix, we've
got to rewrap all the Windows installers to pick up the new version.
If we were relying on what's built into Windows, it would be
Microsoft's problem. Granted, it's not anybody's job to solve
EnterpriseDB's problems except EnterpriseDB, but users might like it
too -- and anyone else who is building Windows installers for
PostgreSQL.

Depending on macOS TLS instead of OpenSSL has similar advantages, of
course, just for a somewhat less common platform.

I think providing alternatives to OpenSSL on platforms where OpenSSL can’t be
relied on to be already available (Windows and macOS come to mind) would be a
great thing for many users and app developers.

cheers ./daniel

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

On Thu, Aug 31, 2017 at 1:52 PM, Andreas Karlsson <andreas@proxel.se> wrote:

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.

I don't know what we should do about these issues.

Maybe the SSL test suite needs to be implementation-specific as well.

If only two tests fail currently, I suggest that the thing to do is to
split it up in generic vs. library-specific test files. It should be
easy to do with the TAP framework -- just move the library-specific
tests to their own file and mark it as skipped at the start of the file
when a different library is detected.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Sep 1, 2017 at 12:09:35PM -0400, Robert Haas wrote:

I think that what this shows is that the current set of GUCs is overly
OpenSSL-centric. We created a set of GUCs that are actually specific
to one particular implementation but named them as if they were
generic. My idea about this would be to actually rename the existing
GUCs to start with "openssl" rather than "ssl", and then add new GUCs
as needed for other SSL implementations.

Depending on what we think is best, GUCs for an SSL implementation
other than the one against which we compiled can either not exist at
all, or can exist but be limited to a single value (e.g. "none", as we
currently do when the compile has no SSL support at all). Also, we
could add a read-only GUC with a name like ssl_library that exposes
the name of the underlying SSL implementation - none, openssl, gnutls,
or whatever.

I think if we go the route of insisting that every SSL implementation
has to use the existing GUCs, we're just trying to shove a square peg
into a round hole, and there's no real benefit for users. If the
string that has to be stuffed into ssl_ciphers differs based on which
library was chosen at compile time, then you can't have a uniform
default configuration for all libraries anyway. I think it'll be
easier to explain and document this if there's separate documentation
for openssl_ciphers, gnutls_ciphers, etc. rather than one giant
documentation section that tries to explain every implementation
separately.

I am worried about having 3x version of TLS controls in postgresql.conf,
and only one set being active. Perhaps we need to break out the TLS
config to separate files or something. Anyway, this needs more thought.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Sep 01, 2017 at 10:33:37PM +0200, Alvaro Herrera wrote:

Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

On Thu, Aug 31, 2017 at 1:52 PM, Andreas Karlsson <andreas@proxel.se> wrote:

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.

I don't know what we should do about these issues.

Maybe the SSL test suite needs to be implementation-specific as well.

If only two tests fail currently, I suggest that the thing to do is to
split it up in generic vs. library-specific test files. It should be
easy to do with the TAP framework -- just move the library-specific
tests to their own file and mark it as skipped at the start of the file
when a different library is detected.

This seems like a much smarter and more reliable way to test.

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Hi,

On 09/04/2017 04:24 PM, Bruce Momjian wrote:

On Fri, Sep 1, 2017 at 12:09:35PM -0400, Robert Haas wrote:

I think that what this shows is that the current set of GUCs is overly
OpenSSL-centric. We created a set of GUCs that are actually specific
to one particular implementation but named them as if they were
generic. My idea about this would be to actually rename the existing
GUCs to start with "openssl" rather than "ssl", and then add new GUCs
as needed for other SSL implementations.

Depending on what we think is best, GUCs for an SSL implementation
other than the one against which we compiled can either not exist at
all, or can exist but be limited to a single value (e.g. "none", as we
currently do when the compile has no SSL support at all). Also, we
could add a read-only GUC with a name like ssl_library that exposes
the name of the underlying SSL implementation - none, openssl, gnutls,
or whatever.

I think if we go the route of insisting that every SSL implementation
has to use the existing GUCs, we're just trying to shove a square peg
into a round hole, and there's no real benefit for users. If the
string that has to be stuffed into ssl_ciphers differs based on which
library was chosen at compile time, then you can't have a uniform
default configuration for all libraries anyway. I think it'll be
easier to explain and document this if there's separate documentation
for openssl_ciphers, gnutls_ciphers, etc. rather than one giant
documentation section that tries to explain every implementation
separately.

I am worried about having 3x version of TLS controls in
postgresql.conf, and only one set being active. Perhaps we need to
break out the TLS config to separate files or something. Anyway, this
needs more thought.

Well, people won't be able to set the inactive options, just like you
can't set ssl=on when you build without OpenSSL support. But perhaps we
could simply not include the inactive options into the config file, no?

I don't see how breaking the TLS config into separate files improves the
situation - instead of dealing with GUCs in a single file you'll be
dealing with the same GUCs in multiple files. No?

regards

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Sep 7, 2017 at 2:34 PM, Tomas Vondra <tomas.vondra@2ndquadrant.com>
wrote:

Hi,

On 09/04/2017 04:24 PM, Bruce Momjian wrote:

On Fri, Sep 1, 2017 at 12:09:35PM -0400, Robert Haas wrote:

I think that what this shows is that the current set of GUCs is overly
OpenSSL-centric. We created a set of GUCs that are actually specific
to one particular implementation but named them as if they were
generic. My idea about this would be to actually rename the existing
GUCs to start with "openssl" rather than "ssl", and then add new GUCs
as needed for other SSL implementations.

Depending on what we think is best, GUCs for an SSL implementation
other than the one against which we compiled can either not exist at
all, or can exist but be limited to a single value (e.g. "none", as we
currently do when the compile has no SSL support at all). Also, we
could add a read-only GUC with a name like ssl_library that exposes
the name of the underlying SSL implementation - none, openssl, gnutls,
or whatever.

I think if we go the route of insisting that every SSL implementation
has to use the existing GUCs, we're just trying to shove a square peg
into a round hole, and there's no real benefit for users. If the
string that has to be stuffed into ssl_ciphers differs based on which
library was chosen at compile time, then you can't have a uniform
default configuration for all libraries anyway. I think it'll be
easier to explain and document this if there's separate documentation
for openssl_ciphers, gnutls_ciphers, etc. rather than one giant
documentation section that tries to explain every implementation
separately.

I am worried about having 3x version of TLS controls in
postgresql.conf, and only one set being active. Perhaps we need to
break out the TLS config to separate files or something. Anyway, this
needs more thought.

Well, people won't be able to set the inactive options, just like you
can't set ssl=on when you build without OpenSSL support. But perhaps we
could simply not include the inactive options into the config file, no?

We build the pg_hba.conf file dynamically depending on if we have ipv6
support, IIRC. Maybe we need to implement that type of support into
postgresql.conf as well?

It will still be a mess though -- documentation, and tutorials around and
whatnot, will be dependent on library. But I'm not sure we can really get
around that.

Do we have some examples of how other products that support multiple
libraries do to handle this?

I don't see how breaking the TLS config into separate files improves the
situation - instead of dealing with GUCs in a single file you'll be
dealing with the same GUCs in multiple files. No?

+1. I don't think splitting them up into different files makes it in any
way better -- if anything, it makes it worse.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

On 09/07/2017 11:34 PM, Tomas Vondra wrote:

I am worried about having 3x version of TLS controls in
postgresql.conf, and only one set being active. Perhaps we need to
break out the TLS config to separate files or something. Anyway, this
needs more thought.

Well, people won't be able to set the inactive options, just like you
can't set ssl=on when you build without OpenSSL support. But perhaps we
could simply not include the inactive options into the config file, no?

Yeah, I have been thinking about how bad it would be to dynamically
generate the config file. I think I will try this.

Daniel: What options does Secure Transport need for configuring ciphers,
ECDH, and cipher preference? Does it need any extra options (I think I
saw something about the keychain)?

Andreas

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andreas Karlsson <andreas@proxel.se> writes:

On 09/07/2017 11:34 PM, Tomas Vondra wrote:

Well, people won't be able to set the inactive options, just like you
can't set ssl=on when you build without OpenSSL support. But perhaps we
could simply not include the inactive options into the config file, no?

Yeah, I have been thinking about how bad it would be to dynamically
generate the config file. I think I will try this.

I'm not exactly convinced that dynamically inserting some parameters
and not others is a great idea. Remember that people tend to copy
postgresql.conf files forward from one installation to another. Or
they might decide to rebuild the postmaster for an existing installation
with a different SSL library. In any scenario like that, you've not
done them any real favor if the config file they have contains no trace
of the SSL parameters they need.

I think we might be best off just playing it straight and providing
a config file that contains a section along these lines:

# Parameters for OpenSSL. Leave these commented out if not using OpenSSL.
#
#ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL' # allowed SSL ciphers
#ssl_prefer_server_ciphers = on
#ssl_ecdh_curve = 'prime256v1'
#ssl_dh_params_file = ''
#ssl_cert_file = 'server.crt'
#ssl_key_file = 'server.key'
#ssl_ca_file = ''
#ssl_crl_file = ''
#
# Parameters for GnuTLS. Leave these commented out if not using GnuTLS.
#
#gnufoo=...
#gnubar=...
#
# Parameters for macOS TLS. ... you get the idea.

As previously noted, it'd be a good idea to rename the existing
ssl_xxx parameters to openssl_xxx, except maybe ones that we think
will be universal. (But even if we do think that, it might be
simpler in the long run to just have three or four totally independent
sections of the config file, instead of some common and some library-
specific parameters.)

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Sep 7, 2017 at 10:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

I think we might be best off just playing it straight and providing
a config file that contains a section along these lines:

# Parameters for OpenSSL. Leave these commented out if not using OpenSSL.
#
#ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL' # allowed SSL ciphers
#ssl_prefer_server_ciphers = on
#ssl_ecdh_curve = 'prime256v1'
#ssl_dh_params_file = ''
#ssl_cert_file = 'server.crt'
#ssl_key_file = 'server.key'
#ssl_ca_file = ''
#ssl_crl_file = ''
#
# Parameters for GnuTLS. Leave these commented out if not using GnuTLS.
#
#gnufoo=...
#gnubar=...
#
# Parameters for macOS TLS. ... you get the idea.

As previously noted, it'd be a good idea to rename the existing
ssl_xxx parameters to openssl_xxx, except maybe ones that we think
will be universal. (But even if we do think that, it might be
simpler in the long run to just have three or four totally independent
sections of the config file, instead of some common and some library-
specific parameters.)

+1 to all of that.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Aug 31, 2017 at 10:52 AM, Andreas Karlsson <andreas@proxel.se>
wrote:

= Work left to do

- Test code with older versions of GnuTLS

I can't build against gnutls-2.12.23-21.el6.x86_64 from CentOS 6.9

be-secure-gnutls.c: In function 'be_tls_init':
be-secure-gnutls.c:168: warning: implicit declaration of function
'gnutls_certificate_set_pin_function'
be-secure-gnutls.c: In function 'get_peer_certificate':
be-secure-gnutls.c:656: error: 'GNUTLS_X509_CRT_LIST_SORT' undeclared
(first use in this function)
be-secure-gnutls.c:656: error: (Each undeclared identifier is reported only
once
be-secure-gnutls.c:656: error: for each function it appears in.)

But I can build on ubuntu 16.04, using whatever baffling salami of package
versions they turned gnutls into on that system.

I can interoperate in both direction gnutls client to openssl server and
the reverse (and gnutls to gnutls).

Cheers,

Jeff

On 09/15/2017 06:55 PM, Jeff Janes wrote:

I can't build against gnutls-2.12.23-21.el6.x86_64 from CentOS 6.9

Thanks for testing my patch. I have fixed both these issues plus some of
the other feedback. A new version of my patch is attached which should,
at least on theory, support all GnuTLS versions >= 2.11.

I just very quickly fixed the broken SSL tests, as I am no fan of how
the SSL tests currently are written and think they should be cleaned up.

Andreas

On Sun, Sep 17, 2017 at 2:17 PM, Andreas Karlsson <andreas@proxel.se> wrote:

On 09/15/2017 06:55 PM, Jeff Janes wrote:

I can't build against gnutls-2.12.23-21.el6.x86_64 from CentOS 6.9

Thanks for testing my patch. I have fixed both these issues plus some of
the other feedback. A new version of my patch is attached which should, at
least on theory, support all GnuTLS versions >= 2.11.

You fixed the first issue, but I still get the second one:

be-secure-gnutls.c: In function 'get_peer_certificate':
be-secure-gnutls.c:667: error: 'GNUTLS_X509_CRT_LIST_SORT' undeclared
(first use in this function)
be-secure-gnutls.c:667: error: (Each undeclared identifier is reported only
once
be-secure-gnutls.c:667: error: for each function it appears in.)

Cheers,

Jeff

On 09/18/2017 07:04 PM, Jeff Janes wrote:> You fixed the first issue,
but I still get the second one:

be-secure-gnutls.c: In function 'get_peer_certificate':
be-secure-gnutls.c:667: error: 'GNUTLS_X509_CRT_LIST_SORT' undeclared
(first use in this function)
be-secure-gnutls.c:667: error: (Each undeclared identifier is reported
only once
be-secure-gnutls.c:667: error: for each function it appears in.)

Thanks again for testing the code. I have now rebased the patch and
fixed the second issue. I tested that it works on CentOS 6.

Work which remains:

- sslinfo
- pgcrypto
- Documentation
- Decide if what I did with the config is a good idea

Andreas

Hi,

On 11/02/2017 11:33 PM, Andreas Karlsson wrote:

On 09/18/2017 07:04 PM, Jeff Janes wrote:> You fixed the first issue,
but I still get the second one:

be-secure-gnutls.c: In function 'get_peer_certificate':
be-secure-gnutls.c:667: error: 'GNUTLS_X509_CRT_LIST_SORT' undeclared
(first use in this function)
be-secure-gnutls.c:667: error: (Each undeclared identifier is reported
only once
be-secure-gnutls.c:667: error: for each function it appears in.)

Thanks again for testing the code. I have now rebased the patch and
fixed the second issue. I tested that it works on CentOS 6.

Work which remains:

- sslinfo
- pgcrypto
- Documentation
- Decide if what I did with the config is a good idea

I don't want to be the annoying guy, but this patch no longer applies
due to 642bafa0c5f9f08d106a14f31429e0e0c718b603 touching the tests :-(

BTW regarding the config, I believe you've kept is static (no hiding of
sections based on configure parameters), and you've separated the
openssl and gnutls options, right? Seems fine to me. The one thing is
that it was proposed to rename the openssl-specific options to start
with openssl_ instead of ssl_.

One question though. What happens when you do

./configure --with-openssl --with-gnutls

If I get it right we ignore gnutls and use openssl (as it's the first
checked in #ifdefs). Shouldn't we enforce in configure that only one TLS
implementation is enabled? Either by some elaborate check, or by
switching to something like

--with-ssl=(openssl|gnutls)

regards

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

On Mon, Nov 20, 2017 at 9:42 AM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:

I don't want to be the annoying guy, but this patch no longer applies
due to 642bafa0c5f9f08d106a14f31429e0e0c718b603 touching the tests :-(

Sorry about that. Something more specific needs to happen here as well
for channel binding support with SCRAM. CheckSCRAMAuth() now assumes
that the channel binding mechanism SCRAM-SHA-256-PLUS can be published
to the client if SSL is used, because OpenSSL is the only
implementation available. Does gnutls include an API to allow an
application to fetch the bytes from the TLS finished message? I can
see some references by glancing at the tarball of gnutls 3.6.1, but
you would need something similar to OpenSSL's SSL_get_peer_finished().
If that cannot be achieved I think that it will be necessary to tweak
auth.c to not publish the -PLUS mechanism if for example the result of
be_tls_get_peer_finished() is NULL. No need for a new SSL-specific
API. At the end it would prove to be more portable to do so for all
the SSL implementations, MacOS stuff does not document an API to get
the TLS finish message bytes.

If I get it right we ignore gnutls and use openssl (as it's the first
checked in #ifdefs). Shouldn't we enforce in configure that only one TLS
implementation is enabled? Either by some elaborate check, or by
switching to something like

--with-ssl=(openssl|gnutls)

WIth potential patches coming to use macos' SSL implementation or
Windows channel, there should really be only one implementation
available at compile time. That's more simple as a first step as well.
So +1 for the --with-ssl switch.
--
Michael