Re: SSL over Unix-domain sockets

Regarding using the hostname of the system... There's no such thing.
Interfaces have names, hosts can have multiple interfaces so the can
have multiple names...

I haven't follwes the discussion so I'm not sure if you have an
existing connection. If so you can get the local interface address
from the connection and look up the name for that address. But that
only works if you already have a socket.

--
Greg

On 27 Mar 2009, at 07:49, Magnus Hagander <magnus(at)hagander(dot)net> wrote:

> 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
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers