PQgetssl() and alternative SSL implementations

On Mon, Aug 18, 2014 at 12:54 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:

server_cert_valid: Did the server present a valid certificate? "yes" or
"no"

Is this just whether the signature verifies? Or whether the chain is
all verified? Or whether the chain leads to a root in the directory?
Does it include verifying the CN? How does the CN comparison get done?

I think you either need to decide that libpq will do all the
verification and impose a blanket policy or leave the verification up
to the application and just return each of these properties as
individual boolean flags.

--
greg

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

* Heikki Linnakangas (hlinnakangas@vmware.com) wrote:

server_cert_valid: Did the server present a valid certificate?
"yes" or "no"

server_cert_matches_host: Does the Common Name of the certificate
match the host connected to? "yes" or "no"

Aren't these questions addressed by sslmode?

Exposing the SSL information as generic key/value pairs allows
adding more attributes in the future, without breaking the ABI, and
it also allows exposing implementation-specific information in a
generic way. The attributes listed above cover the needs of psql.
What else do we need?

At first blush, I'd say a whole bunch.. Off the top of my head I can
think of:

For all certificates:
(client, server, cert that signed each, any intermediate CAs, root CAs)
Certificate itself (perhaps in DER, PEM, X509 formats..)
Fingerprint
Signed-By info
Common Name
Organization (et al)
Alternate names
Issue date, expiration date
CRL info, OCSP info
Allowed usage (encryption, signing, etc)

CRL checking done?
OCSP used?

I think it would also be nice to get more information from the
server's certificate, like the hostname and the organization its
issued to, and expiration date, so that an interactive client like
pgAdmin or even psql could display that information like a web
browser does. Would it be best to add those as extra attributes in
the above list, perhaps with a "server_cert_*" prefix, or add a new
function for extracting server cert's attributes?

This really shouldn't be for *just* the server's certificate but rather
available for all certificates involved- on both sides.

The other question is: What do we do with PQgetssl()? We should
document it as deprecated, but we'll have to keep it around for the
foreseeable future for backwards-compatibility. We obviously cannot
return a valid OpenSSL struct when using any other implementation,
so I think it'll have to just return NULL when not using OpenSSL.
Probably the most common use of PQgetssl() is to just check if it
returns NULL or not, to determine if SSL is enabled, so a client
that does that would incorrectly think that SSL is not used, even
when it is. I think we can live with that.

That's not ideal, but the only other option I can think of offhand is to
break the existing API and force everyone to update and that seems
worse.

Have you looked at how this change will play out with the ODBC driver..?
Especially on Windows with the SSL library you're proposing we use
there.. I recall that at one point the ODBC driver simply used libpq to
handle the authentication and set everything up, and then switched to
talking directly without libpq. In any case, it'd probably be good to
make sure the attributes you're suggesting are sufficient to meet the
needs of the ODBC driver too.

Thanks,

Stephen

On 2014-08-19 10:48:41 -0400, Stephen Frost wrote:

Exposing the SSL information as generic key/value pairs allows
adding more attributes in the future, without breaking the ABI, and
it also allows exposing implementation-specific information in a
generic way. The attributes listed above cover the needs of psql.
What else do we need?

At first blush, I'd say a whole bunch.. Off the top of my head I can
think of:

For all certificates:
(client, server, cert that signed each, any intermediate CAs, root CAs)
Certificate itself (perhaps in DER, PEM, X509 formats..)
Fingerprint
Signed-By info
Common Name
Organization (et al)
Alternate names
Issue date, expiration date
CRL info, OCSP info
Allowed usage (encryption, signing, etc)

CRL checking done?
OCSP used?

I'm not really sure we need all that. We're not building a general ssl
library abstraction here. Presenting all those in a common and useful
format isn't trivial.

What I'm wondering is whether we should differentiate 'standard'
attributes that we require from ones that a library can supply
optionally. If we don't we'll have difficulty enlarging the 'standard'
set over time.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, 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 Tue, Aug 19, 2014 at 4:48 PM, Stephen Frost <sfrost@snowman.net> wrote:

