Re: PQgetssl() and alternative SSL implementations

On 08/19/2014 06:00 PM, Magnus Hagander wrote:
> On Tue, Aug 19, 2014 at 4:48 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> * Heikki Linnakangas (hlinnakangas(at)vmware(dot)com) wrote:
>>> server_cert_valid: Did the server present a valid certificate?
>>> "yes" or "no"
>>>
>>> server_cert_matches_host: Does the Common Name of the certificate
>>> match the host connected to? "yes" or "no"
>>
>> Aren't these questions addressed by sslmode?
>
> Not entirely. You can have sslmode=require and have a matching
> certificate. You don't *have* to have sslmode=verify-full for that.
>
> However, whether it makes *sense* without sslmode is another story -
> but assuming you use something like kerberos for auth, it might. For
> password, you've already lost once you get that far.

Hmm, right, because the client application doesn't get control between
libpq doing the SSL negotiation and sending the password to the server.
So if after connecting you decided that you don't actually trust the
server, you've already sent to password. Not good.

You might think that you could try connecting without password first,
and try again with the password, but that's not safe either, because
there's no guarantee that the second connection reaches the same server
as the first one.

I think we need a callback or new asynchronous polling state after SSL
negotiation but before libpq sends the password to the server. But
that's a separate feature and patch.

- Heikki