PQgetssl() and alternative SSL implementations
In order to support alternatives to OpenSSL, we need to wean off
applications from using PQgetssl(). To do that, we have to provide an
alternative API to get the same information. PQgetSSL() returns a
pointer directly to the OpenSSL private struct, and you can do anything
with that. We cannot have a generic interface that exposes everything,
so we need to identify the information that people actually want, and
expose that.
In the ancient patch that Martijn posted for this back in 2006 (*), he
added a new libpq function called PQgettlsinfo, which returned all
attributes the SSL implementation exposes as a result set with two
columns, key and value. I think that was a bit awkward - a caller that's
interested in a specific attribute would need to iterate through the
result set to find the one its looking for. And some of the values might
be somewhat expensive to calculate - e.g. extracting some attribute of
the server certificate - so it would be better to only calculate the
attributes that are actually needed.
I propose two functions like this:
-------
const char *
PQsslAttribute(const PGconn *conn, const char *attributeName)
Look up an attribute with the given name. Returns NULL if no attribute
with that name is found.
The following common attributes are available:
library: name of the SSL implementation used. Currently always
"OpenSSL", or NULL if not compiled with SSL support.
active: Is the current connection using SSL? "yes" or "no" (note that
"yes" does not necessarily mean that the connection is secure, e.g. if
the null-cipher is used)
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"
compression: Is SSL compression is in use, returns the name of the
compression algorithm, or "yes" if compression is used but the algorithm
is not known. If compression is not enabled, returns "no".
The following standard attributes are available to get more information
on the ciphersuite. Note that an SSL implementation may not provide all
the attributes:
protocol: SSL/TLS version in use. Common values are "SSLv2", "SSLv3",
"TLSv1", "TLSv1.1" and "TLSv1.2", but an implementation may return other
strings if some other protocol is used.
cipher: a short name of the ciphersuite used, e.g.
"DHE-RSA-DES-CBC3-SHA". The names are specific to each SSL implementation.
key_bits: number of key bits used by the encryption algorithm.
An implementation may provide any number of additional,
implementation-specific attributes.
Although the returned pointer is declared const, it in fact points to
mutable storage associated with the PGconn structure. It is unwise to
assume the pointer will remain valid across queries.
const char **
PQsslListAttributes(const PGconn *conn)
Return an array of SSL attribute names available. The array is
terminated by a NULL pointer. Use PQsslAttribute to get the value of an
attribute.
-------
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?
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?
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.
(*) /messages/by-id/20060504134807.GK4752@svana.org
- 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 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.htmlI 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
On 08/19/2014 06:00 PM, Magnus Hagander wrote:
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.
Hmm, right, because the client application doesn't get control between
libpq doing the SSL negotiation and sending the password to the server.
So if after connecting you decided that you don't actually trust the
server, you've already sent to password. Not good.
You might think that you could try connecting without password first,
and try again with the password, but that's not safe either, because
there's no guarantee that the second connection reaches the same server
as the first one.
I think we need a callback or new asynchronous polling state after SSL
negotiation but before libpq sends the password to the server. But
that's a separate feature and patch.
- Heikki
--
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 (tgl@sss.pgh.pa.us) wrote:
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.
Ugh. Yes, there's single-row mode, but I had been thinking there was a
'batch' mode available ala what OCI8 had, where you'd allocate a chunk
of memory and then have it filled directly by the library as rows came
back in until it was full (there was a similar 'bulk send' operation, as
I recall). Perhaps it was the 'pipelining' thread that I was thinking
about. Not really relevant, in any case.
Whether it would solve ODBC's problem I don't know (and I'm not
volunteering to do the work ;-))
It could work.. though it's certainly been a while since I looked at
the ODBC internals.
Thanks,
Stephen
On Mon, Aug 18, 2014 at 7:54 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
In order to support alternatives to OpenSSL, we need to wean off
applications from using PQgetssl(). To do that, we have to provide an
alternative API to get the same information. PQgetSSL() returns a pointer
directly to the OpenSSL private struct, and you can do anything with that.
We cannot have a generic interface that exposes everything, so we need to
identify the information that people actually want, and expose that.
I have a hard time believing that something like this will really
satisfy anyone. Why not just add PQgetSchannelHandleOrWhatever() and
call it good? We can try to be incredibly thorough in exposing the
information people want and we will still inevitably miss something
that someone cares about; worse, we'll spend an awful lot of time and
energy along the way.
--
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 Tue, Aug 19, 2014 at 8:49 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Aug 18, 2014 at 7:54 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:In order to support alternatives to OpenSSL, we need to wean off
applications from using PQgetssl(). To do that, we have to provide an
alternative API to get the same information. PQgetSSL() returns a pointer
directly to the OpenSSL private struct, and you can do anything with that.
We cannot have a generic interface that exposes everything, so we need to
identify the information that people actually want, and expose that.I have a hard time believing that something like this will really
satisfy anyone. Why not just add PQgetSchannelHandleOrWhatever() and
call it good? We can try to be incredibly thorough in exposing the
information people want and we will still inevitably miss something
that someone cares about; worse, we'll spend an awful lot of time and
energy along the way.
Well, for one you push the full burden onto the application. Then
every application has to support every SSL library we do, even for the
simplest check. And it has to be built against the same one. (So for
example if someone wants to use openssl on windows - yes there might
still be reasons for that even if we support schannel - they have to
rebuild every one of their applications. And every one of their higher
level language drivers sitting on top of openssl).
The same problem of course appears on say Linux, if you end up using a
mix of openssl and gnutls or a mix of nss and openssl for example.
It's not likely to happen as long as you only use the officially built
packages, but you're likely in for quite a bit of pain if you are
using any non-standard packaging like the oneclick installers etc.
--
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> writes:
On Tue, Aug 19, 2014 at 8:49 PM, Robert Haas <robertmhaas@gmail.com> wrote:
I have a hard time believing that something like this will really
satisfy anyone. Why not just add PQgetSchannelHandleOrWhatever() and
call it good? We can try to be incredibly thorough in exposing the
information people want and we will still inevitably miss something
that someone cares about; worse, we'll spend an awful lot of time and
energy along the way.
Well, for one you push the full burden onto the application.
Robert's got a point though: there is always going to be somebody who
wants something we fail to expose. It's better to be able to say "well,
you can do PQgetssl and then munge it for yourself" than to have to say
"sorry, you're screwed". So if we're going to define PQgetssl as
returning NULL when you're not using OpenSSL, I don't see why we
shouldn't expose a similarly-defined PQgetXXX for each other underlying
implementation we support. There will not be that many of 'em, and
I suspect the people with very specific needs will not care about more
than one underlying library anyway.
This does not say that we shouldn't also try to have some
library-independent functionality for interrogating certificate state
etc. Just that having an escape hatch isn't a bad thing.
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 Tue, Aug 19, 2014 at 9:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Tue, Aug 19, 2014 at 8:49 PM, Robert Haas <robertmhaas@gmail.com> wrote:
I have a hard time believing that something like this will really
satisfy anyone. Why not just add PQgetSchannelHandleOrWhatever() and
call it good? We can try to be incredibly thorough in exposing the
information people want and we will still inevitably miss something
that someone cares about; worse, we'll spend an awful lot of time and
energy along the way.Well, for one you push the full burden onto the application.
Robert's got a point though: there is always going to be somebody who
wants something we fail to expose. It's better to be able to say "well,
you can do PQgetssl and then munge it for yourself" than to have to say
"sorry, you're screwed". So if we're going to define PQgetssl as
returning NULL when you're not using OpenSSL, I don't see why we
shouldn't expose a similarly-defined PQgetXXX for each other underlying
implementation we support. There will not be that many of 'em, and
I suspect the people with very specific needs will not care about more
than one underlying library anyway.This does not say that we shouldn't also try to have some
library-independent functionality for interrogating certificate state
etc. Just that having an escape hatch isn't a bad thing.
I do agree tha thaving both would be useful. We could have something like
int PQgetSSLstruct(void **sslstruct)
which returns the type of struct. Then it's up to the application to
know if it can handle it. For those apps that need a *lot*. But the
basic attributes - something like the list from apache - should be
retrievable in a library independent way.
--
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
* Heikki Linnakangas (hlinnakangas@vmware.com) wrote:
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?
In applications which I've developed in the past, I've had to rely on
the CN, serial number, and signing root CA to ensure that there were no
duplicates (this was a government environment which trusted multiple
independent root CAs, and there was no guarantee that even a given CA
wouldn't issue the same serial number to different individuals). In
other cases, I've had to rely on the fingerprint, but that gets painful
when you have certificate roll-over since you then have to re-enroll
individuals when they get issued a new certificate. I've also
implemented systems which have certificate expiration warnings.
Checking the extended attributes of the certificate has been a
requirement in the past (to verify it's only being used for its intended
purpose).
One of the things we don't support today is anything beyond matching on
the CN of the certificate in pg_ident, to map from a client certificate
to a PG role. That wouldn't be acceptable in environments I've worked
in because two different individuals could have identical CNs. Another
interesting twist are systems (such as Windows..) where the client
certificate to be presented depends on which root CA the server's
certificate is signed with.
I'm not asking this patch to fix that, but you asked what else a
developer might be looking for when it comes to SSL and I'm telling you
things I've actively used. Generally speaking, these have been on the
server side (eg: with mod_ssl), but I could see a client wanting to use
them, and if we abstract getting this information on the server side to
meet the needs I've described above, wouldn't we be able to (and want
to) share that abstraction with users of libpq?
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.
While that'd certainly be nice, it's not what I'm referring to and I
agree that having a third party library to handle that makes sense, as
some operating systems do. In general, I'm all for more (and better)
integration with the OS-provided certificate systems. For one thing,
they also can address the issues around ensuring that the client side
certificate is encrypted-at-rest, and can handle prompting the user for
the passphrase to decrypt it.
But I don't think that exists in OpenSSL, let alone
in other libraries, and the attribute names would be all different
anyway.
As I said- let's look at mod_ssl/gnutls as a minimum set to start with..
That's certainly a set I'm familiar with and one which I expect most
other developers who work with SSL are also. There are bits missing
from that list (mainly around the extended attributes..), but it's
certainly better than the list originally proposed.
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.
Yes- we should do this also because there may be cases where the app
developers wants to pass that off to another library or do something
else with it, sure.
Thanks,
Stephen
* Heikki Linnakangas (hlinnakangas@vmware.com) wrote:
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?
I hit on a few things in my other email, but there is a huge portion of
SSL which is just about making it easy and sensible to install and get
working properly. Apache is a good example of how to do this and is one
that a lot of people are familiar with. Specific issues that I recall
running into are lack of the 'directory' options for certificates,
having trouble figuring out the right format and structure to provide
the complete root chain for the server's certificate and then trying to
figure out how to add intermediate and additional root CAs for client
certificates, getting CRLs to work was a pain, and nothing about how to
get OCSP working.
I think there's been some improvement since I last had to go through the
pain of setting this all up, and some of it is undoubtably OpenSSL's
fault, but there's definitely quite a bit more we could be doing to make
SSL support easier. I'm hopeful that I'll be able to spend more time on
this in the future but it's not a priority currently.
Thanks,
Stephen
On Tue, Aug 19, 2014 at 3:16 PM, Magnus Hagander <magnus@hagander.net> wrote:
On Tue, Aug 19, 2014 at 9:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Tue, Aug 19, 2014 at 8:49 PM, Robert Haas <robertmhaas@gmail.com> wrote:
I have a hard time believing that something like this will really
satisfy anyone. Why not just add PQgetSchannelHandleOrWhatever() and
call it good? We can try to be incredibly thorough in exposing the
information people want and we will still inevitably miss something
that someone cares about; worse, we'll spend an awful lot of time and
energy along the way.Well, for one you push the full burden onto the application.
Robert's got a point though: there is always going to be somebody who
wants something we fail to expose. It's better to be able to say "well,
you can do PQgetssl and then munge it for yourself" than to have to say
"sorry, you're screwed". So if we're going to define PQgetssl as
returning NULL when you're not using OpenSSL, I don't see why we
shouldn't expose a similarly-defined PQgetXXX for each other underlying
implementation we support. There will not be that many of 'em, and
I suspect the people with very specific needs will not care about more
than one underlying library anyway.This does not say that we shouldn't also try to have some
library-independent functionality for interrogating certificate state
etc. Just that having an escape hatch isn't a bad thing.I do agree tha thaving both would be useful. We could have something like
int PQgetSSLstruct(void **sslstruct)
I think it's likely smarter to have totally separate functions.
First, to make it less likely that users will try to use a pointer to
one type of object as a pointer to some other kind of object. And
second, because you might, for example, someday have an SSL
implementation that wants to return two pointers. May as well make
that kind of thing easy.
BTW, if we're beating on libpq, I wonder if we shouldn't consider
bumping the soversion at some point. I mean, I know that we
technically don't need to do that if we're only *adding* functions and
not changing any of the existing stuff in backward-incompatible ways,
but we might *want* to make some backward-incompatible changes at some
point, and I think there's a decent argument that any patch in this
are is already doing that at least to PQgetSSL(). Maybe this would be
a good time to think if there's anything else we want to do that
would, either by itself or in combination, justify a bump.
--
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) wrote:
BTW, if we're beating on libpq, I wonder if we shouldn't consider
bumping the soversion at some point. I mean, I know that we
technically don't need to do that if we're only *adding* functions and
not changing any of the existing stuff in backward-incompatible ways,
but we might *want* to make some backward-incompatible changes at some
point, and I think there's a decent argument that any patch in this
are is already doing that at least to PQgetSSL(). Maybe this would be
a good time to think if there's anything else we want to do that
would, either by itself or in combination, justify a bump.
I'm not a big fan of doing it for this specific item, though it's
technically an API breakage (which means we should actually have
libpq2-dev packages, make everything that build-deps on libpq-dev
update to build-dep on libpq2-dev, have libpq6, etc..). If there are
other backwards-incompatible things we wish to do, then I agree that
it'd be good to do them all at the same time (perhaps in conjunction
with 10.0...). This is the part where I wish we had been keeping an
updated list of things we want to change (like on the wiki..).
It's certainly not a fun transistion to go through. I also wonder if
we're going to need to worry about what happens when libpq5 and libpq6
end up linked into the same running application. I don't think we
have any symbol versioning or anything to address that risk in place..
Thanks,
Stephen
On 08/19/2014 10:31 PM, Robert Haas wrote:
On Tue, Aug 19, 2014 at 3:16 PM, Magnus Hagander <magnus@hagander.net> wrote:
On Tue, Aug 19, 2014 at 9:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Tue, Aug 19, 2014 at 8:49 PM, Robert Haas <robertmhaas@gmail.com> wrote:
I have a hard time believing that something like this will really
satisfy anyone. Why not just add PQgetSchannelHandleOrWhatever() and
call it good? We can try to be incredibly thorough in exposing the
information people want and we will still inevitably miss something
that someone cares about; worse, we'll spend an awful lot of time and
energy along the way.Well, for one you push the full burden onto the application.
Robert's got a point though: there is always going to be somebody who
wants something we fail to expose. It's better to be able to say "well,
you can do PQgetssl and then munge it for yourself" than to have to say
"sorry, you're screwed". So if we're going to define PQgetssl as
returning NULL when you're not using OpenSSL, I don't see why we
shouldn't expose a similarly-defined PQgetXXX for each other underlying
implementation we support. There will not be that many of 'em, and
I suspect the people with very specific needs will not care about more
than one underlying library anyway.This does not say that we shouldn't also try to have some
library-independent functionality for interrogating certificate state
etc. Just that having an escape hatch isn't a bad thing.
Yeah, wouldn't hurt I guess.
I do agree tha thaving both would be useful. We could have something like
int PQgetSSLstruct(void **sslstruct)I think it's likely smarter to have totally separate functions.
First, to make it less likely that users will try to use a pointer to
one type of object as a pointer to some other kind of object. And
second, because you might, for example, someday have an SSL
implementation that wants to return two pointers. May as well make
that kind of thing easy.
The struct it returns is totally SSL-implementation specific anyway, so
for an implementation that would like to return two structs, you could
well define it to return a struct like:
struct {
CoolStructA *a;
CoolStructB *b;
} CoolSSLStruct;
I don't much like adding a separate function for every SSL
implementation, but you've got a point that it would be nice to make it
difficult to call PQgetSSLstruct() and just assume that the returned
struct is e.g an OpenSSL struct, while it's actually something else.
Perhaps:
int PQgetSSLstruct(void **sslstruct, char *structname)
You'd call it like PQgetSSLStruct(&mystruct, "openssl"), and it checks
that the argument matches the library actually been used, otherwise it
returns an error. And if you need to return two structs, you'd call it
twice: PQgetSSLStruct(&a, "cool_a") and PQgetSSLStruct(&b, "cool_b").
- 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-20 00:58:22 +0300, Heikki Linnakangas wrote:
I don't much like adding a separate function for every SSL implementation,
but you've got a point that it would be nice to make it difficult to call
PQgetSSLstruct() and just assume that the returned struct is e.g an OpenSSL
struct, while it's actually something else. Perhaps:
A good reason to not have functions with the respective functions is
that it requires either including the relevant headers or adding forward
declarations of the libraries type.
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
Andres Freund <andres@2ndquadrant.com> writes:
On 2014-08-20 00:58:22 +0300, Heikki Linnakangas wrote:
I don't much like adding a separate function for every SSL implementation,
but you've got a point that it would be nice to make it difficult to call
PQgetSSLstruct() and just assume that the returned struct is e.g an OpenSSL
struct, while it's actually something else. Perhaps:
A good reason to not have functions with the respective functions is
that it requires either including the relevant headers or adding forward
declarations of the libraries type.
It requires no such thing. What we do for PQgetssl() is declare it as
returning "void *", and we could easily do the same for other libraries.
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 2014-08-19 19:11:46 -0400, Tom Lane wrote:
Andres Freund <andres@2ndquadrant.com> writes:
On 2014-08-20 00:58:22 +0300, Heikki Linnakangas wrote:
I don't much like adding a separate function for every SSL implementation,
but you've got a point that it would be nice to make it difficult to call
PQgetSSLstruct() and just assume that the returned struct is e.g an OpenSSL
struct, while it's actually something else. Perhaps:A good reason to not have functions with the respective functions is
that it requires either including the relevant headers or adding forward
declarations of the libraries type.It requires no such thing. What we do for PQgetssl() is declare it as
returning "void *", and we could easily do the same for other libraries.
Well, the reason the library specific variant has been called superiour
upthread is the potential for type safety...
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 03:26:56PM -0400, Stephen Frost wrote:
I think there's been some improvement since I last had to go through the
pain of setting this all up, and some of it is undoubtably OpenSSL's
fault, but there's definitely quite a bit more we could be doing to make
SSL support easier. I'm hopeful that I'll be able to spend more time on
this in the future but it's not a priority currently.
I know I updated the docs on this in 2013:
commit fa4add50c4ea97c48881fa8cb3863df80141643c
Author: Bruce Momjian <bruce@momjian.us>
Date: Fri Dec 6 09:42:08 2013 -0500
docs: clarify SSL certificate authority chain docs
Previously, the requirements of how intermediate certificates were
handled and their chain to root certificates was unclear.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
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 03:47:17PM -0400, Stephen Frost wrote:
* Robert Haas (robertmhaas@gmail.com) wrote:
BTW, if we're beating on libpq, I wonder if we shouldn't consider
bumping the soversion at some point. I mean, I know that we
technically don't need to do that if we're only *adding* functions and
not changing any of the existing stuff in backward-incompatible ways,
but we might *want* to make some backward-incompatible changes at some
point, and I think there's a decent argument that any patch in this
are is already doing that at least to PQgetSSL(). Maybe this would be
a good time to think if there's anything else we want to do that
would, either by itself or in combination, justify a bump.I'm not a big fan of doing it for this specific item, though it's
technically an API breakage (which means we should actually have
libpq2-dev packages, make everything that build-deps on libpq-dev
update to build-dep on libpq2-dev, have libpq6, etc..). If there are
other backwards-incompatible things we wish to do, then I agree that
it'd be good to do them all at the same time (perhaps in conjunction
with 10.0...). This is the part where I wish we had been keeping an
updated list of things we want to change (like on the wiki..).
We have, called "Wire Protocol Changes":
https://wiki.postgresql.org/wiki/Todo
Unfortunately, the subsection link doesn't work on Firefox.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
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/20/2014 12:58 AM, Heikki Linnakangas wrote:
On 08/19/2014 10:31 PM, Robert Haas wrote:
On Tue, Aug 19, 2014 at 3:16 PM, Magnus Hagander <magnus@hagander.net> wrote:
On Tue, Aug 19, 2014 at 9:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert's got a point though: there is always going to be somebody who
wants something we fail to expose. It's better to be able to say "well,
you can do PQgetssl and then munge it for yourself" than to have to say
"sorry, you're screwed". So if we're going to define PQgetssl as
returning NULL when you're not using OpenSSL, I don't see why we
shouldn't expose a similarly-defined PQgetXXX for each other underlying
implementation we support. There will not be that many of 'em, and
I suspect the people with very specific needs will not care about more
than one underlying library anyway.This does not say that we shouldn't also try to have some
library-independent functionality for interrogating certificate state
etc. Just that having an escape hatch isn't a bad thing.Yeah, wouldn't hurt I guess.
I do agree tha thaving both would be useful. We could have something like
int PQgetSSLstruct(void **sslstruct)I think it's likely smarter to have totally separate functions.
First, to make it less likely that users will try to use a pointer to
one type of object as a pointer to some other kind of object. And
second, because you might, for example, someday have an SSL
implementation that wants to return two pointers. May as well make
that kind of thing easy.The struct it returns is totally SSL-implementation specific anyway, so
for an implementation that would like to return two structs, you could
well define it to return a struct like:struct {
CoolStructA *a;
CoolStructB *b;
} CoolSSLStruct;I don't much like adding a separate function for every SSL
implementation, but you've got a point that it would be nice to make it
difficult to call PQgetSSLstruct() and just assume that the returned
struct is e.g an OpenSSL struct, while it's actually something else.
Perhaps:int PQgetSSLstruct(void **sslstruct, char *structname)
You'd call it like PQgetSSLStruct(&mystruct, "openssl"), and it checks
that the argument matches the library actually been used, otherwise it
returns an error. And if you need to return two structs, you'd call it
twice: PQgetSSLStruct(&a, "cool_a") and PQgetSSLStruct(&b, "cool_b").
Here's a patch to implement the above scheme. It adds four functions to
libpq, to interrogate the SSL status:
int PQsslInUse(const PGconn *conn)
Returns true (1) if the connection uses SSL, false (0) if not.
const char *PQsslAttribute(const PGconn *conn, const char *attribute_name)
Returns a piece of information. The list of attributes depends on the
implementation, but there are a few that are expected to be supported by
all of them. See docs for details.
const char **PQsslAttributes(const PGconn *conn);
Return an array of SSL attribute names available.
void *PQsslStruct(const PGconn *conn, const char *struct_name)
Return a pointer to an SSL-implementation specific object describing the
connection. PQsslStruct(conn, "OpenSSL SSL") is equivalent to
PQgetssl(conn).
I think this is expandable enough, because you can easily add attributes
later on, and different implementations can support different
attributes. It contains the escape hatch for applications that need to
do more, and have intimate knowledge of OpenSSL structs. It's also
pretty easy to use.
Thoughts?
- Heikki
Attachments:
0001-Add-API-functions-to-libpq-to-interrogate-SSL-relate.patchtext/x-diff; name=0001-Add-API-functions-to-libpq-to-interrogate-SSL-relate.patchDownload
>From 0e0f2ceb86cf99611c00e57efdbc84615347542e Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date: Thu, 27 Nov 2014 20:00:36 +0200
Subject: [PATCH 1/1] Add API functions to libpq to interrogate SSL related
stuff.
This makes it possible to query for things like the SSL version and cipher
used, without depending on OpenSSL functions or macros. That is a good
thing if we ever get another SSL implementation.
---
doc/src/sgml/libpq.sgml | 154 +++++++++++++++++++++++++++----
src/bin/psql/command.c | 35 +++----
src/interfaces/libpq/exports.txt | 4 +
src/interfaces/libpq/fe-secure-openssl.c | 68 ++++++++++++++
src/interfaces/libpq/fe-secure.c | 20 ++++
src/interfaces/libpq/libpq-fe.h | 6 ++
6 files changed, 250 insertions(+), 37 deletions(-)
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index de272c5..b96686a 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -1848,33 +1848,130 @@ int PQconnectionUsedPassword(const PGconn *conn);
</para>
</listitem>
</varlistentry>
+ </variablelist>
+ </para>
- <varlistentry id="libpq-pqgetssl">
- <term><function>PQgetssl</function><indexterm><primary>PQgetssl</></></term>
+ <para>
+ The following functions return information related to SSL. This information
+ usually doesn't change after a connection is established.
+
+ <variablelist>
+ <varlistentry id="libpq-pqsslinuse">
+ <term><function>PQsslInUse</function><indexterm><primary>PQsslInUse</></></term>
<listitem>
<para>
- <indexterm><primary>SSL</><secondary sortas="libpq">in libpq</secondary></indexterm>
- Returns the SSL structure used in the connection, or null
- if SSL is not in use.
+ Returns true (1) if the connection uses SSL, false (0) if not.
<synopsis>
-void *PQgetssl(const PGconn *conn);
+int PQsslInUse(const PGconn *conn);
+</synopsis>
+ </para>
+
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="libpq-pqsslAttribute">
+ <term><function>PQsslAttribute</function><indexterm><primary>PQsslAttribute</></></term>
+ <listitem>
+ <para>
+ Returns SSL-related information about the connection.
+
+<synopsis>
+const char *PQsslAttribute(const PGconn *conn, const char *attribute_name);
</synopsis>
</para>
<para>
- This structure can be used to verify encryption levels, check server
- certificates, and more. Refer to the <productname>OpenSSL</>
- documentation for information about this structure.
+ The list of available attributes varies depending on the SSL library
+ being used, and the type of connection. If an attribute is not
+ available, returns NULL.
</para>
<para>
- The actual return value is of type <type>SSL *</type>,
- where <type>SSL</type> is a type defined by
- the <productname>OpenSSL</productname> library, but it is not declared
- this way to avoid requiring the <productname>OpenSSL</productname>
- header files. To use this function, code along the following lines
- could be used:
+ The following attributes are commonly available:
+ <variablelist>
+ <varlistentry>
+ <term><literal>library</literal></term>
+ <listitem>
+ <para>
+ Name of the SSL implementation in use. (Currently, only
+ <literal>"OpenSSL"</literal> is implemented)
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>protocol</literal></term>
+ <listitem>
+ <para>
+ SSL/TLS version in use. Common values are "SSLv2", "SSLv3",
+ "TLSv1", "TLSv1.1" and "TLSv1.2", but an implementation may
+ return other strings if some other protocol is used.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>key_bits</literal></term>
+ <listitem>
+ <para>
+ Number of key bits used by the encryption algorithm.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>cipher</literal></term>
+ <listitem>
+ <para>
+ A short name of the ciphersuite used, e.g.
+ <literal>"DHE-RSA-DES-CBC3-SHA"</literal>. The names are specific
+ to each SSL implementation.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>compression</literal></term>
+ <listitem>
+ <para>
+ If SSL compression is in use, returns the name of the compression
+ algorithm, or "on" if compression is used but the algorithm is
+ not known. If compression is not in use, returns "off".
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="libpq-pqsslattributes">
+ <term><function>PQsslAttributes</function><indexterm><primary>PQsslAttributes</></></term>
+ <listitem>
+ <para>
+ Return an array of SSL attribute names available. The array is terminated by a NULL pointer.
+<synopsis>
+const char **PQsslAttributes(const PGconn *conn);
+</synopsis>
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="libpq-pqsslstruct">
+ <term><function>PQsslStruct</function><indexterm><primary>PQsslStruct</></></term>
+ <listitem>
+ <para>
+ Return a pointer to an SSL-implementation specific object describing
+ the connection.
+<synopsis>
+void *PQsslStruct(const PGconn *conn, const char *struct_name);
+</synopsis>
+ </para>
+ <para>
+ The structs available depends on the SSL implementation in use.
+ </para>
+
+ <para>
+ For OpenSSL, there is one struct, under the name "OpenSSL SSL",
+ and it returns a pointer to the OpenSSL <literal>SSL</literal> struct.
+ To use this function, code along the following lines could be used:
<programlisting><![CDATA[
#include <libpq-fe.h>
#include <openssl/ssl.h>
@@ -1886,13 +1983,38 @@ void *PQgetssl(const PGconn *conn);
dbconn = PQconnectdb(...);
...
- ssl = PQgetssl(dbconn);
+ ssl = PQsslStruct(dbconn, "OpenSSL SSL");
if (ssl)
{
/* use OpenSSL functions to access ssl */
}
]]></programlisting>
</para>
+ <para>
+ This structure can be used to verify encryption levels, check server
+ certificates, and more. Refer to the <productname>OpenSSL</>
+ documentation for information about this structure.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="libpq-pqgetssl">
+ <term><function>PQgetssl</function><indexterm><primary>PQgetssl</></></term>
+ <listitem>
+ <para>
+ <indexterm><primary>SSL</><secondary sortas="libpq">in libpq</secondary></indexterm>
+ Returns the SSL structure used in the connection, or null
+ if SSL is not in use.
+
+<synopsis>
+void *PQgetssl(const PGconn *conn);
+</synopsis>
+ </para>
+
+ <para>
+ This function is equivalent to PQsslStruct(conn, "OpenSSL SSL"). It should
+ not be used in new code.
+ </para>
</listitem>
</varlistentry>
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 4ac21f2..7c9f28d 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -30,9 +30,6 @@
#include <sys/types.h> /* for umask() */
#include <sys/stat.h> /* for stat() */
#endif
-#ifdef USE_OPENSSL
-#include <openssl/ssl.h>
-#endif
#include "portability/instr_time.h"
@@ -1815,28 +1812,24 @@ connection_warnings(bool in_startup)
static void
printSSLInfo(void)
{
-#ifdef USE_OPENSSL
- int sslbits = -1;
- SSL *ssl;
+ const char *protocol;
+ const char *cipher;
+ const char *bits;
+ const char *compression;
- ssl = PQgetssl(pset.db);
- if (!ssl)
+ if (!PQsslInUse(pset.db))
return; /* no SSL */
- SSL_get_cipher_bits(ssl, &sslbits);
- printf(_("SSL connection (protocol: %s, cipher: %s, bits: %d, compression: %s)\n"),
- SSL_get_version(ssl), SSL_get_cipher(ssl), sslbits,
- SSL_get_current_compression(ssl) ? _("on") : _("off"));
-#else
+ protocol = PQsslAttribute(pset.db, "protocol");
+ cipher = PQsslAttribute(pset.db, "cipher");
+ bits = PQsslAttribute(pset.db, "key_bits");
+ compression = PQsslAttribute(pset.db, "compression");
- /*
- * If psql is compiled without SSL but is using a libpq with SSL, we
- * cannot figure out the specifics about the connection. But we know it's
- * SSL secured.
- */
- if (PQgetssl(pset.db))
- printf(_("SSL connection (unknown cipher)\n"));
-#endif
+ printf(_("SSL connection (protocol: %s, cipher: %s, bits: %s, compression: %s)\n"),
+ protocol ? protocol : _("unknown"),
+ cipher ? cipher : _("unknown"),
+ bits ? bits : _("unknown"),
+ (compression && strcmp(compression, "off") != 0) ? _("on") : _("off"));
}
diff --git a/src/interfaces/libpq/exports.txt b/src/interfaces/libpq/exports.txt
index 93da50d..4a21bf1 100644
--- a/src/interfaces/libpq/exports.txt
+++ b/src/interfaces/libpq/exports.txt
@@ -165,3 +165,7 @@ lo_lseek64 162
lo_tell64 163
lo_truncate64 164
PQconninfo 165
+PQsslInUse 166
+PQsslStruct 167
+PQsslAttributes 168
+PQsslAttribute 169
diff --git a/src/interfaces/libpq/fe-secure-openssl.c b/src/interfaces/libpq/fe-secure-openssl.c
index d8b5995..0dee00c 100644
--- a/src/interfaces/libpq/fe-secure-openssl.c
+++ b/src/interfaces/libpq/fe-secure-openssl.c
@@ -1488,6 +1488,18 @@ SSLerrfree(char *buf)
free(buf);
}
+/* ------------------------------------------------------------ */
+/* SSL information functions */
+/* ------------------------------------------------------------ */
+
+int
+PQsslInUse(PGconn *conn)
+{
+ if (!conn)
+ return 0;
+ return conn->ssl_in_use;
+}
+
/*
* Return pointer to OpenSSL object.
*/
@@ -1499,6 +1511,62 @@ PQgetssl(PGconn *conn)
return conn->ssl;
}
+void *
+PQsslStruct(PGconn *conn, const char *struct_name)
+{
+ if (!conn)
+ return NULL;
+ if (strcmp(struct_name, "OpenSSL SSL") == 0)
+ return conn->ssl;
+ return NULL;
+}
+
+const char **
+PQsslAttributes(PGconn *conn)
+{
+ static const char *result[] = {
+ "library",
+ "key_bits",
+ "cipher",
+ "compression",
+ "protocol",
+ NULL
+ };
+ return result;
+}
+
+const char *
+PQsslAttribute(PGconn *conn, const char *attribute_name)
+{
+ if (!conn)
+ return NULL;
+ if (conn->ssl == NULL)
+ return NULL;
+
+ if (strcmp(attribute_name, "library") == 0)
+ return "OpenSSL";
+
+ if (strcmp(attribute_name, "key_bits") == 0)
+ {
+ static char sslbits_str[10];
+ int sslbits;
+
+ SSL_get_cipher_bits(conn->ssl, &sslbits);
+ snprintf(sslbits_str, sizeof(sslbits_str), "%d", sslbits);
+ return sslbits_str;
+ }
+
+ if (strcmp(attribute_name, "cipher") == 0)
+ return SSL_get_cipher(conn->ssl);
+
+ if (strcmp(attribute_name, "compression") == 0)
+ return SSL_get_current_compression(conn->ssl) ? "on" : "off";
+
+ if (strcmp(attribute_name, "protocol") == 0)
+ return SSL_get_version(conn->ssl);
+
+ return NULL; /* unknown attribute */
+}
/*
* Private substitute BIO: this does the sending and receiving using send() and
diff --git a/src/interfaces/libpq/fe-secure.c b/src/interfaces/libpq/fe-secure.c
index 3b79c6b..1ee9f36 100644
--- a/src/interfaces/libpq/fe-secure.c
+++ b/src/interfaces/libpq/fe-secure.c
@@ -381,12 +381,32 @@ retry_masked:
return n;
}
+/* Dummy versions of SSL getter functions, when built without SSL support */
#ifndef USE_SSL
+
+int
+PQsslInUse(PGconn *conn)
+{
+ return 0;
+}
+
void *
PQgetssl(PGconn *conn)
{
return NULL;
}
+
+void *
+PQsslStruct(PGconn *conn, const char *struct_name)
+{
+ return NULL;
+}
+
+const char *
+PQsslAttribute(PGconn *conn, const char *attribute_name)
+{
+ return NULL;
+}
#endif /* USE_SSL */
diff --git a/src/interfaces/libpq/libpq-fe.h b/src/interfaces/libpq/libpq-fe.h
index c402119..a73eae2 100644
--- a/src/interfaces/libpq/libpq-fe.h
+++ b/src/interfaces/libpq/libpq-fe.h
@@ -318,6 +318,12 @@ extern int PQconnectionUsedPassword(const PGconn *conn);
extern int PQclientEncoding(const PGconn *conn);
extern int PQsetClientEncoding(PGconn *conn, const char *encoding);
+/* SSL information functions */
+extern int PQsslInUse(PGconn *conn);
+extern void *PQsslStruct(PGconn *conn, const char *struct_name);
+extern const char *PQsslAttribute(PGconn *conn, const char *attribute_name);
+extern const char **PQsslAttributes(PGconn *conn);
+
/* Get the OpenSSL structure associated with a connection. Returns NULL for
* unencrypted connections or if any other TLS library is in use. */
extern void *PQgetssl(PGconn *conn);
--
2.1.4
On Wed, Jan 28, 2015 at 10:13 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
Here's a patch to implement the above scheme. It adds four functions to
libpq, to interrogate the SSL status:int PQsslInUse(const PGconn *conn)
Returns true (1) if the connection uses SSL, false (0) if not.const char *PQsslAttribute(const PGconn *conn, const char *attribute_name)
Returns a piece of information. The list of attributes depends on the
implementation, but there are a few that are expected to be supported by all
of them. See docs for details.const char **PQsslAttributes(const PGconn *conn);
Return an array of SSL attribute names available.void *PQsslStruct(const PGconn *conn, const char *struct_name)
Return a pointer to an SSL-implementation specific object describing the
connection. PQsslStruct(conn, "OpenSSL SSL") is equivalent to
PQgetssl(conn).I think this is expandable enough, because you can easily add attributes
later on, and different implementations can support different attributes. It
contains the escape hatch for applications that need to do more, and have
intimate knowledge of OpenSSL structs. It's also pretty easy to use.
I like it!
Although I think "OpenSSL SSL" is a little bit duplicatively
redundant. Why not just "OpenSSL"?
--
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) wrote:
On Wed, Jan 28, 2015 at 10:13 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:Here's a patch to implement the above scheme. It adds four functions to
libpq, to interrogate the SSL status:int PQsslInUse(const PGconn *conn)
Returns true (1) if the connection uses SSL, false (0) if not.const char *PQsslAttribute(const PGconn *conn, const char *attribute_name)
Returns a piece of information. The list of attributes depends on the
implementation, but there are a few that are expected to be supported by all
of them. See docs for details.const char **PQsslAttributes(const PGconn *conn);
Return an array of SSL attribute names available.void *PQsslStruct(const PGconn *conn, const char *struct_name)
Return a pointer to an SSL-implementation specific object describing the
connection. PQsslStruct(conn, "OpenSSL SSL") is equivalent to
PQgetssl(conn).I think this is expandable enough, because you can easily add attributes
later on, and different implementations can support different attributes. It
contains the escape hatch for applications that need to do more, and have
intimate knowledge of OpenSSL structs. It's also pretty easy to use.I like it!
Although I think "OpenSSL SSL" is a little bit duplicatively
redundant. Why not just "OpenSSL"?
I wondered also, but figured it was probably because it's OpenSSL's
"ssl" structure, which then made sense.
What bothers me about this is that it punts SSL work to the application
and requires that they be coded to work with both OpenSSL and whatever
else we implement (eg: GnuTLS) to do anything but the most simple
checks. That's a problem because people are *not* going to want to
#include both OpenSSL and GnuTLS headers into their applications because
they don't know which PG will be compiled with.. Not to mention that
it'd be darn awkward to do so.
My hope is that Heikki's attribute approach will be extended quite a bit
in the near future (to hopefully avoid too many apps having to deal with
the complexity of supporting multiple major PG versions where the older
ones don't have the necessary attributes..), but I'm not sure that this
will actually make it much easier to support GnuTLS, nor am I sure that
anyone is going to actually go through that effort.. And if we don't
then we really aren't making an improvement here since it'll still all
be OpenSSL-centric.
Thanks,
Stephen
Stephen Frost <sfrost@snowman.net> writes:
What bothers me about this is that it punts SSL work to the application
and requires that they be coded to work with both OpenSSL and whatever
else we implement (eg: GnuTLS) to do anything but the most simple
checks. That's a problem because people are *not* going to want to
#include both OpenSSL and GnuTLS headers into their applications because
they don't know which PG will be compiled with.. Not to mention that
it'd be darn awkward to do so.
The point of this is to provide an escape hatch for people who really
want to do XYZ even though we provide no API for XYZ in libpq. Hopefully,
those people will be few and far between, because anything that's a really
common requirement should be catered for by libpq.
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/28/2015 06:58 PM, Stephen Frost wrote:
Although I think "OpenSSL SSL" is a little bit duplicatively
redundant. Why not just "OpenSSL"?I wondered also, but figured it was probably because it's OpenSSL's
"ssl" structure, which then made sense.
Right, that was the idea. I wanted it to include the word "OpenSSL", to
make it clear in the callers that it's specific to OpenSSL. And SSL,
because that's the name of the struct. I agree it looks silly, though.
One idea is to have two separate arguments: the implementation name, and
the struct name. PQgetSSLstruct(&ssl, "OpenSSL", "SSL") would look less
silly.
- Heikki
--
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 (tgl@sss.pgh.pa.us) wrote:
Stephen Frost <sfrost@snowman.net> writes:
What bothers me about this is that it punts SSL work to the application
and requires that they be coded to work with both OpenSSL and whatever
else we implement (eg: GnuTLS) to do anything but the most simple
checks. That's a problem because people are *not* going to want to
#include both OpenSSL and GnuTLS headers into their applications because
they don't know which PG will be compiled with.. Not to mention that
it'd be darn awkward to do so.The point of this is to provide an escape hatch for people who really
want to do XYZ even though we provide no API for XYZ in libpq. Hopefully,
those people will be few and far between, because anything that's a really
common requirement should be catered for by libpq.
I understand that, but 4 variables is pretty darn far from what an
application developing for SSL is going to want. As I've mentioned
before when this has been brought up, I'm of the opinion that we should
be providing, from the start, the same set as Apache's SSL environment
variables:
The mod_ssl (OpenSSL-based) documentation:
http://httpd.apache.org/docs/2.2/mod/mod_ssl.html
For mod_gnutls, this is the list of SSL variables provided:
http://www.outoforder.cc/projects/apache/mod_gnutls/docs/#environment-variables
Note that they're pretty much the same set, so providing them for
OpenSSL isn't closing off the ability to provide GnuTLS in the future.
To be clear, I'm not asking for all of this to happen in the first
patch, but I'd like whomever is going forward with this to at least
agree that they're going to try and cover the Apache set for whatever
libraries are supported in the first major release we put out with this.
Considering the example is already there, I'm really hopeful that isn't
too difficult to do..
Thanks,
Stephen
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
Right, that was the idea. I wanted it to include the word "OpenSSL", to
make it clear in the callers that it's specific to OpenSSL. And SSL,
because that's the name of the struct. I agree it looks silly, though.
One idea is to have two separate arguments: the implementation name, and
the struct name. PQgetSSLstruct(&ssl, "OpenSSL", "SSL") would look less
silly.
That's probably overkill. Why not establish a convention that the "main"
API struct for the library doesn't have to be named? So it's just
PQgetSSLstruct(&ssl, "OpenSSL"), and you only need strange naming if
you're dealing with a library that actually has more than one API object
that needs to be fetched this way. (That set is likely empty...)
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/28/2015 08:05 PM, Tom Lane wrote:
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
Right, that was the idea. I wanted it to include the word "OpenSSL", to
make it clear in the callers that it's specific to OpenSSL. And SSL,
because that's the name of the struct. I agree it looks silly, though.
One idea is to have two separate arguments: the implementation name, and
the struct name. PQgetSSLstruct(&ssl, "OpenSSL", "SSL") would look less
silly.That's probably overkill. Why not establish a convention that the "main"
API struct for the library doesn't have to be named? So it's just
PQgetSSLstruct(&ssl, "OpenSSL"), and you only need strange naming if
you're dealing with a library that actually has more than one API object
that needs to be fetched this way. (That set is likely empty...)
Works for me. Committed that way.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers