Re: SSL over Unix-domain sockets

Magnus Hagander wrote:
>> I imagine for example, we could invent an additional sslmode of the sort
>> prefer-but-not-if-local-socket, which could be the default.
> 
> That parameter is already pretty complex, not sure it's a great idea to
> make it even more so :(

I think there is a firm difference between complex and having a large 
number of things to choose from.  By your definition, a float type would 
be a complex.  Uh ... hahah.

> Perhaps it's enough to add a "localssl" row to pg_hba.conf?

That defeats the point, I think.  You don't want the server to determine 
whether the client should verify the server.

>> The other question is whether sslverify=cn makes sense, but that may be
>> up to the user to find out.
> 
> Without finding a way to have that make sense, you don't actually fix
> the potential MITM problem (at least not in many common scenarios), so I
> think that needs to be considered before we put anything in.

Yeah, the problem is that there is only one server certificate.  Is it 
possible/does it make sense to add an additional cn to the certificate?

Another thought I had is to somehow employ hostaddr, as in 
"hostaddr=/tmp host=real.hostname.lan".

Another^2 thought is to just examine the certificate for the local host 
name, which the client can find out itself.