Re: Successor of MD5 authentication, let's use SCRAM - Mailing list pgsql-hackers

On Sun, Oct 21, 2012 at 5:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> I don't see a problem at all with providing the snakeoil cert. In
>> fact, it's quite useful.
>
>> I see a problem with enabling it by default. Because it makes people
>> think they are more secure than they are.
>
> I am far from an SSL expert, but I had the idea that the only problem
> with a self-signed cert is that the client can't trace it to a trusted
> cert --- so if the user took the further step of copying the cert to the
> client machines' ~/.postgresql/root.crt files, wouldn't things be just
> fine?

I'm not sure if server certs are supposed to go in the root.crt file
or somewhere else. It's a bit tricky to distribute them securely but
most people will just scp them and call that good since they ignore
the ssh host key messages anyways.

Fwiw the main problem here is that you're vulnerable to a MitM attack.
In theory we could work around that by doing something like encrypting
the ssl public key in a key based on a query provided by the user.
That query would have to include some server data that the client can
predict and that only the correct server would have access to. There
are obvious problems with this though and inventing our own security
protocol is almost certainly a bad idea even if we can fix them.

>> In a browser, they will get a big fat warning every time, so they will
>> know it. There is no such warning in psql. Actually, maybe we should
>> *add* such a warning. We could do it in psql. We can't do it in libpq
>> for everyone, but we can do it in our own tools... Particularly since
>> we do print the SSL information already - we could just add a
>> "warning: cert not verified" or something like that to the same piece
>> of information.

I think we can provide a much better warning however. I think we want
something like 'WARNING: Server identity signed by unknown and
untrusted authority "Snakeoil CA"'

We could go even further:
INFO: Server identity "ACME Debian Machine" certified by "Snakeoil CA"
WARNING: Server identity signed by unknown and untrusted authority "Snakeoil CA"
HINT: Add either the server certificate or the CA certificate to
"/usr/lib/ssl/certs" after verifying the identity and certificate hash

SSL is notoriously hard to set up, it would go a long way to give the
sysadmin an immediate pointer to what certificates are being used and
where to find or install the CA certs. It might be worth mentioning
the GUC parameter names to control these things too.

> What happens in the other direction, ie if a client presents a
> self-signed cert that the server can't verify?

Surely that's just a failure. The server always expects client
authentication and a connection authenticated using an unverified cert
could be anyone at all. Clients traditionally didn't authenticate the
server until encrypted connections entered the picture and preventing
MitM attacks became relevant.

-- 
greg