From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Lev Kokotov <lev(at)hyperparam(dot)ai>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Add "host" to startup packet |
Date: | 2023-04-02 16:33:04 |
Message-ID: | 982450.1680453184@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <stark(at)mit(dot)edu> writes:
> My question is a bit different. How does this interact with TLS SNI.
> Can you just use the SNI name given in the TLS handshake? Should the
> server require them to match? Is there any value to having a separate
> source for this info? Is something similar available in GSSAPI
> authentication?
The idea that I was thinking about was to not hard-wire sending the host
string exactly, but instead to invent another connection parameter along
the line of "send_host = name-to-send". This parallels the situation in
HTTP where the "Host" header doesn't necessarily have to match the actual
transport target. I can think of a couple of benefits:
* Avoid breaking backward compatibility with old servers: if user doesn't
add this option then nothing extra is sent.
* Separating the send_host name would simplify testing scenarios.
Seems like it would depend a lot on your use-case whether you care about
the send_host name matching anything that's authenticated. If you do,
there's a whole lot more infrastructure to build out around pg_hba.conf.
Right now that file is designed on the assumption that it describes
authentication rules for a single "host", but we'd need to generalize
it to describe rules for multiple host values.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-04-02 16:38:32 | Re: regression coverage gaps for gist and hash indexes |
Previous Message | Andres Freund | 2023-04-02 16:24:34 | Re: regression coverage gaps for gist and hash indexes |