Re: [PATCH v1] GSSAPI encryption support - Mailing list pgsql-hackers

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?