On 29/04/2024 20:10, Ranier Vilela wrote:
> Hi,
>
> With TLS 1.3 and others there is possibly a security flaw using ALPN [1].
>
> It seems to me that the ALPN protocol can be bypassed if the client does
> not correctly inform the ClientHello header.
>
> So, the suggestion is to check the ClientHello header in the server and
> terminate the TLS handshake early.
Sounds to me like it's working as designed. ALPN in general is optional;
if the client doesn't request it, then you proceed without it. We do
require ALPN for direct SSL connections though. We can, because direct
SSL connections is a new feature in Postgres. But we cannot require it
for the connections negotiated with SSLRequest, or we break
compatibility with old clients that don't use ALPN.
There is a check in direct SSL mode that ALPN was used
(ProcessSSLStartup in backend_startup.c):
> if (!port->alpn_used)
> {
> ereport(COMMERROR,
> (errcode(ERRCODE_PROTOCOL_VIOLATION),
> errmsg("received direct SSL connection request without ALPN protocol negotiation
extension")));
> goto reject;
> }
That happens immediately after the SSL connection has been established.
Hmm. I guess it would be better to abort the connection earlier, without
completing the TLS handshake. Otherwise the client might send the first
message in wrong protocol to the PostgreSQL server. That's not a
security issue for the PostgreSQL server: the server disconnects without
reading the message. And I don't see any way for an ALPACA attack when
the server ignores the client's message. Nevertheless, from the point of
view of keeping the attack surface as small as possible, aborting
earlier seems better.
--
Heikki Linnakangas
Neon (https://neon.tech)