* Heikki Linnakangas (hlinnakangas@vmware.com) wrote:

server_cert_valid: Did the server present a valid certificate?
"yes" or "no"

server_cert_matches_host: Does the Common Name of the certificate
match the host connected to? "yes" or "no"

Aren't these questions addressed by sslmode?

Not entirely. You can have sslmode=require and have a matching
certificate. You don't *have* to have sslmode=verify-full for that.

However, whether it makes *sense* without sslmode is another story -
but assuming you use something like kerberos for auth, it might. For
password, you've already lost once you get that far.

Exposing the SSL information as generic key/value pairs allows
adding more attributes in the future, without breaking the ABI, and
it also allows exposing implementation-specific information in a
generic way. The attributes listed above cover the needs of psql.
What else do we need?

At first blush, I'd say a whole bunch.. Off the top of my head I can
think of:

For all certificates:
(client, server, cert that signed each, any intermediate CAs, root CAs)
Certificate itself (perhaps in DER, PEM, X509 formats..)

Yeah, if we can extract it in PEM for example, that would be useful.

Fingerprint

Definitely.

Signed-By info

If we can get the full cert, do that one instead.

Common Name

Definitely.

Organization (et al)
Alternate names
Issue date, expiration date
CRL info, OCSP info
Allowed usage (encryption, signing, etc)

All those would also be covered by the "certificate itself" part I
think - they're not that common.

CRL checking done?
OCSP used?

I think it would also be nice to get more information from the
server's certificate, like the hostname and the organization its
issued to, and expiration date, so that an interactive client like
pgAdmin or even psql could display that information like a web
browser does. Would it be best to add those as extra attributes in
the above list, perhaps with a "server_cert_*" prefix, or add a new
function for extracting server cert's attributes?

This really shouldn't be for *just* the server's certificate but rather
available for all certificates involved- on both sides.

Well, if you are already the client, wouldn't you know your own certificate?

The other question is: What do we do with PQgetssl()? We should
document it as deprecated, but we'll have to keep it around for the
foreseeable future for backwards-compatibility. We obviously cannot
return a valid OpenSSL struct when using any other implementation,
so I think it'll have to just return NULL when not using OpenSSL.
Probably the most common use of PQgetssl() is to just check if it
returns NULL or not, to determine if SSL is enabled, so a client
that does that would incorrectly think that SSL is not used, even
when it is. I think we can live with that.

That's not ideal, but the only other option I can think of offhand is to
break the existing API and force everyone to update and that seems
worse.

Agreed.

If we just return an arbitrary pointer, then any application that
*did* actually try to use it would crash.

It's not ideal, but errorring in the way of not saying we're secure
when we are, is acceptable - unlike the opposite.

Of course, we need to publish it very clearly in the release notes,
and I would suggest backpatching into the documentation in old
versions etc as well.

Have you looked at how this change will play out with the ODBC driver..?
Especially on Windows with the SSL library you're proposing we use
there.. I recall that at one point the ODBC driver simply used libpq to
handle the authentication and set everything up, and then switched to
talking directly without libpq. In any case, it'd probably be good to
make sure the attributes you're suggesting are sufficient to meet the
needs of the ODBC driver too.

+1.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

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

* Andres Freund (andres@2ndquadrant.com) wrote:

On 2014-08-19 10:48:41 -0400, Stephen Frost wrote:

At first blush, I'd say a whole bunch.. Off the top of my head I can
think of:

[...]

I'm not really sure we need all that. We're not building a general ssl
library abstraction here.

Really? I'm pretty sure that's exactly what we're doing. What I was
wondering is which one we should be modeling off of.

One thought I had was to look at what Apache's mod_ssl provides, which
can be seen here: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html

I know that I've used quite a few of those.

