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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers