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