TODO item for protocol revision: Negotiate encryption in connection handshake

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: TODO item for protocol revision: Negotiate encryption in connection handshake
Date: 2014-09-03 10:17:55
Message-ID: 5406EAD3.7070002@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark 2014-09-03 10:23:50 xslt_process deprecated?
Previous Message Heikki Linnakangas 2014-09-03 09:50:51 Re: implement subject alternative names support for SSL connections