Re: Add "host" to startup packet

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

In response to

Responses

Browse pgsql-hackers by date

  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