Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M279820=pgsql-hackers-arkari@postgresql.org>)
 id 1ZSrfI-0007lY-SE
 for pgsql-hackers@arkaria.postgresql.org; Fri, 21 Aug 2015 19:07:48 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
 by malur.postgresql.org with smtp (Exim 4.84) (envelope-from
 <pgsql-hackers-owner+M279820=pgsql-hackers-arkari@postgresql.org>)
 id 1ZSrfI-0008IJ-DL
 for pgsql-hackers@arkaria.postgresql.org; Fri, 21 Aug 2015 19:07:48 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
 by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
 (Exim 4.84) (envelope-from <rharwood@redhat.com>) id 1ZSre0-0006oX-2J
 for pgsql-hackers@postgresql.org; Fri, 21 Aug 2015 19:06:28 +0000
Received: from mx1.redhat.com ([209.132.183.28])
 by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
 (Exim 4.84) (envelope-from <rharwood@redhat.com>) id 1ZSrdw-000437-D8
 for pgsql-hackers@postgresql.org; Fri, 21 Aug 2015 19:06:27 +0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
 (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
 by mx1.redhat.com (Postfix) with ESMTPS id 72C528CF42;
 Fri, 21 Aug 2015 19:06:20 +0000 (UTC)
Received: from localhost (unused [10.10.51.158] (may be forged))
 by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 t7LJ6KCt024323; Fri, 21 Aug 2015 15:06:20 -0400
From: Robbie Harwood <rharwood@redhat.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH v1] GSSAPI encryption support
In-Reply-To: 
 <CAB7nPqRGQ60PWLb-CLLrvMoQwPAbnu-961W+xGPvG62RMSkcZQ@mail.gmail.com>
References: <jlg1tgq1ktm.fsf@thriss.redhat.com>
 <CAB7nPqRGQ60PWLb-CLLrvMoQwPAbnu-961W+xGPvG62RMSkcZQ@mail.gmail.com>
User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1
 (x86_64-pc-linux-gnu)
Date: Fri, 21 Aug 2015 15:06:15 -0400
Message-ID: <jlgmvxk31i0.fsf@thriss.redhat.com>
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.24
X-Pg-Spam-Score: -7.7 (-------)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

--=-=-=
Content-Type: text/plain

Michael Paquier <michael.paquier@gmail.com> writes:

> On Fri, Jul 3, 2015 at 3:22 AM, Robbie Harwood <rharwood@redhat.com> wrote:
>
>> 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:

Hi!  Thanks for taking it for a spin.

> +   <para>
> +    If the client has probed <acronym>GSSAPI</acronym> encryption support and
> +    the connection is <acronym>GSSAPI</acronym>-authenticated, then after the
> +    server sends AuthenticationOk, all traffic between the client and server
> +    will be <acronym>GSSAPI</acronym>-encrypted. Because
> +    <acronym>GSSAPI</acronym> does not provide framing,
> +    <acronym>GSSAPI</acronym>-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.
> +   </para>
>
> Message formats should be described in protocol.sgml in the section for
> message formats.

ACK.  In next version of patch.

> +      network. In the <filename>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

Thanks for catching these.  They'll be included in a new version of the
series, which I'll post once you and I have resolved the issue at the
bottom.

> Going through the docs, the overall approach taken by the patch looks neat,
> and the default values as designed for both the client and the server are
> good things to do. Now actually looking at the code I am suspecting that
> some code portions could be largely simplified in the authentication
> protocol code, though I don't have the time yet to look at that in details.

If there are ways to make it simpler without sacrificing clarity, I
welcome them.  Fresh eyes could definitely help with that!

> Also, when trying to connect with GSSAPI, I found the following problem:
> psql: lost synchronization with server: got message type "S", length 22
> This happens whatever the value of require_encrypt on server-side is,
> either 0 or 1.

Well that's not good!  Since I'm not seeing this failure (even after
rebuilding my setup with patches applied to master), can you give me
more information here?  Since it's independent of require_encrypt, can
you verify it doesn't happen on master without my patches?  What
messages went over the wire to/from the server before this occurred (and
what was it trying to send at the time)?  Did you have valid
credentials?

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJV13anAAoJECUy+RdqlaRCPcwP/R0xUDioBzHIGEN8C8IArRJV
zigI99FD7C2iltR8HYiKy+OuwhDW7FGFcFCZVtAwpCmyEGsWgF2ioQkKUGRyODUA
IEktUXxt2yTe4Vz1LWrNgDFRTYGC4PcT34eRVkOfpb6H3FfKOtbYMf+DTTVfMiuH
ZTxXFNQexVrTJm5QLVyZVYo2+JWS1D6+w464kSzekMFAK0uNJVSrvT4tSVeIBhM8
ha0xmnJv1z+mS/cLPAXZ/fanVWs29Lv6Gj04z3lnI4gF/UwHPKv0fzx3wnizONse
DuJqRguroJ/CNpAm5wjoUrtw9Zebo2PTrN78iN78AaLTt4cxkJryxR4S6n+UAPJJ
JtUs5OXWOsbX8m1/moouiG9G0RCng7PDu3QEE9rPyaE9aYRyBP3cle1A1VwWeStD
FXU1LlHxjNfJsyM9sQRVJ3KWIrp8B9Ux6dLqfLV8zFSnpYRSpIGwpIPOUQLZlLex
r5QOjlwRjiRK8iPWan7rBQFIQW7FqYSZhqFap6wXplFkxgJUZUR6lXmbhBi+JONT
dL8dPM7+wGJKIpqmVD/0AnFKjNDa/h/pL/aJgZgQJf6gdAyYGhZjTnOhPs7cYP33
ehNkfDWhlWKEgcKlxLWH2Sr94GCOQQ7KqqiD/Ghjv4zUwvRssTC4DlDs2D2e/Lm+
z6oN2n5wVswOH8CPkchy
=ZhBr
-----END PGP SIGNATURE-----
--=-=-=--