From: Heikki Linnakangas <hlinnakangas@vmware.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: PQgetssl() and alternative SSL implementations
Date: Tue, 19 Aug 2014 19:14:38 +0300
Message-ID: <53F377EE.4090006@vmware.com> (raw)
In-Reply-To: <20140819154436.GD16422@tamriel.snowman.net>
References: <53F1E989.8020609@vmware.com>
<20140819144841.GA16422@tamriel.snowman.net>
<53F36B6E.6040105@vmware.com>
<20140819154436.GD16422@tamriel.snowman.net>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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
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: hlinnakangas@vmware.com, sfrost@snowman.net
Subject: Re: PQgetssl() and alternative SSL implementations
In-Reply-To: <53F377EE.4090006@vmware.com>
* 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