Re: SSL cleanups/hostname verification

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: SSL cleanups/hostname verification
Дата
Msg-id 48FDBFD7.6000208@gmx.net
обсуждение исходный текст
Ответ на Re: SSL cleanups/hostname verification  (Martijn van Oosterhout <kleptog@svana.org>)
Ответы Re: SSL cleanups/hostname verification  (Magnus Hagander <magnus@hagander.net>)
Re: SSL cleanups/hostname verification  (Magnus Hagander <magnus@hagander.net>)
Re: SSL cleanups/hostname verification  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-hackers
Martijn van Oosterhout wrote:
> SSH is a good example, it only works with self-signed certificates, and
> relies on the client to check it. Libpq provides a mechanism for the
> client to verify the server's certificate, and that is safe even if it
> is self-signed.
> 
> If the client knows the certificate the server is supposed to present,
> then you can't have a man-in-the-middle attack, right? Whether it's
> self-signed or not is irrelevent.

That appears to be correct, but that was not the original issue under 
discussion.

Both a web browser and an SSH client will, when faced with an untrusted 
certificate, pop a question to the user.  The user then verifies the 
certificate some other way (in theory), answers/clicks yes, and then web 
browser and SSH client store the certificate locally marked as trusted, 
so this question goes away the next time.

An SSL-enabled libpq program will, when faced with an untrusted 
certificate, go ahead anyway, without notification.  (Roughly speaking.  If I understand this right, there are other
scenariosdepending on 
 
whether the client user has set up the requires files in ~/.postgresql.  All this just leads users to do the wrong
thingby neglect, ignorance, 
 
or error.)

The change Magnus proposes is that SSL-enabled libpq programs will in 
the future refuse to connect without a trusted certificate.  Being a 
library, we cannot really go ask the user, as web browser and SSH client 
do, but I could imagine that we could make psql do that and store the 
trusted certificate automatically in a local place.  Then we would be 
close to the usual operating mode for SSH and web browsers, and then 
chances are better that users can understand this setup and use it 
securely and easily.

> Preventing casual snooping without preventing MitM is a rational choice
> for system administrators.

I am not an expert in these things, but it seems to me that someone who 
can casually snoop can also casually insert DHCP or DNS packages and 
redirect traffic.  There is probably a small niche where just encryption 
without server authentication prevents information leaks, but it is not 
clear to me where this niche is or how it can be defined, and I 
personally wouldn't encourage this sort of setup.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Matthieu Imbert
Дата:
Сообщение: Re: binary representation of datatypes
Следующее
От: "Ted Wong"
Дата:
Сообщение: TSEARCH2 Thesaurus limitations