Robbie Harwood <rharw...@redhat.com> writes: > Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers