Re: RFC 9266: Channel Bindings for TLS 1.3 support
Nico Williams <nico@cryptonector.com>
From: Nico Williams <nico@cryptonector.com>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, * Neustradamus * <neustradamus@hotmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-11-21T17:38:04Z
Lists: pgsql-hackers
On Thu, Nov 20, 2025 at 01:59:22PM -0800, Jacob Champion wrote: > On Thu, Nov 20, 2025 at 1:52 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote: > > PostgreSQL does support channel binding, with tls-server-end-point. I > > believe that sufficient to prevent an attack like that. > > No, IIRC unique bindings (-unique and -exporter) prevent MITM even if > the attacker has the server's private key, as long as they do not also > possess the SCRAM verifiers. tls-server-end-point does not prevent > against that (so you can terminate TLS on a different node from the > verifiers). If the attacker has the server's private keys then presumably also have the credentials needed to also terminate the SASL/GSS-API mechanism's server/acceptor side, so channel binding will not protect you. The original intent for channel binding was so we could have channels that authenticate end-points either very weakly (IPsec) or not at all (TLS w/ anonymous ciphersuites, IPsec w/ BTNS). But channel binding also serves to detect unwanted proxies -- not wanted by the app, but maybe wanted by the user. Channel binding has also inspired various token binding schemes to reduce the risk of bearer token compromise. Nico --