Telling users they simply can't have this information isn't acceptable.
I'm not a huge fan of just passing back all of the certificates and
making the user extract out the information themselves, but if it comes
down to it then that's at least better than removing any ability to get
at that information.

What I'm wondering is whether we should differentiate 'standard'
attributes that we require from ones that a library can supply
optionally. If we don't we'll have difficulty enlarging the 'standard'
set over time.

If we end up not being able to provide everything for all of the
libraries we support then perhaps we can document which are available
from all of them, but I'd hope the list of "only in X" is pretty small.

Thanks,

Stephen

On Tue, Aug 19, 2014 at 5:05 PM, Stephen Frost <sfrost@snowman.net> wrote:

* Andres Freund (andres@2ndquadrant.com) wrote:

On 2014-08-19 10:48:41 -0400, Stephen Frost wrote:

At first blush, I'd say a whole bunch.. Off the top of my head I can
think of:

[...]

I'm not really sure we need all that. We're not building a general ssl
library abstraction here.

Really? I'm pretty sure that's exactly what we're doing. What I was
wondering is which one we should be modeling off of.

One thought I had was to look at what Apache's mod_ssl provides, which
can be seen here: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html

I know that I've used quite a few of those.

Telling users they simply can't have this information isn't acceptable.
I'm not a huge fan of just passing back all of the certificates and
making the user extract out the information themselves, but if it comes
down to it then that's at least better than removing any ability to get
at that information.

Yeah, being able to provide most of them easily accessible is a good
thing. Otherwise, we just move the burden to deparse them to the
client which will then have to know which SSL library it's built
against, so every single client that wants to do something useful with
the cert would have to know about multiple implementations.

I think starting from the apache list is a very good idea.

We should then expose the same set of data at least through the
sslinfo server module.

What I'm wondering is whether we should differentiate 'standard'
attributes that we require from ones that a library can supply
optionally. If we don't we'll have difficulty enlarging the 'standard'
set over time.

If we end up not being able to provide everything for all of the
libraries we support then perhaps we can document which are available
from all of them, but I'd hope the list of "only in X" is pretty small.

+1. I bet the most common ones will be in all of them, because
frankly, it's functionality you just need to use SSL properly.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

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

* Magnus Hagander (magnus@hagander.net) wrote:

On Tue, Aug 19, 2014 at 4:48 PM, Stephen Frost <sfrost@snowman.net> wrote:

Aren't these questions addressed by sslmode?

Not entirely. You can have sslmode=require and have a matching
certificate. You don't *have* to have sslmode=verify-full for that.

However, whether it makes *sense* without sslmode is another story -
but assuming you use something like kerberos for auth, it might. For
password, you've already lost once you get that far.

Sure- I guess my point was really, if you're not verifying them by
sslmode=verify-full, do you really want to ask the question? If you
*are* verifying them by verify-full, then you already know the answers.

What else do we need?

At first blush, I'd say a whole bunch.. Off the top of my head I can
think of:

For all certificates:
(client, server, cert that signed each, any intermediate CAs, root CAs)
Certificate itself (perhaps in DER, PEM, X509 formats..)

Yeah, if we can extract it in PEM for example, that would be useful.

Fingerprint

Definitely.

Signed-By info

If we can get the full cert, do that one instead.

Common Name

Definitely.

Organization (et al)
Alternate names
Issue date, expiration date
CRL info, OCSP info
Allowed usage (encryption, signing, etc)

All those would also be covered by the "certificate itself" part I
think - they're not that common.

Not sure I agree with that but what I don't really like is the
suggestion that we'll need to tell everyone who wants more detailed
information from the certificate to link in whatever their preferred SSL
library is and use that to decode the PEM cert to pull the info. We'll
end up having applications linking in both OpenSSL and GNUTLS, for
example, which is pretty grotty, imv.

Serial is absolutely another one we need to include, as I look over at
what mod_ssl supports. Really, I'd look at that list as our minimum to
support..

