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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2007-12-29 11:45:26 | Re: Spoofing as the postmaster |
Previous Message | Andrew Dunstan | 2007-12-29 05:40:13 | Re: minimal update |