Обсуждение: unclear wording re: spoofing prevention on network connections
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?
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