I think it would also be nice to get more information from the
server's certificate, like the hostname and the organization its
issued to, and expiration date, so that an interactive client like
pgAdmin or even psql could display that information like a web
browser does. Would it be best to add those as extra attributes in
the above list, perhaps with a "server_cert_*" prefix, or add a new
function for extracting server cert's attributes?

This really shouldn't be for *just* the server's certificate but rather
available for all certificates involved- on both sides.

Well, if you are already the client, wouldn't you know your own certificate?

Uh, no? Not without having a library of your own which can open the
certificate file (after it figures out which one we decided to use- oh
yeah, we should probably include that information too.. and then we
have to make sure we can represent things like "on a smart card") and
then parse and extract the information you want from it..

That's not ideal, but the only other option I can think of offhand is to
break the existing API and force everyone to update and that seems
worse.

Agreed.

If we just return an arbitrary pointer, then any application that
*did* actually try to use it would crash.

That wasn't what I was thinking but rather something like "remove
PQgetssl and replace it with PQgetopenssl" or something, breaking the
API completely, forcing everyone to make changes to compile against the
new library, etc, etc. Very ugly but also very obvious.

It's not ideal, but errorring in the way of not saying we're secure
when we are, is acceptable - unlike the opposite.

Yeah, I tend to agree, though I don't particularly like it. The options
are just so much worse. :/

Of course, we need to publish it very clearly in the release notes,
and I would suggest backpatching into the documentation in old
versions etc as well.

Sounds like a good idea to me.

Thanks,

Stephen

On 08/19/2014 05:48 PM, Stephen Frost wrote:

* Heikki Linnakangas (hlinnakangas@vmware.com) wrote:

server_cert_valid: Did the server present a valid certificate?
"yes" or "no"

server_cert_matches_host: Does the Common Name of the certificate
match the host connected to? "yes" or "no"

Aren't these questions addressed by sslmode?

Sort of. In sslmode=verify-ca, libpq checks that the server cert was
valid (the first attribute) and rejects the connection if not. In
verify-full mode, it also checks that the hostname matches (the second
attribute). But in sslmode=require, it's possible to connect to a server
with an invalid server cert. (to be precise in sslmode=require mode
libpq checks the server cert if a root CA cert was given, but if no root
CA cert is configured it will allow connecting anyway).

I think it would be nice to be able to query those attributes
explicitly, rather than just expect libpq to reject the connection if
something's wrong. For example, I'm thinking that an interactive client
might present an annoying pop-up window to the user if the server cert
is not valid, asking if he wants to connect anyway, and perhaps remember
the certificate and not ask again (TOFU).

We don't actually have such functionality today; you can query the
OpenSSL structs for those things, but the checks that libpq performs are
not exactly the same that OpenSSL does. We have our own function to
check if a wildcard cert matches a hostname, for example, and libpq
knows that "host" and "hostaddr" can be different. So this would
actually be a new feature, probably best to be implemented as a separate
patch. (I grabbed the idea for those attributes from Martijn's ancient
gnutls patch.)

Exposing the SSL information as generic key/value pairs allows
adding more attributes in the future, without breaking the ABI, and
it also allows exposing implementation-specific information in a
generic way. The attributes listed above cover the needs of psql.
What else do we need?

At first blush, I'd say a whole bunch.. Off the top of my head I can
think of:

For all certificates:
(client, server, cert that signed each, any intermediate CAs, root CAs)
Certificate itself (perhaps in DER, PEM, X509 formats..)
Fingerprint
Signed-By info
Common Name
Organization (et al)
Alternate names
Issue date, expiration date
CRL info, OCSP info
Allowed usage (encryption, signing, etc)

Hmm. That seems a bit too much. Perhaps provide just the certificate
itself in DER/PEM format, and have the client parse it (using OpenSSL or
something else) if it wants more details.

CRL checking done?

I guess, although you know implicitly that it was if the sslcrl option
was given.

OCSP used?

We don't support OCSP.

