On the use of channel binding without server certificates (was: Direct SSL connection with ALPN and HBA rules)

Поиск
Список
Период
Сортировка
От Jacob Champion
Тема On the use of channel binding without server certificates (was: Direct SSL connection with ALPN and HBA rules)
Дата
Msg-id CAOYmi+=T-do_9Zdyz2KNMRnq=_5Z+k5WnGodu4rfevVpfQjWQg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Direct SSL connection with ALPN and HBA rules  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
[soapbox thread, so I've changed the Subject]

On Mon, May 13, 2024 at 4:08 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> "channel_binding=require sslmode=require" also protects from MITM attacks.

This isn't true in the same way that "standard" TLS protects against
MITM. I know you know that, but for the benefit of bystanders reading
the threads, I think we should stop phrasing it like this. Most people
who want MITM protection need to be using verify-full.

Details for those bystanders: Channel binding alone will only
disconnect you after the MITM is discovered, after your startup packet
is leaked but before you send any queries to the server. A hash of
your password will also be leaked in that situation, which starts the
timer on an offline attack. And IIRC, you won't get an alert that says
"someone's in the middle"; it'll just look like you mistyped your
password.

(Stronger passwords provide stronger protection in this situation,
which is not a property that most people are used to. If I choose to
sign into Google with the password "hunter2", it doesn't somehow make
the TLS protection weaker. But if you rely on SCRAM by itself for
server authentication, it does more or less work like that.)

Use channel_binding *in addition to* sslmode=verify-full if you want
enhanced authentication of the peer, as suggested in the docs [1].
Don't rely on channel binding alone for the vast majority of use
cases, and if you know better for your particular use case, then you
already know enough to be able to ignore my advice.

[/soapbox]

Thanks,
--Jacob

[1] https://www.postgresql.org/docs/current/preventing-server-spoofing.html



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

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Fix resource leak (src/backend/libpq/be-secure-common.c)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Is there any chance to get some kind of a result set sifting mechanism in Postgres?