Re: [PATCH v12] GSSAPI encryption support

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.

> In this design, the contents of the Startup Message are the only
> non-authentication related information sent in the clear. This
> contains: username (which we need anyway), database, application_name,
> and I add gss_encrypt.

And any other GUC value that the user has decided to send via PGOPTIONS.
Whatever the merits of assuming that the username is okay to expose to
eavesdroppers, I dislike having to assume that there are not and never
will be any GUCs whose settings are potentially security-sensitive.

I really think you need to fix this so that the true startup packet
is not sent until the connection has been encrypted. People are used
to assuming that's true with SSL encryption, and if GSSAPI is less
secure that's likely to lead to unexpected security weaknesses somewhere
down the line.

regards, tom lane