I think it would also be nice to get more information from the
server's certificate, like the hostname and the organization its
issued to, and expiration date, so that an interactive client like
pgAdmin or even psql could display that information like a web
browser does. Would it be best to add those as extra attributes in
the above list, perhaps with a "server_cert_*" prefix, or add a new
function for extracting server cert's attributes?

This really shouldn't be for *just* the server's certificate but rather
available for all certificates involved- on both sides.

Ok, but why? All the other stuff is readily available in the
configuration you use to connect. I guess it doesn't hurt to expose them
through this interface as well, but I can't immediately think of an
example that would use them.

Have you looked at how this change will play out with the ODBC driver..?
Especially on Windows with the SSL library you're proposing we use
there.. I recall that at one point the ODBC driver simply used libpq to
handle the authentication and set everything up, and then switched to
talking directly without libpq. In any case, it'd probably be good to
make sure the attributes you're suggesting are sufficient to meet the
needs of the ODBC driver too.

Indeed, the ODBC driver only uses libpq for authentication, then calls
PQgetssl(), and takes over the whole show calling SSL_read() and
SSL_write() itself. Ideally, we'd modify psqlodbc to stop doing that,
but that's not an easy job. In the short-term, I think we need to export
pqsecure_read() and pqsecure_write() functions in libpq, so that the
ODBC driver can use those instead of SSL_read() and SSL_write().

- Heikki

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

On 2014-08-19 11:05:07 -0400, Stephen Frost wrote:

* Andres Freund (andres@2ndquadrant.com) wrote:

On 2014-08-19 10:48:41 -0400, Stephen Frost wrote:

At first blush, I'd say a whole bunch.. Off the top of my head I can
think of:

[...]

I'm not really sure we need all that. We're not building a general ssl
library abstraction here.

Really? I'm pretty sure that's exactly what we're doing.

No. We should build something that's suitable for postgres, not
something general. We'll fail otherwise. For anything fancy the user has
to look at the certificate themselves. We should make it easy to get at
the whole certificate chain in a consistent manner.

Telling users they simply can't have this information isn't
acceptable.

Meh. Why? Most of that isn't something a normal libpq user is going to
need.

What I'm wondering is whether we should differentiate 'standard'
attributes that we require from ones that a library can supply
optionally. If we don't we'll have difficulty enlarging the 'standard'
set over time.

If we end up not being able to provide everything for all of the
libraries we support then perhaps we can document which are available
from all of them, but I'd hope the list of "only in X" is pretty small.

I'm pretty sure that we can't build a reasonable list of the information
exposed by any library. Especially as we're likely going to need some
mapping to agree to map to the common names.

I'd just go for plain names for standard attributes and X-$library- for library
specific stuff.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, 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

* Heikki Linnakangas (hlinnakangas@vmware.com) wrote:

I think it would be nice to be able to query those attributes
explicitly, rather than just expect libpq to reject the connection
if something's wrong. For example, I'm thinking that an interactive
client might present an annoying pop-up window to the user if the
server cert is not valid, asking if he wants to connect anyway, and
perhaps remember the certificate and not ask again (TOFU).

Alright, I could see that being useful, though as you say, it'd really
be new functionality.

Hmm. That seems a bit too much. Perhaps provide just the certificate
itself in DER/PEM format, and have the client parse it (using
OpenSSL or something else) if it wants more details.

I really don't care for that approach. Our SSL support has always been
horrible- I was hoping we'd actually improve that situation. Adding
things in piecemeal over time will just be painful for our users and I
don't see why we should wait.

OCSP used?

We don't support OCSP.

