Re: Spoofing as the postmaster - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Spoofing as the postmaster
Date
Msg-id 47763228.1010908@hagander.net
Whole thread Raw
In response to Re: Spoofing as the postmaster  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Spoofing as the postmaster  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>> Agreed.  Requiring client root certificate checking is heavy-handed.
> 
> There seems to be some confusion here.  I didn't think anyone was
> proposing that we force every installation to require client root
> certificate checking.  What was under discussion (I thought) was
> providing the ability for a DBA to *choose* to require it.

Ok, at least someone is partly lost in this discussion, and I'm getting
a sneaky suspicion it's me :-)

We already *do* allow the DBA to choose this, no? If you put the root
certificate on the client, it *will* verify the server cert, and it
*will* refuse to connect to a server that can't present a trusted root cert.

Hang on, maybe I get what you're referring to now - we don't check the
Common Name field on the certificate, so *any* trusted certificate would
be ok. Incorrect common name generally results in a warning in a
browser, for example, but we accept it fine. We do store it in
conn->peer_cn, so the client can check it if they need to. But we don't
enforce.


Or are you saying that the *server* should require that the client has
done verification, by a config string? If so, I just don't see how
that's possible in any meaningful way.


>> Of course I am not sure anyone knows how to get that information from
>> SSL.
> 
> Yeah, if OpenSSL doesn't support testing for this then the discussion
> is moot...

AFAIK, our current OpenSSL code supports verifying both client and
server certificates. If we want to, as Bruce suggested, emit a log
message when the client hasn't provided a certificate, we can certainly
do so. But I thought this thread was about impersonating the server, not
the client...

Emitting such a log message in cases where the system isn't configured
to use client certificates at all would cause a whole lot of unnecessary
logging for all cases that don't use client certificates. And if you
*do* use client certificates, it's not going to get emitted because you
can't even *connect* without having it.

Now, if/when we actually support authenticating with client certificates
(as I said, I hope to work on this), the equation is different because
then you can set it per hba using authentication method. But just
enabling such a thing globally is a very blunt instrument...

//Magnus


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: minimal update
Next
From: Magnus Hagander
Date:
Subject: Re: Spoofing as the postmaster