Skip site navigation (1) Skip section navigation (2)

Re: libpq should not be using SSL_CTX_set_client_cert_cb

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org, Magnus Hagander <magnus(at)hagander(dot)net>
Subject: Re: libpq should not be using SSL_CTX_set_client_cert_cb
Date: 2010-05-27 02:46:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 27/05/10 10:21, Tom Lane wrote:

> What will happen as things stand is that all the certs get loaded
> into a common pool.  That's not too horrible as long as there are
> not actual conflicts, but it could mean that for example some
> connections trust CA certs that the app programmer expected to only
> be trusted for other connections.  I did arrange (and test) that the
> client cert and key are local to each connection, but leakage of
> trusted root certs is a different story.
> We could avoid this problem if we were willing to set up a separate
> SSL_context for each connection, but I'm not sure if it's worth that.
> The scenario where a single application process is managing multiple
> distinct sets of trusted certs seems a bit far-fetched anyway.

OpenSSL really doesn't seem to be designed for multiple truly 
independent SSL contexts. The SSL context stuff has clearly been hacked 
on after the fact to a library that started out having only one global 
state, and it's pretty incomplete. I'm honestly not sure it's worth 
trying to allow per-connection trust going, especially as (AFAIK) 
there's no evidence that anybody _wants_ per-client-connection SSL trust 

If I really needed that sort of thing, I'd try to abstract the OpenSSL 
stuff away a layer, so it could be replaced by Mozilla NSS (or GnuTLS, 
or whatever) if an application needed it. This would make it easier to 
use libpq in apps that already have their own SSL/TLS environment based 
on a different library, and would make it possible for apps to use more 
flexible libraries if they needed to do complex things with SSL/TLS.

Really, though, is it necessary? What's the use case for trusting one 
cert for one connection, and another cert for another connection, beyond 
what's already provided by 'verify-full' in terms of hostname/ip 
checking? It *is* possible in more sophisticated APIs (Java, NSS too I 
think) but it's hard to imagine client-side reasons to use it.

(Or have I misunderstood what you're describing?)

Craig Ringer

In response to


pgsql-hackers by date

Next:From: Takahiro ItagakiDate: 2010-05-27 02:49:35
Subject: Re: exporting raw parser
Previous:From: Robert HaasDate: 2010-05-27 02:38:34
Subject: Re: psql's is_select_command is naive

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group