BUG #5559: Full SSL verification fails when hostaddr provided

The following bug has been logged online:

Bug reference: 5559
Logged by: Christopher Head
Email address: chris2k01(at)hotmail(dot)com
PostgreSQL version: 8.4.4
Operating system: Gentoo Linux i386, kernel 2.6.34
Description: Full SSL verification fails when hostaddr provided
Details:

When establishing a connection to a PostgreSQL server using a connection
string, there are two parameters that can be provided to specify where to
connect to: "host" and "hostaddr". If both are provided, the documentation
states that "hostaddr" is used to actually establish the socket (thus
avoiding
a potentially-expensive DNS lookup), while "host" is used for doing some
Kerberos stuff.

It makes sense that in the case of an SSL connection with
"sslmode=verify-full" (check that the server's certificate is signed by a
trusted CA and has the
correct hostname), if both parameters are provided, that "host" also be used
for certificate checking. Unfortunately, as per line 536 of the file
fe-secure.c in the PostgreSQL sources, if hostaddr is specified, SSL full
verification just plain fails without trying at all. I suspect this line
should be "if (!conn->pghost)" instead of "if (conn->pghostaddr)".

There is no security vulnerability here, since "host" is a configuration
slot intended to hold some kind of semantic name for the host as understood
by the
user (which is precisely what you want to verify a certificate
against—that you are connecting to the semantically-correct server, not
simply the one that
happens to have the right IP address), while "hostaddr" is merely a
network-level implementation detail which should be essentially meaningless
to
the user.

Although it's easy enough to avoid the issue when using psql (just don't
include "hostaddr" at all), this unfortunately causes all connections to
fail
when using pgAdmin3, as that program apparently does its own DNS lookups and
always attaches a hostaddr (thus causing the confusing message "verified
SSL
connections are only supported when connecting to a host name" even if one
*does* in fact specify a host*name* in the appropriate place!)