Re: Spoofing as the postmaster

Mark Mielke wrote:
> 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.
>>
>>> 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..
> I believe SSL is only capable of letting you know whether authentication
> for each end point was 1) not requested, 2) optional requested, or 3)
> required. Note that even if the authentication is required, there is no
> way to know how authentication was performed. For example, did it check
> the signature chain, requiring it to map to a public root certificate
> lists used by most web browsers? If so, did it check the contents of the
> certificate, or is only checking that it exists? Did it check a local
> key store that has a copy of the public key certificate? Or did it just
> log the certificate subject?

That is exactly my point. The server can never know if the client has
actually verified anything. It can provide the client with the *means*
to verify things, but it can't enforce it.

A naive implementation would have a flag in the protocol that says
"enforce client to validate server certs". The MITM attacker could then
just remove this flag in the stream before it arrives at the client, and
it's gone. And the kind of attack we would be trying to protect from
here is exactly the one that can trivially remove such a check. It would
just be a no-op with administrative overhead, really.

The bottom line is that the server cannot be responsible for client
security. Only the client can.

> OpenSSH, for instance, presents the user with the finger print of the
> certificate and asks you:
>
> $ ssh 192.168.0.1
> The authenticity of host '192.168.0.1 (192.168.0.1)' can't be established.
> RSA key fingerprint is 3e:a7:0f:04:60:7e:8e:64:52:bf:81:92:a9:05:c7:36.
> Are you sure you want to continue connecting (yes/no)?
>
> While this certainly gives you the opportunity to challenge it, I don't
> know of any person who actually checks this finger print. Luckily, it
> stores it to ~/.ssh/known_hosts, and so the real issue is if it suddenly
> changes, you get a warning. Still, I've seen the warning before, and
> realized that "oh yes, that machine was upgraded, so it probably has a
> new public key". I have never personally checked the finger print
> against a known source. Authentication is only as strong as the person
> or process confirming it. In the case of trying to force a client to
> authenticate the server, this requires the client to know who the server
> is. As most clients will not know who the server is, I see clients
> implementing an OpenSSH-style authentication model (shown above), or
> providing their own no-op authentication routine to OpenSSL. I don't
> think it is worth it, and I don't think it would work.

Yeah, it *is* decent protection against it suddenly changing. But as you
say, that requires the original fingerprint to be stored at the client.
Just like if you store the root or server cert on a libpq client, it
will refuse to connect if the server suddenly presents an untrusted
certificate. (So in that way we're actually *more* secure than OpenSSH,
since we don't give you a prompt to ignore an untrusted root cert - we
just refuse to connect. Unless you manually disable the check by
removing the file.)

//Magnus