unclear wording re: spoofing prevention on network connections

On Fri, Dec 8, 2023 at 05:42:27PM +0000, PG Doc comments form wrote:

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/16/preventing-server-spoofing.html
Description:

When I read:
To prevent spoofing on TCP connections, either use SSL certificates and make
sure that clients check the server's certificate, or use GSSAPI encryption
(or both, if they're on separate connections).

It takes some thought to figure out what "separate connections" are being
referred to. Does it mean separate TLS connection and
non-tls-with-gssapi-encryption?

I have no idea. It was added in this commit:

commit b0b39f72b9
Author: Stephen Frost <sfrost@snowman.net>
Date: Wed Apr 3 15:02:33 2019 -0400

GSSAPI encryption support

On both the frontend and backend, prepare for GSSAPI encryption
support by moving common code for error handling into a separate file.
Fix a TODO for handling multiple status messages in the process.
Eliminate the OIDs, which have not been needed for some time.
...

I have CC'ed the patch author.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

Greetings,

On Sat, Dec 9, 2023 at 17:29 Bruce Momjian <bruce@momjian.us> wrote:

On Fri, Dec 8, 2023 at 05:42:27PM +0000, PG Doc comments form wrote:

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/16/preventing-server-spoofing.html
Description:

When I read:
To prevent spoofing on TCP connections, either use SSL certificates and

make

sure that clients check the server's certificate, or use GSSAPI

encryption

(or both, if they're on separate connections).

It takes some thought to figure out what "separate connections" are being
referred to. Does it mean separate TLS connection and
non-tls-with-gssapi-encryption?

Short answer here is “yes, you understand correctly.”

I have no idea. It was added in this commit:

…

Agreed that the wording isn’t great.

The idea is that you can use both TLS and GSSAPI-with-encryption at the
same time within a given cluster for connections but you wouldn’t use them
on the same connection. Certainly would welcome suggestions as to the best
way to phrase that.

Thanks,

Stephen

On Saturday, December 9, 2023, Stephen Frost <sfrost@snowman.net> wrote:

The idea is that you can use both TLS and GSSAPI-with-encryption at the
same time within a given cluster for connections but you wouldn’t use them
on the same connection. Certainly would welcome suggestions as to the best
way to phrase that.

It isn’t really connection driven though - or even specific to these two
options. The pg_hba.conf file can contain any number of different
authentication methods that are usable simultaneously (from the perspective
of the cluster). But a given login request is only going to match a single
one of those lines; so it isn’t like the client somehow decides during each
login using the same machine and user name which way they are going to
verify who they say they are.

We don’t call out being able to use password and peer simultaneously, the
description and specification of the pg_hba.conf file itself imparts that
information. I’m unclear why these two would warrant a special calling out.

David J.

Greetings,

On Sat, Dec 9, 2023 at 18:02 David G. Johnston <david.g.johnston@gmail.com>
wrote:

On Saturday, December 9, 2023, Stephen Frost <sfrost@snowman.net> wrote:

The idea is that you can use both TLS and GSSAPI-with-encryption at the
same time within a given cluster for connections but you wouldn’t use them
on the same connection. Certainly would welcome suggestions as to the best
way to phrase that.

It isn’t really connection driven though - or even specific to these two
options. The pg_hba.conf file can contain any number of different
authentication methods that are usable simultaneously (from the perspective
of the cluster). But a given login request is only going to match a single
one of those lines; so it isn’t like the client somehow decides during each
login using the same machine and user name which way they are going to
verify who they say they are.

Not sure how it isn’t connection driven- as mentioned, the options are
available and can be used at the same time but only on independent
connections.

Didn’t mean to suggest it was really up to the client. Also- you can use
TLS with GSSAPI, just not with GSSAPI-with-encryption.

We don’t call out being able to use password and peer simultaneously, the

description and specification of the pg_hba.conf file itself imparts that
information. I’m unclear why these two would warrant a special calling out.

Cross verification between client and server with encryption…. Perhaps
SCRAM with channel binding and TLS could also be listed. Password doesn’t
provide this security, nor does LDAP, nor PAM. Peer doesn’t provide
encryption (tho fair that it isn’t really necessary, but that doesn’t make
it meet the criteria or intention of this).

Thanks,

Stephen