Horton

Re: Direct SSL connection with ALPN and HBA rules

Heikki Linnakangas <hlinnaka@iki.fi>

View thread View on postgr.es
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Michael Paquier <michael@paquier.xyz>
Cc: Jacob Champion <jacob.champion@enterprisedb.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-04-29T09:43:18Z
Lists: pgsql-hackers 
On 23/04/2024 10:07, Michael Paquier wrote:
> 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;

Good catch. I changed the code to return an empty string, as the 
documentation says.

I considered if NULL or empty string would be better here. The docs for 
PQsslAttribute also says:

"Returns NULL if the connection does not use SSL or the specified 
attribute name is not defined for the library in use."

If a caller wants to distinguish between "libpq or the SSL library 
doesn't support ALPN at all" from "the server didn't support ALPN", you 
can tell from whether PQsslAttribute returns NULL or an empty string. So 
I think an empty string is better.

-- 
Heikki Linnakangas
Neon (https://neon.tech)

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