<acronym>GSSAPI</acronym> Session Encryption

Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZOKA-0006QO-RB for pgsql-hackers@arkaria.postgresql.org; Tue, 08 Sep 2015 19:12:59 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZZOK9-0001Qr-H1 for pgsql-hackers@arkaria.postgresql.org; Tue, 08 Sep 2015 19:12:57 +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) (envelope-from ) id 1ZZOK7-0001Qi-Fe for pgsql-hackers@postgresql.org; Tue, 08 Sep 2015 19:12:55 +0000 Received: from mx1.redhat.com ([209.132.183.28]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZZOK3-0005n2-0O for pgsql-hackers@postgresql.org; Tue, 08 Sep 2015 19:12:53 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 6C43D8E3E9; Tue, 8 Sep 2015 19:12:49 +0000 (UTC) Received: from localhost (vpn-57-8.rdu2.redhat.com [10.10.57.8]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t88JCmFg004210; Tue, 8 Sep 2015 15:12:48 -0400 From: Robbie Harwood To: Michael Paquier Cc: PostgreSQL mailing lists Subject: Re: [PATCH v2] GSSAPI encryption support In-Reply-To: References:

User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Tue, 08 Sep 2015 15:12:49 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Pg-Spam-Score: -6.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 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Michael Paquier writes: > On Fri, Jul 3, 2015 at 3:22 AM, Robbie Harwood wrote: > >> Hello -hackers, >> >> As previously discussed on this list, I have coded up GSSAPI encryption >> support. If it is easier for anyone, this code is also available for >> viewing on my github: >> >> https://github.com/postgres/postgres/compare/master...frozencemetery:feature/gssencrypt >> >> Fallback support is present in both directions for talking to old client >> and old servers; GSSAPI encryption is by default auto-upgraded to where >> available (for compatibility), but both client and server contain >> settings for requiring it. >> >> There are 8 commits in this series; I have tried to err on the side of >> creating too much separation rather than too little. A patch for each >> is attached. This is v1 of the series. > > I just had a quick look at this patch, and here are some comments: > + > + If the client has probed GSSAPI encryption support > and > + the connection is GSSAPI-authenticated, then after > the > + server sends AuthenticationOk, all traffic between the client and > server > + will be GSSAPI-encrypted. Because > + GSSAPI does not provide framing, > + GSSAPI-encrypted messages are modeled after > protocol-3 > + messages: the first byte is the caracter g, then four bytes of length, > and > + then an encrypted message. > + > Message formats should be described in protocol.sgml in the section for > message formats. > > + network. In the pg_hba.conf file, the GSS authenticaion > + method has a parameter to require encryption; otherwise, connections > + will be encrypted if available and requiested by the client. On the > s/authenticaion/authentication > s/requiested/requested > > + Whether to require GSSAPI encryption. Default is off, which causes > + GSSAPI encryption to be enabled if available and requested for > + compatability with old clients. It is recommended to set this > unless > + old clients are present. > s/compatability/compatibility As promised, here's a V2 to address your issues with comments. I haven't heard back on the issues you found in testing, so no other changes are present. This means that only the last patch has changed. For convenience, I will therefore only provide this new patch. I have also updated the version available from my github. Thanks! --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=v2-8-Document-GSSAPI-encryption.patch Content-Transfer-Encoding: quoted-printable From=202e9017a572a3097fecf2f7e53bf5f9aabf6ae36d Mon Sep 17 00:00:00 2001 From: "Robbie Harwood (frozencemetery)" Date: Mon, 29 Jun 2015 15:29:36 -0400 Subject: [PATCH] Document GSSAPI encryption =2D-- doc/src/sgml/client-auth.sgml | 19 ++++++++-- doc/src/sgml/libpq.sgml | 12 +++++++ doc/src/sgml/protocol.sgml | 82 +++++++++++++++++++++++++++++++++++++++= +++- doc/src/sgml/runtime.sgml | 20 ++++++++++- 4 files changed, 128 insertions(+), 5 deletions(-) diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml index ba04bdf..0863468 100644 =2D-- a/doc/src/sgml/client-auth.sgml +++ b/doc/src/sgml/client-auth.sgml @@ -913,9 +913,10 @@ omicron bryanh guest1 GSSAPI with Kerberos authentication according to RFC 1964. GSSAPI provides automatic authentication (single sign-on) for systems =2D that support it. The authentication itself is secure, but the =2D data sent over the database connection will be sent unencrypted unle= ss =2D SSL is used. + that support it. The authentication itself is secure, and GSSAPI can be + used for connection encryption as well (see the + require_encrypt parameter below); SSL + can also be used for connection security. =20 @@ -1046,6 +1047,18 @@ omicron bryanh guest1 + + + require_encrypt + + + Whether to require GSSAPI encryption. Default is off, which causes + GSSAPI encryption to be enabled if available and requested for + compatibility with old clients. It is recommended to set this unl= ess + old clients are present. + + + diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml index 7940ef2..b80d29d 100644 =2D-- a/doc/src/sgml/libpq.sgml +++ b/doc/src/sgml/libpq.sgml @@ -1356,6 +1356,18 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname =20 + + gss_enc_require + + + If set, whether to require GSSAPI encryption support from the remo= te + server. Defaults to unset, which will cause the client to fall bac= k to + not using GSSAPI encryption if the server does not support encrypt= ion + through GSSAPI. + + + + service diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml index 42e9497..15e0014 100644 =2D-- a/doc/src/sgml/protocol.sgml +++ b/doc/src/sgml/protocol.sgml @@ -1295,6 +1295,42 @@ of authentication checking. + + + <acronym>GSSAPI</acronym> Session Encryption + + + If PostgreSQL was built with + GSSAPI and GSSAPI support, traff= ic + can also be encrypted using GSSAPI. To force encryp= tion + using GSSAPI, set require_encrypt in + pg_hba.conf. + + + + In order to probe for GSSAPI support, the client wi= ll + include in their StartupMessage the parameter gss_encrypt. If the serv= er + does not support GSSAPI or GSSAPI + encryption, the server will error the connection; otherwise, it contin= ues + as normal. The client may retry the connection + without GSSAPI encryption support depending on its + settings. If the client does not probe support, depending on settings + in pg_hba.conf, the server may drop + GSSAPI-authenticated connections without encryption. + + + + If the client has probed GSSAPI encryption support = and + the connection is GSSAPI-authenticated, then after = the + server sends AuthenticationOk, all traffic between the client and serv= er + will be GSSAPI-encrypted. See message formats abov= e. + + + + It is valid to use GSSAPI encryption over + SSL-encrypted connections. + + =20 @@ -2191,7 +2227,9 @@ Notice that although each message includes a byte cou= nt at the beginning, the message format is defined so that the message end can be found without reference to the byte count. This aids validity checking. (The CopyData message is an exception, because it forms part of a data stream; the conte= nts =2Dof any individual CopyData message cannot be interpretable on their own.) +of any individual CopyData message cannot be interpretable on their own. = The +GSSAPI message type is another exception because GSSAPI does not require +payloads to include length information.) =20 @@ -3921,6 +3959,48 @@ FunctionCallResponse (B) =20 + + +GSSAPI (F & B) + + + + + + + Byte1('g') + + + + Identifies the message as GSSAPI-encrypted data. + + + + + + Int32 + + + + Length of message contents in bytes, including self. + + + + + + Byten + + + + GSSAPI-encrypted data. Once decrypted, will be in a valid + message format. + + + + + + + =20 diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml index 6d5b108..0d65fd6 100644 =2D-- a/doc/src/sgml/runtime.sgml +++ b/doc/src/sgml/runtime.sgml @@ -1868,7 +1868,7 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433 =20 =2D To prevent spoofing on TCP connections, the best solution is to use + To prevent spoofing on TCP connections, one possible solution is to use SSL certificates and make sure that clients check the server's certific= ate. To do that, the server must be configured to accept only hostssl connections (verify-full and have the appropriate root certificate file installed (). + + + Another way of preventing spoofing on TCP connections is to use GSSAPI + encryption. In order to force all GSSAPI connections to be encrypted, o= ne + should set require_encrypt in pg_hba.conf on G= SS + connections. Then, using Kerberos, the client and server will mutually + authenticate, and the connection will be encrypted once the authenticat= ion + step is complete. + =20 @@ -1993,6 +2002,15 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433 connect to servers only via SSL. Stunnel or SSH can also be used to encrypt transmissions. + + + GSSAPI connections can also encrypt all data sent across the network= . In + the pg_hba.conf file, the GSSAPI authentication method = has + a parameter to require encryption; otherwise, connections will be + encrypted if available and requested by the client. On the client si= de, + there is also a parameter to require GSSAPI encryption support from = the + server. + =20 =2D-=20 2.5.1 --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJV7zMyAAoJECUy+RdqlaRCfR8QAJedMDgxrz0PqhPQf0WMKLMG +tScjs5VgPWrXu+wSimC9QRXsxFxyIy4jQSmfqqNCBGDi5JEYTkgsXwxLCBC9f20 ev0u9z+7N1E9kIGvChj9s2TtYWt/02GCr+U14Coe1y9UdIZFU3ga+/bw5JK6+V4h D6uViGbVdpz9Y2j5eKLTWW1SWnOEbIP3kkMthRfRMg5NzJcGN1I+BPkBfH2ZZyoD xkygLA1N8KGppm8dTauhlrZ7ofSBZaA/N8q1IEwK7E8/KEWe3pzEeyU7JlOb1VsV Q0kk3JQz/pEbO6YRNuBcn3tj27ONMJFW1rxI51rQW1D/e+XLaFQLs4vjL6bDcS2p FeCRYTwRed5aMO/IDNnk2gCoBYrCUiLIw9V8VWKK8M2RRKeKEPSC4hM7qyLlMweM WlqkwUex2F5YjPEHGurwH2YHwd8aiemFPiHg1w/VYtOHawP5+T4Hc5l1AV8mun8F ohk6q4/uPuK9vXvLDbog25Vgox5IQpuCysRIwbCU/Rq7YbcPSRiInK/AU4dG1ADL 9NpqJwhzbv1M3BE26ImlaEAd4KVhLAZNVpM8Km60uuZI5VIxHY2vnnEkzQkoOba0 7L0nXW8kPQQEalfLfoatcVA1lQXDNeJnDidfjsIJeh7yQWswnRVVzK2mjJ10Jb8F 70vtqezr9HrZ2RxpNHTu =91OT -----END PGP SIGNATURE----- --==-=-=--