Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1anwmG-0005DK-V4 for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Apr 2016 23:22:25 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1anwmG-0004yy-He for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Apr 2016 23:22:24 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1anwkv-0003UA-Ca for pgsql-hackers@postgresql.org; Wed, 06 Apr 2016 23:21:01 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1anwks-0001c7-WC for pgsql-hackers@postgresql.org; Wed, 06 Apr 2016 23:21:00 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id u36NKvCu005487; Wed, 6 Apr 2016 19:20:57 -0400 From: Tom Lane To: Robbie Harwood cc: Stephen Frost , pgsql-hackers@postgresql.org Subject: Re: [PATCH v12] GSSAPI encryption support In-reply-to: References: <20160406112105.GG10850@tamriel.snowman.net> <1530.1459977031@sss.pgh.pa.us> Comments: In-reply-to Robbie Harwood message dated "Wed, 06 Apr 2016 18:15:37 -0400" Date: Wed, 06 Apr 2016 19:20:57 -0400 Message-ID: <5486.1459984857@sss.pgh.pa.us> X-Pg-Spam-Score: -2.9 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Robbie Harwood writes: > Tom Lane 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 (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers