Horton

Re: Direct SSL connection with ALPN and HBA rules

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Jacob Champion <jacob.champion@enterprisedb.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-04-23T07:07:32Z
Lists: pgsql-hackers 
On Tue, Apr 23, 2024 at 01:48:04AM +0300, Heikki Linnakangas wrote:
> Here's the patch for that. The error message is:
> 
> "direct SSL connection was established without ALPN protocol negotiation
> extension"

WFM.

> That's accurate, but I wonder if we could make it more useful to a user
> who's wondering what went wrong. I'd imagine that if the server doesn't
> support ALPN, it's because you have some kind of a (not necessarily
> malicious) generic SSL man-in-the-middle that doesn't support it. Or you're
> trying to connect to an HTTPS server. Suggestions welcome.

Hmm.  Is there any point in calling SSL_get0_alpn_selected() in
open_client_SSL() to get the ALPN if current_enc_method is not
ENC_DIRECT_SSL?

In the documentation of PQsslAttribute(), it is mentioned that empty
string is returned for "alpn" if ALPN was not used, however the code
returns NULL in this case:
        SSL_get0_alpn_selected(conn->ssl, &data, &len);
        if (data == NULL || len == 0 || len > sizeof(alpn_str) - 1)
            return NULL;
--
Michael

Commits

  1. Remove option to fall back from direct to postgres SSL negotiation

  2. Reject SSL connection if ALPN is used but there's no common protocol

  3. libpq: Enforce ALPN in direct SSL connections

  4. libpq: If ALPN is not used, make PQsslAttribute(conn, "alpn") == ""

  5. Fix documentation and comments on what happens after GSS rejection

  6. doc: Add note to prevent server spoofing with SCRAM