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