On Fri, Nov 21, 2025 at 10:21:41AM -0800, Jacob Champion wrote: > On Fri, Nov 21, 2025 at 9:38 AM Nico Williams <[email protected]> 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...
Well, you're right that if we're talking about a Heartbleed type leak then what I said does not follow. However loss of the TLS server credential's private keys is still close enough to catastrophic. That reminds me of another motivation for channel binding: protection against wayward CAs. In the WebPKI this is reasonably well accomplished by certificate transparency, but it's still nice to be able to use CB to protect against that. In corporate networks (where PG is mostly deployed, no?) this is not that interesting a consideration. > (But I agree with you that most people probably want unique bindings > for the default use case, not end-point bindings.) The situation has changed. In the mid- to late-00s unique CB support was harder to come by. But EP CB is still useful for HTTP applications for reasons having to do with reverse proxies. Nico --