Another thing that we really should address (actually- can't you enable
it in OpenSSL directly? I seem to recall something along those lines
anyway, though it's been quite a few years now).

This really shouldn't be for *just* the server's certificate but rather
available for all certificates involved- on both sides.

Ok, but why? All the other stuff is readily available in the
configuration you use to connect. I guess it doesn't hurt to expose
them through this interface as well, but I can't immediately think
of an example that would use them.

For starters, certificates can be passed between the client and the
server to complete the chain, so I don't see how it's "readily
available", not to mention that even if the location of the certs was in
simple files locally, the application would need to bring in their own
library to parse and extract out this information, which we've
more-or-less already got.

Indeed, the ODBC driver only uses libpq for authentication, then
calls PQgetssl(), and takes over the whole show calling SSL_read()
and SSL_write() itself. Ideally, we'd modify psqlodbc to stop doing
that, but that's not an easy job. In the short-term, I think we need
to export pqsecure_read() and pqsecure_write() functions in libpq,
so that the ODBC driver can use those instead of SSL_read() and
SSL_write().

Yeah, that's what I remembered. There was an attempt to make that
change at one point, but it was reverted due to the lack of batching
ability in libpq (without resorting to cursors, as I recall...),
requiring double the memory usage. Still, if pqsecure_read and
pqsecure_write are sufficient to make the ODBC driver work, that's good
news. I had been worried it did other things with the OpenSSL struct
beyond just using those.

Thanks,

Stephen

* Andres Freund (andres@2ndquadrant.com) wrote:

No. We should build something that's suitable for postgres, not
something general. We'll fail otherwise. For anything fancy the user has
to look at the certificate themselves. We should make it easy to get at
the whole certificate chain in a consistent manner.

I don't buy this argument at all.

Telling users they simply can't have this information isn't
acceptable.

Meh. Why? Most of that isn't something a normal libpq user is going to
need.

I'm not interested in SSL support for users who don't use or care about
SSL (which would be 'normal libpq users', really). I've *long* been
frustrated by our poor support of SSL and at how painful it is to get
proper SSL working- and it's been a real problem getting PG to pass the
security compliance requirements because of that poor support. Let's
stop the rhetoric that PG doesn't need anything but the most basic
SSL/auditing/security capabilities.

If we end up not being able to provide everything for all of the
libraries we support then perhaps we can document which are available
from all of them, but I'd hope the list of "only in X" is pretty small.

I'm pretty sure that we can't build a reasonable list of the information
exposed by any library. Especially as we're likely going to need some
mapping to agree to map to the common names.

Per Apache's documentation, mod_ssl and mod_gnutls support the same set
of environment variables (with the same names even), so I don't buy this
argument either.

Thanks,

Stephen

On 2014-08-19 11:52:37 -0400, Stephen Frost wrote:

* Andres Freund (andres@2ndquadrant.com) wrote:

No. We should build something that's suitable for postgres, not
something general. We'll fail otherwise. For anything fancy the user has
to look at the certificate themselves. We should make it easy to get at
the whole certificate chain in a consistent manner.

I don't buy this argument at all.

Aha.

Telling users they simply can't have this information isn't
acceptable.

Meh. Why? Most of that isn't something a normal libpq user is going to
need.

I'm not interested in SSL support for users who don't use or care about
SSL (which would be 'normal libpq users', really).

That's the majority of our users. Even those that care about ssl care
about setting it up in a safe manner, won't care about most of the
attributes.

I have no problem to expand the list of attributes once we have a couple
of differing backends for the support, but having a long list of things
that need to be supported by every one just makes getting there harder.

I've *long* been
frustrated by our poor support of SSL and at how painful it is to get
proper SSL working- and it's been a real problem getting PG to pass the
security compliance requirements because of that poor support. Let's
stop the rhetoric that PG doesn't need anything but the most basic
SSL/auditing/security capabilities.

I've no problem with keeping future extensions of the API in mind while
this is being designed. We just shouldn't start too big. This is about
getting a proper abstraction in place, not making pg pass security
compliance stuff. Don't mix those too much.

If we end up not being able to provide everything for all of the
libraries we support then perhaps we can document which are available
from all of them, but I'd hope the list of "only in X" is pretty small.

I'm pretty sure that we can't build a reasonable list of the information
exposed by any library. Especially as we're likely going to need some
mapping to agree to map to the common names.

Per Apache's documentation, mod_ssl and mod_gnutls support the same set
of environment variables (with the same names even), so I don't buy this
argument either.

Gnutls is quite similar from what it provides to openssl. That's not
saying much. Schannel would be more interesting from that point of view.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, 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

Stephen Frost wrote:

* Heikki Linnakangas (hlinnakangas@vmware.com) wrote:

Indeed, the ODBC driver only uses libpq for authentication, then
calls PQgetssl(), and takes over the whole show calling SSL_read()
and SSL_write() itself. Ideally, we'd modify psqlodbc to stop doing
that, but that's not an easy job. In the short-term, I think we need
to export pqsecure_read() and pqsecure_write() functions in libpq,
so that the ODBC driver can use those instead of SSL_read() and
SSL_write().

Yeah, that's what I remembered. There was an attempt to make that
change at one point, but it was reverted due to the lack of batching
ability in libpq (without resorting to cursors, as I recall...),
requiring double the memory usage. Still, if pqsecure_read and
pqsecure_write are sufficient to make the ODBC driver work, that's good
news. I had been worried it did other things with the OpenSSL struct
beyond just using those.

Um, libpq has recently gained the ability to return result fragments,
right? Those didn't exist when libpq-ification of odbc was attempted,
as I recall -- perhaps it's possible now.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, 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

* Andres Freund (andres@2ndquadrant.com) wrote:

Per Apache's documentation, mod_ssl and mod_gnutls support the same set
of environment variables (with the same names even), so I don't buy this
argument either.

Gnutls is quite similar from what it provides to openssl. That's not
saying much. Schannel would be more interesting from that point of view.

Fine- but let's at least start with what two of the three support and
figure out if there's actually an issue getting this information from
Schannel. I'd be surprised if there really is, but I'm a lot happier
starting with a larger set and then considering if we can live without
certain things than trying to build up one-by-one over major releases.

Thanks,

Stephen

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:

Stephen Frost wrote:

Yeah, that's what I remembered. There was an attempt to make that
change at one point, but it was reverted due to the lack of batching
ability in libpq (without resorting to cursors, as I recall...),
requiring double the memory usage. Still, if pqsecure_read and
pqsecure_write are sufficient to make the ODBC driver work, that's good
news. I had been worried it did other things with the OpenSSL struct
beyond just using those.

Um, libpq has recently gained the ability to return result fragments,
right? Those didn't exist when libpq-ification of odbc was attempted,
as I recall -- perhaps it's possible now.

I was trying to remember off-hand if we still had that or not.. I
thought there was discussion about removing it, actually, but perhaps
that was something else.

I agree that having that would definitely help with the ODBC driver.

Thanks,

Stephen

On 08/19/2014 06:44 PM, Stephen Frost wrote:

Hmm. That seems a bit too much. Perhaps provide just the certificate
itself in DER/PEM format, and have the client parse it (using
OpenSSL or something else) if it wants more details.

I really don't care for that approach. Our SSL support has always been
horrible- I was hoping we'd actually improve that situation. Adding
things in piecemeal over time will just be painful for our users and I
don't see why we should wait.

What would you like to do with the certificates?

I'm imagining that a GUI tool like pgAdmin might want to extract all
information from the certificate, display it in a window, and let the
user look at the whole chain and all the fields. Like a browser does
when you click the little lock icon in the address bar. That would be a
nice feature, but it's a huge effort to expose *all* certificate
information through attributes, especially if you want to support
multiple SSL libraries. If there was a generic "get attribute X"
interface in OpenSSL and all the other SSL libraries we wish to support,
we could provide a pass-through mechanism for that, so that e.g all
attributes that OpenSSL exposes were mapped to "server_cert_*". But I
don't think that exists in OpenSSL, let alone in other libraries, and
the attribute names would be all different anyway.

So that's not really feasible.

But if we provide an interface to grab the whole certificate chain, then
you can use any library you want to parse and present it to the user.
You could use OpenSSL, but you could also use a more light-weight parser
like libtasn1, or if you're writing a python app for example, whatever
x509 certificate handling library they have. You wouldn't be *verifying*
the certificates - that's handled by libpq (or rather, the SSL library
that libpq uses) - so no cryptography required.

