Prev: [HACKERS] out-of-date comment in CreateRestartPoint()
Next: Show schema name on REINDEX DATABASE
From: Craig Ringer on 26 May 2010 22:46
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
anyway.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 26 May 2010 22:50
Craig Ringer <craig(a)postnewspapers.com.au> writes:
> 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
> anyway.

Precisely. I'm not excited about doing anything about this in the near
term, or even the not-so-near term. I just wanted to get the
information into the PG archives in case it ever does become
significant.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  | 
Pages: 1 2
Prev: [HACKERS] out-of-date comment in CreateRestartPoint()
Next: Show schema name on REINDEX DATABASE