From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Direct SSL connection with ALPN and HBA rules |
Date: | 2024-04-23 07:07:32 |
Message-ID: | ZideNHji0G4gxmc3@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2024-04-23 08:18:15 | Re: pg_stat_statements and "IN" conditions |
Previous Message | kuroda.keisuke | 2024-04-23 06:44:00 | Add privileges test for pg_stat_statements to improve coverage |