Or you could just pass the whole cert to a 3rd party program
specifically written to display x509 certificates, and let it do the
parsing. I'll mention that the Windows Crypto API has a built-in
function called CryptUIDlgViewCertificate that pops up a dialog for
viewing the certificate. Very handy. I think it's the same dialog that
Internet Explorer uses.

If you want to write such a GUI from scratch, anyway, I think you would
be better off to *not* rely on libpq functions, so that you could use
the same GUI in other contexts too. Like to view an arbitrary
certificate file on the filesystem.

That said, if there's a need to extract some specific fields for some
other purpose than displaying the whole certificate to the user, let's
hear it.

- Heikki

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

On 08/19/2014 07:10 PM, Alvaro Herrera wrote:

Stephen Frost wrote:

* Heikki Linnakangas (hlinnakangas@vmware.com) wrote:

Indeed, the ODBC driver only uses libpq for authentication, then
calls PQgetssl(), and takes over the whole show calling SSL_read()
and SSL_write() itself. Ideally, we'd modify psqlodbc to stop doing
that, but that's not an easy job. In the short-term, I think we need
to export pqsecure_read() and pqsecure_write() functions in libpq,
so that the ODBC driver can use those instead of SSL_read() and
SSL_write().

Yeah, that's what I remembered. There was an attempt to make that
change at one point, but it was reverted due to the lack of batching
ability in libpq (without resorting to cursors, as I recall...),
requiring double the memory usage. Still, if pqsecure_read and
pqsecure_write are sufficient to make the ODBC driver work, that's good
news. I had been worried it did other things with the OpenSSL struct
beyond just using those.

