Re: RFC 9266: Channel Bindings for TLS 1.3 support - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: RFC 9266: Channel Bindings for TLS 1.3 support
Date
Msg-id CAOYmi+kzkVyS5=SnjjTFpRsAmTK9amXgio9iOeo-gWYEkGLtOw@mail.gmail.com
Whole thread Raw
In response to Re: RFC 9266: Channel Bindings for TLS 1.3 support  (Nico Williams <nico@cryptonector.com>)
Responses Re: RFC 9266: Channel Bindings for TLS 1.3 support
List pgsql-hackers
On Fri, Nov 21, 2025 at 9:28 AM Nico Williams <nico@cryptonector.com> wrote:
> The main benefit of "end-point"-style CB data is that it's easier to
> deal with server-side ("reverse") proxies.  That's primarily a benefit
> for HTTP applications, and almost certainly not relevant to PG (unless
> there _are_ reverse proxies for PG -- are there?).

There is some newer/in-progress work that's beginning to converge on
that, yes (direct-mode SSL+ALPN, server-side SNI, others?).

On Fri, Nov 21, 2025 at 9:38 AM Nico Williams <nico@cryptonector.com> wrote:
> 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.

Why does that follow? I would think that the avenues for leaking a key
in today's containerized world are much different from the avenues for
leaking database credentials. Or do I misunderstand what you mean...?
I want to make sure I haven't misled people on our SCRAM guarantees...

(But I agree with you that most people probably want unique bindings
for the default use case, not end-point bindings.)

Thanks,
--Jacob



pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Buffer locking is special (hints, checksums, AIO writes)
Next
From: Etsuro Fujita
Date:
Subject: Re: Import Statistics in postgres_fdw before resorting to sampling.