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

On Fri, May 21, 2010 at 7:52 AM, Craig Ringer
<craig@postnewspapers.com.au> wrote:
>
> The following bug has been logged online:
>
> Bug reference: =A0 =A0 =A05468
> Logged by: =A0 =A0 =A0 =A0 =A0Craig Ringer
> Email address: =A0 =A0 =A0craig@postnewspapers.com.au
> PostgreSQL version: 8.4
> Operating system: =A0 Ubuntu 10.04, but affects all
> Description: =A0 =A0 =A0 =A0Pg doesn't send accepted root CA list to clie=
nt during
> SSL client cert request
> Details:

This is actually not a bug, but a documented way how it's done. It's
actually even on the TODO to get it fixed, referencing bug #5245 -
from what I can tell that's what you're talking about, except we need
to send it in both directions?


> When configured to request a client certificate by the installation of the
> 'root.crt' file in the data dir, PostgreSQL will instruct OpenSSL to send=
 a
> CertificateRequest message during the SSL handshake. This asks the client=
 to
> send a certificate.
>
> However, Pg doesn't tell OpenSSL to present the list of accepted signing
> roots to the client, so the client has no way of knowing what client
> certificate to present.
>
> Existing clients (such as psql) generally only have one certificate/key
> pair, and will blindly present it without checking what the server suppor=
ts.
> So it works fine.
>
> If a client has a selection of keypairs, however, it will be unable to
> negotiate with the server as it has no way to know which keypair to offer.
> It can brute-force this with multiple connection attempts, but that's more
> than little ugly. It may also try to guess the right client cert to send
> based on the cert the server presented, but that'll only work if the serv=
er
> cert happens to be signed by the same CA as the client certs, which is
> frequently NOT the case.
>
> Pg needs to tell OpenSSL to present the accepted root certificate(s) to t=
he
> client during negotiation, so the client can tell what to do. Adding a
> suitable call to SSL_CTX_set_client_CA_list(...) in
> src/backend/libpq/be-secure.c will do the trick, though it'll require
> explicit loading of the CA cert list rather than the current approach of
> just telling OpenSSL the file name.
>
> This change will fix Java/JDBC clients trying to negotiate with a Pg serv=
er.
> At present, a Java client using the Sun built-in X509KeyManager
> implementation fails to negotiate because it doesn't know what cert to
> present to the server. The user may provide a custom X509KeyManager, but =
in
> doing so makes it difficult for the user to use PKCS#11 hardware tokens,
> system-wide single sign-on, kerberos key storage, or other mechanisms.
>
> This issue will also affect other clients using key stores capable of
> holding multiple keys, like Mozilla's NSS and any PKCS#11 hardware token
> provider, so it's not just Java specific.

Yeah, all our (at least my) testing is done on OpenSSL - I had no idea
of this behaviour of the java layer really.

Unfortunately, I don't think this is something we can fix as a bugfix
- it'll be a pretty clear change of behaviour, so I think it's
something we will need to push back for a full release, which would
mean 9.1. What would be good is if we can collect a list of interop
issues and collect test-cases for them, because given the state of the
openssl documentation it really comes down to having fairly detailed
test-cases...


--=20
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/