Re: [PATCH v12] GSSAPI encryption support

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robbie Harwood <rharwood(at)redhat(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH v12] GSSAPI encryption support
Date: 2016-04-08 02:17:09
Message-ID: CAB7nPqRPK1f4oAStwsy_Ty_Cjjo8U50HF0bRZi86my7va4nVdg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 7, 2016 at 8:20 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robbie Harwood <rharwood(at)redhat(dot)com> writes:
>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>>> Wait a second. So the initial connection-request packet is necessarily
>>> unencrypted under this scheme?
>
>> Yes, by necessity. The username must be sent in the clear, even if only
>> as part of the GSSAPI handshake (i.e., the GSSAPI username will appear
>> in plantext in the GSSAPI blobs which are otherwise encrypted). GSSAPI
>> performs authentication before it can start encryption.
>
> Ugh. I had thought we were putting work into this because it represented
> something we could recommend as best practice, but now you're telling me
> that it's always going to be inferior to what we have already.

It does not seem necessary to have an equivalent of
pqsecure_open_client, just some extra handling in fe-connect.c to set
up the initial context with a proper message handling... Not that
direct anyway. So should the patch be marked as returned with feedback
at this stage?
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2016-04-08 02:33:42 Re: Timeline following for logical slots
Previous Message Michael Paquier 2016-04-08 01:54:48 Re: Fix for OpenSSL error queue bug