From: Stephen Frost <sfrost@snowman.net>
To: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: PQgetssl() and alternative SSL implementations
Date: Tue, 19 Aug 2014 11:44:36 -0400
Message-ID: <20140819154436.GD16422@tamriel.snowman.net> (raw)
In-Reply-To: <53F36B6E.6040105@vmware.com>
References: <53F1E989.8020609@vmware.com>
<20140819144841.GA16422@tamriel.snowman.net>
<53F36B6E.6040105@vmware.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-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
Attachments:
signature.asc (application/pgp-signature, 818B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net, hlinnakangas@vmware.com
Subject: Re: PQgetssl() and alternative SSL implementations
In-Reply-To: <20140819154436.GD16422@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox