Magnus Hagander wrote:
>>> 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.
>
> Good point. OTOH, client behavior can be controlled now fine by setting
> it to "require" or "prefer" - I think that's enough.
>
> However, we might want a simple ssl_local=true/false parameter on the
> server that turns it on/off completely.
But the choice is that of the client:
1) I want a connection with server authentication. or
2) I want a fast connection, I don't care about server authentication.
No configuration knob in the server can ever solve this.
Of course the client has all the sslmode parameters to make its wishes
known, but the point here is that the *default* should possibly be a
different one in the case of Unix-domain sockets.
>> 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?
>
> Yes on both. Except the current version of libpq doesn't support this
> :-( I was planning to add it (and still do), but the way to do it
> appears to be fairly complex and completely undocumented. I did some
> searching to find examples of it, but never followed through.
After further thought, this is probably not the right solution anyway.
The security of all this depends on the fact that each common name only
exists once within the scope of a CA. The socket name or directory,
however, is more or less them same for everyone.
>> Another thought I had is to somehow employ hostaddr, as in
>> "hostaddr=/tmp host=real.hostname.lan".
>
> That seems rather abusive.
True, but Kerberos more or less works this way. hostaddr is where to
connect, host is what to use for authentication.
>> Another^2 thought is to just examine the certificate for the local host
>> name, which the client can find out itself.
>
> That could work. In which case we should probably consider doing the
> same thing for "localhost" or "127.0.0.1" connections.
Hmm, as per my statement above, this would be the right thing to do.
But I think https works differently. Tricky ...
