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

Re: Spoofing as the postmaster

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Spoofing as the postmaster
Date: 2007-12-29 11:40:24
Message-ID: 47763228.1010908@hagander.net (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2007-12-29 11:45:26
Subject: Re: Spoofing as the postmaster
Previous:From: Andrew DunstanDate: 2007-12-29 05:40:13
Subject: Re: minimal update

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