Peter Eisentraut wrote:
> Magnus Hagander wrote:
>>> I imagine for example, we could invent an additional sslmode of the sort
>>> prefer-but-not-if-local-socket, which could be the default.
>>
>> That parameter is already pretty complex, not sure it's a great idea to
>> make it even more so :(
>
> I think there is a firm difference between complex and having a large
> number of things to choose from. By your definition, a float type would
> be a complex. Uh ... hahah.
>
>> 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. That way you can use that
parameter to control the performance side of things (basically to turn
off SSL on unix sockets so you don't pay the overhead) and you keep
using pg_hba to control the policy (because you still need a localssl
line in pg_hba.conf of course). The client gets to say "i require ssl"
in case it cares. And this is the same client that already knows if it's
connecting over tcp or unix sockets...
>>> The other question is whether sslverify=cn makes sense, but that may be
>>> up to the user to find out.
>>
>> Without finding a way to have that make sense, you don't actually fix
>> the potential MITM problem (at least not in many common scenarios), so I
>> think that needs to be considered before we put anything in.
>
> 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.
> Another thought I had is to somehow employ hostaddr, as in
> "hostaddr=/tmp host=real.hostname.lan".
That seems rather abusive.
> 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.
//Magnus
