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

Re: BUG #5468: Pg doesn't send accepted root CA list to client during SSL client cert request

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
Date: 2010-05-24 00:12:33
Message-ID: 4BF9C471.9050705@postnewspapers.com.au (view raw or flat)
Thread:
Lists: pgsql-bugs
On 24/05/10 00:58, Tom Lane wrote:
> Craig Ringer<craig(at)postnewspapers(dot)com(dot)au>  writes:
>> + 		SSL_CTX_set_client_CA_list( SSL_context, SSL_load_client_CA_file(ROOT_CERT_FILE) );
>
> Hmm, what about failures?  If we're loading the root cert file a second
> time, it's possible that the user just changed it and the load now fails
> for some reason.

True I guess. It's a pretty narrow window for failure given that we 
*just* loaded it milliseconds ago, but not impossible.

As it is, SSL_ctx_set_client_CA_list handles null input gracefully, and 
the client_CA member of the SSL_context starts out null, so there'll be 
no harm in calling SSL_CTX_set_client_CA_list with a null arg when 
SSL_load_client_CA_file fails. It just assigns null to the the 
already-null client_CA member of the context. OpenSSL checks for null in 
client_CA before doing anything with it.

If the user does somehow manage to trigger this case, the worst that'll 
happen is that the list of trusted certificates will not be sent to the 
client - exactly as currently happens. This may cause some clients to 
fail to negotiate, but cannot grant access that would otherwise not be 
granted. Triggering it requires access to the datadir (or where a 
symlink from the datadir points) and has such a narrow time window I'm 
not sure it's worth worrying about.

I *could* avoid the second file load by supplying the list of loaded 
certificates from SSL_load_client_CA_file to OpenSSL as trusted 
certificates for verifying clients. I'd really rather not mess with the 
logic around verifying client certificates, though, especially given the 
state of the OpenSSL documentation. What I've done is the approach 
recommended in the documentation (see the man page for 
SSL_CTX_set_client_CA_list) and seems safest.

Still, I'm happy to move some code around so that either load of 
ROOT_CERT_FILE will report an error. The reason I did it this way is 
that it's a small, clear change that only affects users of client 
certificates. I've attached a revision that catches both failures, using 
the existing error message. Hope that suits.

--
Craig Ringer

Attachment: postgresql-backend-send-client-trusted-roots-v2.diff
Description: text/x-patch (1.4 KB)

In response to

pgsql-bugs by date

Next:From: Joshua TolleyDate: 2010-05-24 00:53:10
Subject: Re: ERROR: failed to build any 3-way joins
Previous:From: Jehan-Guillaume (ioguix) de RorthaisDate: 2010-05-23 20:11:22
Subject: ERROR: failed to build any 3-way joins

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