Craig Ringer <cr...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
