Peter Eisentraut wrote:
> 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.
Agreed, except I really don't see why the default should be different.
>>> 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.
Yeah, and it has always annoyed me :)
I think it'd be better to just gtet the hostname of the system, and use
that.
>>> 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 ...
Yeah, https requires the cert to be named "localhost". It's a smaller
issue on a Unix system since the http/https ports require root to bind
to them, and if somebody is root no amount of SSL is going to help you
anyway...
//Magnus