Message-ID: <53F377EE.4090006@vmware.com>
Date: Tue, 19 Aug 2014 19:14:38 +0300
From: Heikki Linnakangas <hlinnakangas@vmware.com>
Organization: VMware
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Stephen Frost <sfrost@snowman.net>
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: PQgetssl() and alternative SSL implementations
References: <53F1E989.8020609@vmware.com>
 <20140819144841.GA16422@tamriel.snowman.net> <53F36B6E.6040105@vmware.com>
 <20140819154436.GD16422@tamriel.snowman.net>
In-Reply-To: <20140819154436.GD16422@tamriel.snowman.net>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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