Peter Eisentraut wrote:
> Bruce Momjian wrote:
>> In testing an SSL patch, I found that if I use 'sslmode=require' in the
>> libpq connection string, it does not use SSL over a unix-domain socket.
>>
>> libpq should either use SSL (which I don't think it can), or error out,
>> or we should at least document this behavior.
>
> We discussed this before 8.3 already. It might be time to address this
> now that the SSL support is being redesigned.
>
> SSL over Unix-domain sockets with libpq works perfectly fine if you
> remove the code in libpq and/or the postmaster (forgot which exactly)
> that thinks that it doesn't work.
Well, "perfectly fine" I'm not sure. What would you verify the CN in the
certificate against, if there is no hostname?
And doing this CN verification would actually be the only reason you'd
want to use SSL over Unix sockets, I think. If we can figure out
something "reasonable" to do here, it might be worthwhile to support it.
> The issue previously was the libpq defaults to sslmode=prefer and that
> would impose a noticeable connection initiation overhead on everyone's
> Unix-domain socket uses. You could make it use SSL in require mode, but
> it seems weird that prefer mode would end up doing something different
> than require mode.
>
> Maybe Magnus has an opinion on how we could make this fit into the new
> scheme of things. I assume since we require certificates to be set up
> now, SSL will by default be off and so using it over Unix-domain sockets
> when enabled would not be in the common path, which was the objection
> previously.
The only difference is that we require certificate or CA on the client.
Well, not require, but by default request it. We have always required a
certificate on the server.
SSL is still controlled by the "ssl=on" on the server side primarily.
//Magnus