From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Robbie Harwood <rharwood(at)redhat(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH v1] GSSAPI encryption support |
Date: | 2015-08-21 13:18:18 |
Message-ID: | CAB7nPqRGQ60PWLb-CLLrvMoQwPAbnu-961W+xGPvG62RMSkcZQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 3, 2015 at 3:22 AM, Robbie Harwood <rharwood(at)redhat(dot)com> 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:
+ <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.
+ 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
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.
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.
Regards,
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-08-21 14:06:44 | Re: Autonomous Transaction is back |
Previous Message | Shulgin, Oleksandr | 2015-08-21 12:39:55 | Re: deparsing utility commands |