| From: | Nico Williams <nico(at)cryptonector(dot)com> |
|---|---|
| To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, * Neustradamus * <neustradamus(at)hotmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: RFC 9266: Channel Bindings for TLS 1.3 support |
| Date: | 2025-11-21 17:38:04 |
| Message-ID: | aSCjfO0FuGJvcWy/@ubby |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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(at)iki(dot)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
--
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nico Williams | 2025-11-21 17:38:41 | Re: RFC 9266: Channel Bindings for TLS 1.3 support |
| Previous Message | Nico Williams | 2025-11-21 17:32:02 | Re: RFC 9266: Channel Bindings for TLS 1.3 support |