On 01.03.24 22:49, Jacob Champion wrote:
If we're interested in ALPN negotiation in the future, we may also
want to look at GREASE [1] to keep those options open in the presence
of third-party implementations. Unfortunately OpenSSL doesn't do this
automatically yet.
If we don't have a reason not to, it'd be good to follow the strictest
recommendations from [2] to avoid cross-protocol attacks. (For anyone
currently running web servers and Postgres on the same host, they
really don't want browsers "talking" to their Postgres servers.) That
would mean checking the negotiated ALPN on both the server and client
side, and failing if it's not what we expect.
I've been reading up on ALPN. There is another thread that is
discussing PostgreSQL protocol version negotiation, and ALPN also has
"protocol negotiation" in the name and there is some discussion in this
thread about the granularity oft the protocol names.
I'm concerned that there appears to be some confusion over whether ALPN
is a performance feature or a security feature. RFC 7301 appears to be
pretty clear that it's for performance, not for security.
Looking at the ALPACA attack, I'm not convinced that it's very relevant
for PostgreSQL. It's basically just a case of, you connected to the
wrong server. And web browsers routinely open additional connections
based on what data they have previously received, and they liberally
send along session cookies to those new connections, so I understand
that this can be a problem. But I don't see how ALPN is a good defense.
It can help only if all other possible services other than http
implement it and say, you're a web browser, go away. And what if the
rogue server is in fact a web server, then it doesn't help at all. I
guess there could be some common configurations where there is a web
server, and ftp server, and some mail servers running on the same TLS
end point. But in how many cases is there also a PostgreSQL server
running on the same end point? The page about ALPACA also suggests SNI
as a mitigation, which seems more sensible, because the burden is then
on the client to do the right thing, and not on all other servers to
send away clients doing the wrong thing. And of course libpq already
supports SNI.
For the protocol negotiation aspect, how does this work if the wrapped
protocol already has a version negotiation system? For example, various
HTTP versions are registered as separate protocols for ALPN. What if
ALPN says it's HTTP/1.0 but the actual HTTP requests specify 1.1, or
vice versa? What is the actual mechanism where the performance benefits
(saving round-trips) are created? I haven't caught up with HTTP 2 and
so on, so maybe there are additional things at play there, but it is not
fully explained in the RFCs. I suppose PostgreSQL would keep its
internal protocol version negotiation in any case, but then what do we
need ALPN on top for?
