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