Re: [HACKERS] Client Connection redirection support for PostgreSQL

On Tue, Feb 13, 2018 at 5:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> -- might need some defense against the redirected-to server getting
>> the same password as was sent to the original server. Is that a
>> security risk? Does HTTP have a rule about this?
>
> Without having read any of the previous discussion ... I'd say that if the
> redirect info is placed in pg_hba.conf then I would expect a redirect to
> happen before any authentication exchange, so that this is not an issue.
> Perhaps it would be a good security measure for clients to refuse a
> redirect once they've sent any auth-related messages.
>
> But ... pg_hba.conf? Really? Surely that is a completely random and
> inappropriate place to control redirection?

Where would you suggest?

My thought was that if, for example, you migrated one database off of
a multiple database cluster to a new location, you'd want to redirect
anyone trying to connect to that database to the new server, so you
need to put the redirection facility someplace where we can make
decisions about whether or not to redirect based on rules involving
database names. The other things we expose in pg_hba.conf seem like
they could potentially be useful, too, although maybe less so. For
instance, if you've got several standbys (or several masters connected
via some MMR solution) you could redirect connections which come from
the "wrong" IP block to the server to which they are local. I think
of pg_hba.conf as a place where we decide what to do with connections,
and redirecting them seems like one thing we might decide to do.

I hadn't really thought deeply about whether redirection should happen
before or after authentication. For the most part, before seems
better, because it seems a bit silly to force people to authenticate
just so that you can tell them to go someplace else. Also, that would
lead to double authentication, which might for example result in
multiple password prompts, which users might either dislike or find
confusing. The only contrary argument that comes to mind is that
someone could argue that there's a security leakage --- if someone has
a redirect rule that only engages for a particular user or database
name, then you can perhaps guess that the user or database name exists
on the target system, or that in general it's one that they care
about. However, reject rules already have the same exposure.
Similarly, you might also be able to infer something based on the type
of authentication request that you get from the server. So I don't
see this argument as compelling.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company