Re: TODO item for protocol revision: Negotiate encryption in connection handshake - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: TODO item for protocol revision: Negotiate encryption in connection handshake
Date
Msg-id CABUevEyEXm-GM7jK-Y+kGzp4grgnTxqXadOcQ7KPnY130PcGnA@mail.gmail.com
Whole thread Raw
In response to TODO item for protocol revision: Negotiate encryption in connection handshake  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
On Wed, Sep 3, 2014 at 12:17 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
> Hi all
>
> Another thing I keep on wishing Pg's protocol had is an after-connection
> negotiation for transport encryption, like STARTTLS .
>
> Right now, the client has to guess if the server requires, permits, or
> rejects SSL, and decide whether to start with SSL or !SSL. If that
> fails, it has to try the other one.
>
> The way it's managed in pg_hba.conf means that users usually just get
> confusing errors like:
>
> FATAL: no pg_hba.conf entry for host "192.168.0.1", user "postgres",
> database "whatever", SSL off
>
> without the client app being given the opportunity to be told by the
> server "Please upgrade to transport level security before proceeding".
>
> I like how IMAP does it, where the server announces its capabilities.
>
> Reasonable to aim for in a protocol v4?

Yeah, it definitely does I think. Should be in the form of some more
generic "capabilities negotiation" though, even if we only have SSL to
begin with.

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Escaping from blocked send() reprised.
Next
From: Vik Fearing
Date:
Subject: Re: GSoC on WAL-logging hash indexes