Re: BUG #5559: Full SSL verification fails when hostaddr provided

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > Perhaps I was being a bit overzealous in my last response, sorry about
> > that. If the point here is that people who are using hostaddr are in an
> > environment where DNS is non-functional or actively broken, then yes,
> > just bombing out would probably be fine.
>
> Well, if your environment includes broken DNS then you are clearly going
> to get nowhere anyway with Kerberos auth, no?

Yes, that's correct as far as I can tell. There may be a way to get
Kerberos to work just on IP addresses, but I didn't have any success
when trying to force that in my environment.

> The point of hostaddr is
> *not* to try to avoid that problem. Rather, it's to allow the
> application to shift the time expense of the forward DNS lookup to some
> other place than its PQconnect() call. If you've got an app where the
> cost of PQconnect() is that critical, you're likely going to want to
> avoid Kerberos auth anyway, so I don't think it's all that important
> exactly how the two features play together.

I can agree with that in general, I feel we just need to be very clear
that using hostaddr is *only* for that reason, that an IP address *can*
be passed to host, and that using hostaddr should be done judiciously
since it will break Kerberos, GSSAPI, etc.

> As the code stands in HEAD, I think everything is nicely
> self-consistent: host is what we believe the server name is for
> authentication purposes, and hostaddr is an optional pre-looked-up
> address corresponding to that. There is nothing in this suggesting
> that we should be expected to try to generate an authentication name
> from hostaddr alone. In particular, the fact that Kerberos is capable
> of trying to do that is at odds with the other three code paths where
> the server name is needed for authentication. I don't feel any need
> to expose Kerberos' peculiarity here.

Kerberos and GSSAPI act exactly the same in this regard, at a functional
level (even if how it gets there is slightly different), from everything
I've seen with them (and they're supposed to be compatible to boot, so
I'd be suprised if it wasn't the case). One distinction that I'd make
is that while we may feel host is the server name for authentication,
Kerberos, GSSAPI, SSPI, are just going to use that host to get the IP to
do an rDNS lookup to get what *they* feel the hostname for
authentication is, and that's what will be requested from the KDC.

Reviewing what's currently on developer.postgresql.org, here's what I
think the docs would read and what the associated code behavior should
be (which I think it's pretty close to already, but perhaps not
entirely..):

hostaddr

This option is not recommended except in cases where PQconnectdb() must
avoid a host name look-up. host can be used with regular hostnames, IP
addresses, etc, directly.

Numeric IP address of host to connect to. This should be in the
standard IPv4 address format, e.g., 172.28.40.9. If your machine
supports IPv6, you can also use those addresses. TCP/IP communication
is always used when a nonempty string is specified for this parameter.

Using hostaddr instead of host allows the application to avoid a host
name look-up, which might be important in applications with time
constraints. However, Kerberos, GSSAPI, and SSPI depend on being able
to do a host name look-up, and so are disabled when hostaddr is used
without host to prevent a DNS lookup from happening. Full SSL
certificate verification requires the client provide the host name
(XXX: I don't believe this needs to be the case. If you have a
certificate whose CN is an IP address, which I've seen quite a few
times in the past, I don't see any reason to break SSL-based auth
when hostaddr is used; of course, if you care about speed, SSL
negotiation a'int exactly cheap... I don't believe the OpenSSL libs
do any DNS lookups; the user must pass in exactly what is in the CN).

The following rules are used: If host is specified without hostaddr, a
host name lookup occurs. If hostaddr is specified without host, the
value for hostaddr gives the server address. The connection attempt
will fail in any of the cases where a host name is required. If both
host and hostaddr are specified, the value for hostaddr gives the
server address. The value for host is ignored unless needed for
authentication or verification purposes, in which case it will be used
as the host name, and DNS look-ups may occur.
(XXX: They will for Kerberos/GSSAPI/SSPI, I don't think they will for
SSL unless libpq does a lookup, but that shouldn't be the case here,
since hostaddr is populated.)

Also, note that host rather than hostaddr is used to identify the
connection in ~/.pgpass (see Section 31.14).

Thanks,

Stephen