Um, libpq has recently gained the ability to return result fragments,
right? Those didn't exist when libpq-ification of odbc was attempted,
as I recall -- perhaps it's possible now.

IIRC the thing that psqlodbc does that libpq doesn't support is sending
multiple queries to the backend, and then wait for *all* the replies to
arrive, in a single round-trip. The closest thing is using PQexec("foo;
bar;"), but that's quite limited.

- Heikki

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

Stephen Frost <sfrost@snowman.net> writes:

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:

Um, libpq has recently gained the ability to return result fragments,
right? Those didn't exist when libpq-ification of odbc was attempted,
as I recall -- perhaps it's possible now.

I was trying to remember off-hand if we still had that or not.. I
thought there was discussion about removing it, actually, but perhaps
that was something else.

Sure,
http://www.postgresql.org/docs/devel/static/libpq-single-row-mode.html
That's a done deal, it won't be going away.

Whether it would solve ODBC's problem I don't know (and I'm not
volunteering to do the work ;-))

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 08/19/2014 06:52 PM, Stephen Frost wrote:

* Andres Freund (andres@2ndquadrant.com) wrote:

No. We should build something that's suitable for postgres, not
something general. We'll fail otherwise. For anything fancy the user has
to look at the certificate themselves. We should make it easy to get at
the whole certificate chain in a consistent manner.

I don't buy this argument at all.

Telling users they simply can't have this information isn't
acceptable.

Meh. Why? Most of that isn't something a normal libpq user is going to
need.

I'm not interested in SSL support for users who don't use or care about
SSL (which would be 'normal libpq users', really). I've *long* been
frustrated by our poor support of SSL and at how painful it is to get
proper SSL working- and it's been a real problem getting PG to pass the
security compliance requirements because of that poor support. Let's
stop the rhetoric that PG doesn't need anything but the most basic
SSL/auditing/security capabilities.

I think you just packed up the goalposts for a one-way trip to Mars, but
I wonder: What would you consider "proper SSL support"? What exactly are
we missing?

- Heikki

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