MIME-Version: 1.0
References: <ZiH7vHwEJeRKHlST@paquier.xyz> <CAOYmi+kfsRfopQRTuJwpsO50Urq=-gwYDJ1fWNkDr3oYM1wdjA@mail.gmail.com>
 <CA+TgmoZspODpL6AYbANpffhbF+Q12xo1pHXrR9ZSkYfEQWpP3w@mail.gmail.com>
 <CAOYmi+k3x-aKiVzyLfzdxFdmcBmVD8UvcwfB075BkNqyA1aa9w@mail.gmail.com>
 <CA+TgmobR1R8q-rT06oWdLw_Kp_i67Uey9b+rWVrrpCJVSDNBFQ@mail.gmail.com>
 <CAOYmi+=TB8=yfXoBk=p0k0GPaCD79F8xXcypZFkjKmPKuT0hjQ@mail.gmail.com>
 <f6833e88-2e21-459d-a661-152ced273c60@iki.fi> <CAOYmi+nWKJNihuMpT+ZVTC5-d+pQdACTK7xKhhwAB075EHrOMg@mail.gmail.com>
 <3a6f126c-e1aa-4dcc-9252-9868308f6cf0@iki.fi> <CAOYmi+k2kJcJLMj=K4Vb3S_J6tN6989Wfi5+amqf15VkHcej3Q@mail.gmail.com>
 <1a717f65-7390-4111-8efd-c6e9b213805e@iki.fi> <CAOYmi+mAfO2hXfpOrpjhSZZf7Rq-rCywdyyfygkqbZ0KZjOBTg@mail.gmail.com>
 <d3b1608a-a1b6-4eda-9ec5-ddb3e4375808@iki.fi> <CAGECzQS9V5t9-gNtd8pUXR+Rv1vZFE6bPYvt1bO-f+c_UkXGHw@mail.gmail.com>
 <f6434810-3d12-4ce1-860b-1ce79e9d03ea@iki.fi> <CAGECzQSs8rWE9jjEVTahGNa=aKi_r3bqJXBUiAJmaZA0GY4mdw@mail.gmail.com>
 <b2d42242-e979-4ae5-a864-e4b64e563b60@iki.fi>
In-Reply-To: <b2d42242-e979-4ae5-a864-e4b64e563b60@iki.fi>
From: Jelte Fennema-Nio <postgres@jeltef.nl>
Date: Mon, 13 May 2024 16:19:36 +0200
Message-ID: <CAGECzQQtddvUtA3+sOqOhb2h6hXJx66YNdMuz-Eim4pzQUJ-BQ@mail.gmail.com>
Subject: Re: Direct SSL connection with ALPN and HBA rules
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Jacob Champion <jacob.champion@enterprisedb.com>, Daniel Gustafsson <daniel@yesql.se>, 
	Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael@paquier.xyz>, 
	Postgres hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAGECzQQtddvUtA3%2BsOqOhb2h6hXJx66YNdMuz-Eim4pzQUJ-BQ%40mail.gmail.com>
Precedence: bulk

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

Cool, I didn't realize we had this connection option and it could be
used like this. But I think there's a few security downsides of
channel_binding=require over sslmode=verify-full: If the client relies
on channel_binding to validate server authenticity, a leaked
server-side SCRAM hash is enough for an attacker to impersonate a
server. While normally a leaked scram hash isn't really much of a
security concern (assuming long enough passwords). I also don't know
of many people rotating their scram hashes, even though many rotate
TLS certs.

> I think these options should be designed from the user's point of view,
> so that the user can specify the risks they're willing to accept, and
> the details of how that's accomplished are handled by libpq. For
> example, I'm OK with (tick all that apply):
>
> [ ] passive eavesdroppers seeing all the traffic
> [ ] MITM being able to hijack the session
> [ ] connecting without verifying the server's identity
> [ ] divulging the plaintext password to the server
> [ ] ...

I think that sounds like a great idea, looking forward to the proposal.