Message-ID: <53F37DF3.5070107@vmware.com>
Date: Tue, 19 Aug 2014 19:40:19 +0300
From: Heikki Linnakangas <hlinnakangas@vmware.com>
Organization: VMware
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Magnus Hagander <magnus@hagander.net>, Stephen Frost <sfrost@snowman.net>
CC: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: PQgetssl() and alternative SSL implementations
References: <53F1E989.8020609@vmware.com>
	<20140819144841.GA16422@tamriel.snowman.net>
 <CABUevEyjj1W=R++RK5AcbcOheG0R48PqpV+h4UtJunNb6D6YYA@mail.gmail.com>
In-Reply-To: 
 <CABUevEyjj1W=R++RK5AcbcOheG0R48PqpV+h4UtJunNb6D6YYA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 08/19/2014 06:00 PM, Magnus Hagander wrote:
> On Tue, Aug 19, 2014 at 4:48 PM, Stephen Frost <sfrost@snowman.net> wrote:
>> * Heikki Linnakangas (hlinnakangas@vmware.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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers