SV: Problem with ssl and psql in Postgresql 13

SV: Problem with ssl and psql in Postgresql 13

Re: Problem with ssl and psql in Postgresql 13

I wrote:
> So this directly explains the original report: if the only applicable
> pg_hba.conf entry is "hostssl", right here is where libpq will see
> that error, and it will go around and fail again because the next
> try uses neither GSS nor SSL.

> However, in the tests Mikael ran after backing that pg_hba.conf entry
> off to just "host", pg_hba wouldn't have caused an authentication-stage
> failure, so it's not so clear why we'd have looped back at this step.
> We'd need to explain the later cases to have a full theory.  It's
> plenty plausible that something else caused an auth-stage failure,
> but if so, why would the second GSS-free try work?

So, after actually trying to reproduce this error, the answer
to that question is blindingly obvious:

2020-12-26 15:34:01.425 EST [1853] FATAL:  GSSAPI encryption can only be used with gss, trust, or reject authentication methods

You'll recall that Mikael was using PAM auth; I hit this with
just regular password auth.

So, given that the server and client are in a Kerberos-enabled
environment, they'll negotiate a GSS-encrypted connection (that the
user did not ask for), then the server refuses to use it because of
the above restriction, then libpq drops down to a new connection
... which, because of this allow_ssl_try bug, is not SSL-encrypted
but just plain, even if the user had set sslmode=require.

I'd say this is not just a nasty bug, but verges on requiring a CVE.

I'm also of the opinion that this restriction on authentication type
is useless damfool nannyism, and we should just drop it.  Sure, if
you've managed to GSS-ify the connection then the client is known
to the Kerberos system, but that proves little about whether the
client is entitled to log into the database under the username
he's asking for.  Why should we restrict how that auth is done?
Even if there's some reason to do so, it's hard to believe that the
reason justifies forcing a whole new round of encrypted-connection
setup to switch to SSL encryption, when we have a perfectly good
encrypted connection already.

			regards, tom lane

PS: AFAICS, it's also undocumented useless damfool nannyism.

Re: Problem with ssl and psql in Postgresql 13

Here's a draft patch for the libpq-side issues.  The core of the
fix is to get rid of pqsecure_open_gss's clearing of allow_ssl_try,
and instead check whether GSS encryption is already enabled before
we try to enable SSL.  While I was at it I also fixed the places
where we drop an attempted GSS connection: they should set
need_new_connection = true rather than incompletely doing it for
themselves.  Notably that coding misses resetting auth_req_received
and password_needed; the consequences of that are minor but not zero.

There are things to fix on the server side, and the documentation
needs work, but this should be enough to solve Mikael's problem
if he's in a position to apply the patch locally.

			regards, tom lane

diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index 7d04d3664e..ec7c4c5e87 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -2909,11 +2909,16 @@ keep_going:						/* We will come back to here until there is
 #ifdef USE_SSL
 
 				/*
-				 * If SSL is enabled and we haven't already got it running,
-				 * request it instead of sending the startup message.
+				 * If SSL is enabled and we haven't already got encryption of
+				 * some sort running, request SSL instead of sending the
+				 * startup message.
 				 */
 				if (conn->allow_ssl_try && !conn->wait_ssl_try &&
-					!conn->ssl_in_use)
+					!conn->ssl_in_use
+#ifdef ENABLE_GSS
+					&& !conn->gssenc
+#endif
+					)
 				{
 					ProtocolVersion pv;
 
@@ -3042,6 +3047,7 @@ keep_going:						/* We will come back to here until there is
 						}
 						/* Otherwise, proceed with normal startup */
 						conn->allow_ssl_try = false;
+						/* We can proceed using this connection */
 						conn->status = CONNECTION_MADE;
 						return PGRES_POLLING_WRITING;
 					}
@@ -3139,8 +3145,7 @@ keep_going:						/* We will come back to here until there is
 						 * don't hang up the socket, though.
 						 */
 						conn->try_gss = false;
-						pqDropConnection(conn, true);
-						conn->status = CONNECTION_NEEDED;
+						need_new_connection = true;
 						goto keep_going;
 					}
 
@@ -3158,6 +3163,7 @@ keep_going:						/* We will come back to here until there is
 						}
 
 						conn->try_gss = false;
+						/* We can proceed using this connection */
 						conn->status = CONNECTION_MADE;
 						return PGRES_POLLING_WRITING;
 					}
@@ -3186,8 +3192,7 @@ keep_going:						/* We will come back to here until there is
 					 * the current connection to do so, though.
 					 */
 					conn->try_gss = false;
-					pqDropConnection(conn, true);
-					conn->status = CONNECTION_NEEDED;
+					need_new_connection = true;
 					goto keep_going;
 				}
 				return pollres;
@@ -3354,10 +3359,9 @@ keep_going:						/* We will come back to here until there is
 					 */
 					if (conn->gssenc && conn->gssencmode[0] == 'p')
 					{
-						/* postmaster expects us to drop the connection */
+						/* only retry once */
 						conn->try_gss = false;
-						pqDropConnection(conn, true);
-						conn->status = CONNECTION_NEEDED;
+						need_new_connection = true;
 						goto keep_going;
 					}
 #endif
diff --git a/src/interfaces/libpq/fe-secure-gssapi.c b/src/interfaces/libpq/fe-secure-gssapi.c
index bfc0f55214..9416306eea 100644
--- a/src/interfaces/libpq/fe-secure-gssapi.c
+++ b/src/interfaces/libpq/fe-secure-gssapi.c
@@ -647,17 +647,14 @@ pqsecure_open_gss(PGconn *conn)
 	if (output.length == 0)
 	{
 		/*
-		 * We're done - hooray!  Kind of gross, but we need to disable SSL
-		 * here so that we don't accidentally tunnel one over the other.
+		 * We're done - hooray!  Set flag to tell the low-level I/O routines
+		 * to do GSS wrapping/unwrapping.
 		 */
-#ifdef USE_SSL
-		conn->allow_ssl_try = false;
-#endif
+		conn->gssenc = true;
 
 		/* Clean up */
 		gss_release_cred(&minor, &conn->gcred);
 		conn->gcred = GSS_C_NO_CREDENTIAL;
-		conn->gssenc = true;
 		gss_release_buffer(&minor, &output);
 
 		/*

Re: Problem with ssl and psql in Postgresql 13

Here's a more complete patchset.

0001 is the same libpq fixes I posted before.

0002 fixes a collection of random server-side issues, including:

* The GSS encryption code figured it could just ereport(ERROR) or
ereport(FATAL) for unrecoverable errors.  This seems entirely unsafe,
because elog.c will try to send the error message to the client,
likely re-triggering the same error and leading to infinite recursion.
Even if that doesn't happen, we might have sent a partial packet
to the client meaning that protocol synchronization is lost.  The
right thing to do is like what the SSL encryption code has long done:
log the error at COMMERROR level and then return errno = ECONNRESET
to shut things down.

* Fix sloppiness about whether pg_GSS_error()'s message parameter
is already translated or not.  (BTW, I'm a bit inclined to remove
pg_GSS_error()'s elevel parameter altogether and hardwire it as
COMMERROR, thus removing a bug temptation and making it more like the
similarly-named frontend function.  I didn't pull the trigger on that
here, though.)

* I really didn't like that we had the postmaster allocating the
port->gss struct (and committing hara-kiri if it could not).
Admittedly, the struct is not so large that an OOM failure is
likely, but it's just dumb to make the postmaster allocate a
struct it has zero use for.  I moved that allocation to the code
that actually needs it, GSSAPI encryption or auth startup.

* That also allows fixing a bug I noticed earlier, that the
"connection authorized" log message fails to mention GSS if we are
only using GSS for encryption without invoking GSS auth.  We can
use whether or not port->gss is non-null to figure out whether
the GSS clause of the message should appear.  (This is related to,
but distinct from, the pg_hba.conf-related log message fixes
discussed upthread.  I've not included those changes here, but
they're still on the table.)

* BackendStatusShmemSize failed to account for GSS-related space.
With large max_connections this could make a serious dent in our
shared-memory slop space.

* Various places knew more than they needed to about whether
port->gss->auth being set is equivalent to port->gss->princ being set.

* Remove long-dead call of secure_close() in postmaster's
ConnFree subroutine.

The 0003 patch removes the restriction I griped of earlier about
which auth methods can be used on a GSS-encrypted connection.
I made that a separate patch just in case it's controversial.

Finally, 0004 tries to improve the documentation in this area.
Some of that is reflective of 0003, but most of it is just
cleanup.

I propose to back-patch all of this as far as v12.

			regards, tom lane

diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index 7d04d3664e..ec7c4c5e87 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -2909,11 +2909,16 @@ keep_going:						/* We will come back to here until there is
 #ifdef USE_SSL
 
 				/*
-				 * If SSL is enabled and we haven't already got it running,
-				 * request it instead of sending the startup message.
+				 * If SSL is enabled and we haven't already got encryption of
+				 * some sort running, request SSL instead of sending the
+				 * startup message.
 				 */
 				if (conn->allow_ssl_try && !conn->wait_ssl_try &&
-					!conn->ssl_in_use)
+					!conn->ssl_in_use
+#ifdef ENABLE_GSS
+					&& !conn->gssenc
+#endif
+					)
 				{
 					ProtocolVersion pv;
 
@@ -3042,6 +3047,7 @@ keep_going:						/* We will come back to here until there is
 						}
 						/* Otherwise, proceed with normal startup */
 						conn->allow_ssl_try = false;
+						/* We can proceed using this connection */
 						conn->status = CONNECTION_MADE;
 						return PGRES_POLLING_WRITING;
 					}
@@ -3139,8 +3145,7 @@ keep_going:						/* We will come back to here until there is
 						 * don't hang up the socket, though.
 						 */
 						conn->try_gss = false;
-						pqDropConnection(conn, true);
-						conn->status = CONNECTION_NEEDED;
+						need_new_connection = true;
 						goto keep_going;
 					}
 
@@ -3158,6 +3163,7 @@ keep_going:						/* We will come back to here until there is
 						}
 
 						conn->try_gss = false;
+						/* We can proceed using this connection */
 						conn->status = CONNECTION_MADE;
 						return PGRES_POLLING_WRITING;
 					}
@@ -3186,8 +3192,7 @@ keep_going:						/* We will come back to here until there is
 					 * the current connection to do so, though.
 					 */
 					conn->try_gss = false;
-					pqDropConnection(conn, true);
-					conn->status = CONNECTION_NEEDED;
+					need_new_connection = true;
 					goto keep_going;
 				}
 				return pollres;
@@ -3354,10 +3359,9 @@ keep_going:						/* We will come back to here until there is
 					 */
 					if (conn->gssenc && conn->gssencmode[0] == 'p')
 					{
-						/* postmaster expects us to drop the connection */
+						/* only retry once */
 						conn->try_gss = false;
-						pqDropConnection(conn, true);
-						conn->status = CONNECTION_NEEDED;
+						need_new_connection = true;
 						goto keep_going;
 					}
 #endif
diff --git a/src/interfaces/libpq/fe-secure-gssapi.c b/src/interfaces/libpq/fe-secure-gssapi.c
index bfc0f55214..9416306eea 100644
--- a/src/interfaces/libpq/fe-secure-gssapi.c
+++ b/src/interfaces/libpq/fe-secure-gssapi.c
@@ -647,17 +647,14 @@ pqsecure_open_gss(PGconn *conn)
 	if (output.length == 0)
 	{
 		/*
-		 * We're done - hooray!  Kind of gross, but we need to disable SSL
-		 * here so that we don't accidentally tunnel one over the other.
+		 * We're done - hooray!  Set flag to tell the low-level I/O routines
+		 * to do GSS wrapping/unwrapping.
 		 */
-#ifdef USE_SSL
-		conn->allow_ssl_try = false;
-#endif
+		conn->gssenc = true;
 
 		/* Clean up */
 		gss_release_cred(&minor, &conn->gcred);
 		conn->gcred = GSS_C_NO_CREDENTIAL;
-		conn->gssenc = true;
 		gss_release_buffer(&minor, &output);
 
 		/*
diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
index 3d80930968..7f65310c14 100644
--- a/src/backend/libpq/auth.c
+++ b/src/backend/libpq/auth.c
@@ -383,7 +383,7 @@ ClientAuthentication(Port *port)
 	}
 
 #ifdef ENABLE_GSS
-	if (port->gss->enc && port->hba->auth_method != uaReject &&
+	if (port->gss && port->gss->enc && port->hba->auth_method != uaReject &&
 		port->hba->auth_method != uaImplicitReject &&
 		port->hba->auth_method != uaTrust &&
 		port->hba->auth_method != uaGSS)
@@ -533,7 +533,17 @@ ClientAuthentication(Port *port)
 
 		case uaGSS:
 #ifdef ENABLE_GSS
+			/* We might or might not have the gss workspace already */
+			if (port->gss == NULL)
+				port->gss = (pg_gssinfo *)
+					MemoryContextAllocZero(TopMemoryContext,
+										   sizeof(pg_gssinfo));
 			port->gss->auth = true;
+
+			/*
+			 * If GSS state was set up while enabling encryption, we can just
+			 * check the client's principal.  Otherwise, ask for it.
+			 */
 			if (port->gss->enc)
 				status = pg_GSS_checkauth(port);
 			else
@@ -548,6 +558,10 @@ ClientAuthentication(Port *port)
 
 		case uaSSPI:
 #ifdef ENABLE_SSPI
+			if (port->gss == NULL)
+				port->gss = (pg_gssinfo *)
+					MemoryContextAllocZero(TopMemoryContext,
+										   sizeof(pg_gssinfo));
 			sendAuthRequest(port, AUTH_REQ_SSPI, NULL, 0);
 			status = pg_SSPI_recvauth(port);
 #else
@@ -1185,9 +1199,10 @@ pg_GSS_recvauth(Port *port)
 		if (maj_stat != GSS_S_COMPLETE && maj_stat != GSS_S_CONTINUE_NEEDED)
 		{
 			gss_delete_sec_context(&lmin_s, &port->gss->ctx, GSS_C_NO_BUFFER);
-			pg_GSS_error(ERROR,
+			pg_GSS_error(COMMERROR,
 						 _("accepting GSS security context failed"),
 						 maj_stat, min_stat);
+			return STATUS_ERROR;
 		}
 
 		if (maj_stat == GSS_S_CONTINUE_NEEDED)
@@ -1224,9 +1239,12 @@ pg_GSS_checkauth(Port *port)
 	 */
 	maj_stat = gss_display_name(&min_stat, port->gss->name, &gbuf, NULL);
 	if (maj_stat != GSS_S_COMPLETE)
-		pg_GSS_error(ERROR,
+	{
+		pg_GSS_error(COMMERROR,
 					 _("retrieving GSS user name failed"),
 					 maj_stat, min_stat);
+		return STATUS_ERROR;
+	}
 
 	/*
 	 * Copy the original name of the authenticated principal into our backend
diff --git a/src/backend/libpq/be-gssapi-common.c b/src/backend/libpq/be-gssapi-common.c
index ef9b8ebd6d..a7006a0ab7 100644
--- a/src/backend/libpq/be-gssapi-common.c
+++ b/src/backend/libpq/be-gssapi-common.c
@@ -42,14 +42,22 @@ pg_GSS_error_int(char *s, size_t len, OM_uint32 stat, int type)
 	while (msg_ctx && i < len);
 
 	if (msg_ctx || i == len)
-		ereport(WARNING,
-				(errmsg_internal("incomplete GSS error report")));
+		elog(COMMERROR, "incomplete GSS error report");
 }
 
 /*
- * Fetch and report all error messages from GSSAPI.  To avoid allocation,
- * total error size is capped (at 128 bytes for each of major and minor).  No
- * known mechanisms will produce error messages beyond this cap.
+ * Report the GSSAPI error described by maj_stat/min_stat.
+ *
+ * errmsg should be an already-translated primary error message.
+ * The GSSAPI info is appended as errdetail.
+ *
+ * Caution: although we allow the caller to specify the ereport severity,
+ * passing anything but COMMERROR is almost certainly wrong, as it'd lead
+ * to infinite recursion when elog.c tries to write to the client.
+ *
+ * To avoid memory allocation, total error size is capped (at 128 bytes for
+ * each of major and minor).  No known mechanisms will produce error messages
+ * beyond this cap.
  */
 void
 pg_GSS_error(int severity, const char *errmsg,
diff --git a/src/backend/libpq/be-secure-gssapi.c b/src/backend/libpq/be-secure-gssapi.c
index 5a73302b7b..b70d74ca83 100644
--- a/src/backend/libpq/be-secure-gssapi.c
+++ b/src/backend/libpq/be-secure-gssapi.c
@@ -21,6 +21,7 @@
 #include "libpq/pqformat.h"
 #include "miscadmin.h"
 #include "pgstat.h"
+#include "utils/memutils.h"
 
 
 /*
@@ -81,10 +82,14 @@ static uint32 PqGSSMaxPktSize;	/* Maximum size we can encrypt and fit the
  * transport negotiation is complete).
  *
  * On success, returns the number of data bytes consumed (possibly less than
- * len).  On failure, returns -1 with errno set appropriately.  (For fatal
- * errors, we may just elog and exit, if errno wouldn't be sufficient to
- * describe the error.)  For retryable errors, caller should call again
- * (passing the same data) once the socket is ready.
+ * len).  On failure, returns -1 with errno set appropriately.  For retryable
+ * errors, caller should call again (passing the same data) once the socket
+ * is ready.
+ *
+ * Dealing with fatal errors here is a bit tricky: we can't invoke elog(FATAL)
+ * since it would try to write to the client, probably resulting in infinite
+ * recursion.  Instead, use elog(COMMERROR) to log extra info about the
+ * failure if necessary, and then return an errno indicating connection loss.
  */
 ssize_t
 be_gssapi_write(Port *port, void *ptr, size_t len)
@@ -108,8 +113,11 @@ be_gssapi_write(Port *port, void *ptr, size_t len)
 	 * again, so if it offers a len less than that, something is wrong.
 	 */
 	if (len < PqGSSSendConsumed)
-		elog(FATAL, "GSSAPI caller failed to retransmit all data needing to be retried");
-
+	{
+		elog(COMMERROR, "GSSAPI caller failed to retransmit all data needing to be retried");
+		errno = ECONNRESET;
+		return -1;
+	}
 	/* Discount whatever source data we already encrypted. */
 	bytes_to_encrypt = len - PqGSSSendConsumed;
 	bytes_encrypted = PqGSSSendConsumed;
@@ -192,17 +200,27 @@ be_gssapi_write(Port *port, void *ptr, size_t len)
 		major = gss_wrap(&minor, gctx, 1, GSS_C_QOP_DEFAULT,
 						 &input, &conf_state, &output);
 		if (major != GSS_S_COMPLETE)
-			pg_GSS_error(FATAL, gettext_noop("GSSAPI wrap error"), major, minor);
-
+		{
+			pg_GSS_error(COMMERROR, _("GSSAPI wrap error"), major, minor);
+			errno = ECONNRESET;
+			return -1;
+		}
 		if (conf_state == 0)
-			ereport(FATAL,
+		{
+			ereport(COMMERROR,
 					(errmsg("outgoing GSSAPI message would not use confidentiality")));
-
+			errno = ECONNRESET;
+			return -1;
+		}
 		if (output.length > PQ_GSS_SEND_BUFFER_SIZE - sizeof(uint32))
-			ereport(FATAL,
+		{
+			ereport(COMMERROR,
 					(errmsg("server tried to send oversize GSSAPI packet (%zu > %zu)",
 							(size_t) output.length,
 							PQ_GSS_SEND_BUFFER_SIZE - sizeof(uint32))));
+			errno = ECONNRESET;
+			return -1;
+		}
 
 		bytes_encrypted += input.length;
 		bytes_to_encrypt -= input.length;
@@ -234,9 +252,11 @@ be_gssapi_write(Port *port, void *ptr, size_t len)
  * transport negotiation is complete).
  *
  * Returns the number of data bytes read, or on failure, returns -1
- * with errno set appropriately.  (For fatal errors, we may just elog and
- * exit, if errno wouldn't be sufficient to describe the error.)  For
- * retryable errors, caller should call again once the socket is ready.
+ * with errno set appropriately.  For retryable errors, caller should call
+ * again once the socket is ready.
+ *
+ * We treat fatal errors the same as in be_gssapi_write(), even though the
+ * argument about infinite recursion doesn't apply here.
  */
 ssize_t
 be_gssapi_read(Port *port, void *ptr, size_t len)
@@ -326,10 +346,14 @@ be_gssapi_read(Port *port, void *ptr, size_t len)
 		input.length = pg_ntoh32(*(uint32 *) PqGSSRecvBuffer);
 
 		if (input.length > PQ_GSS_RECV_BUFFER_SIZE - sizeof(uint32))
-			ereport(FATAL,
+		{
+			ereport(COMMERROR,
 					(errmsg("oversize GSSAPI packet sent by the client (%zu > %zu)",
 							(size_t) input.length,
 							PQ_GSS_RECV_BUFFER_SIZE - sizeof(uint32))));
+			errno = ECONNRESET;
+			return -1;
+		}
 
 		/*
 		 * Read as much of the packet as we are able to on this call into
@@ -361,12 +385,18 @@ be_gssapi_read(Port *port, void *ptr, size_t len)
 
 		major = gss_unwrap(&minor, gctx, &input, &output, &conf_state, NULL);
 		if (major != GSS_S_COMPLETE)
-			pg_GSS_error(FATAL, gettext_noop("GSSAPI unwrap error"),
-						 major, minor);
-
+		{
+			pg_GSS_error(COMMERROR, _("GSSAPI unwrap error"), major, minor);
+			errno = ECONNRESET;
+			return -1;
+		}
 		if (conf_state == 0)
-			ereport(FATAL,
+		{
+			ereport(COMMERROR,
 					(errmsg("incoming GSSAPI message did not use confidentiality")));
+			errno = ECONNRESET;
+			return -1;
+		}
 
 		memcpy(PqGSSResultBuffer, output.value, output.length);
 		PqGSSResultLength = output.length;
@@ -468,6 +498,12 @@ secure_open_gssapi(Port *port)
 	OM_uint32	major,
 				minor;
 
+	/*
+	 * Allocate subsidiary Port data for GSSAPI operations.
+	 */
+	port->gss = (pg_gssinfo *)
+		MemoryContextAllocZero(TopMemoryContext, sizeof(pg_gssinfo));
+
 	/*
 	 * Allocate buffers and initialize state variables.  By malloc'ing the
 	 * buffers at this point, we avoid wasting static data space in processes
@@ -521,10 +557,13 @@ secure_open_gssapi(Port *port)
 		 * Verify on our side that the client doesn't do something funny.
 		 */
 		if (input.length > PQ_GSS_RECV_BUFFER_SIZE)
-			ereport(FATAL,
+		{
+			ereport(COMMERROR,
 					(errmsg("oversize GSSAPI packet sent by the client (%zu > %d)",
 							(size_t) input.length,
 							PQ_GSS_RECV_BUFFER_SIZE)));
+			return -1;
+		}
 
 		/*
 		 * Get the rest of the packet so we can pass it to GSSAPI to accept
@@ -544,7 +583,7 @@ secure_open_gssapi(Port *port)
 									   NULL, NULL);
 		if (GSS_ERROR(major))
 		{
-			pg_GSS_error(ERROR, gettext_noop("could not accept GSSAPI security context"),
+			pg_GSS_error(COMMERROR, _("could not accept GSSAPI security context"),
 						 major, minor);
 			gss_release_buffer(&minor, &output);
 			return -1;
@@ -570,10 +609,14 @@ secure_open_gssapi(Port *port)
 			uint32		netlen = pg_hton32(output.length);
 
 			if (output.length > PQ_GSS_SEND_BUFFER_SIZE - sizeof(uint32))
-				ereport(FATAL,
+			{
+				ereport(COMMERROR,
 						(errmsg("server tried to send oversize GSSAPI packet (%zu > %zu)",
 								(size_t) output.length,
 								PQ_GSS_SEND_BUFFER_SIZE - sizeof(uint32))));
+				gss_release_buffer(&minor, &output);
+				return -1;
+			}
 
 			memcpy(PqGSSSendBuffer, (char *) &netlen, sizeof(uint32));
 			PqGSSSendLength += sizeof(uint32);
@@ -634,8 +677,10 @@ secure_open_gssapi(Port *port)
 								&PqGSSMaxPktSize);
 
 	if (GSS_ERROR(major))
-		pg_GSS_error(FATAL, gettext_noop("GSSAPI size check error"),
-					 major, minor);
+	{
+		pg_GSS_error(COMMERROR, _("GSSAPI size check error"), major, minor);
+		return -1;
+	}
 
 	port->gss->enc = true;
 
@@ -667,12 +712,13 @@ be_gssapi_get_enc(Port *port)
 }
 
 /*
- * Return the GSSAPI principal used for authentication on this connection.
+ * Return the GSSAPI principal used for authentication on this connection
+ * (NULL if we did not perform GSSAPI authentication).
  */
 const char *
 be_gssapi_get_princ(Port *port)
 {
-	if (!port || !port->gss->auth)
+	if (!port || !port->gss)
 		return NULL;
 
 	return port->gss->princ;
diff --git a/src/backend/libpq/be-secure.c b/src/backend/libpq/be-secure.c
index 2ae507a902..59bc02e79c 100644
--- a/src/backend/libpq/be-secure.c
+++ b/src/backend/libpq/be-secure.c
@@ -160,7 +160,7 @@ retry:
 	else
 #endif
 #ifdef ENABLE_GSS
-	if (port->gss->enc)
+	if (port->gss && port->gss->enc)
 	{
 		n = be_gssapi_read(port, ptr, len);
 		waitfor = WL_SOCKET_READABLE;
@@ -273,7 +273,7 @@ retry:
 	else
 #endif
 #ifdef ENABLE_GSS
-	if (port->gss->enc)
+	if (port->gss && port->gss->enc)
 	{
 		n = be_gssapi_write(port, ptr, len);
 		waitfor = WL_SOCKET_WRITEABLE;
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index 0cc4397769..41ca0791ea 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -2134,9 +2134,11 @@ check_hba(hbaPort *port)
 
 			/* Check GSSAPI state */
 #ifdef ENABLE_GSS
-			if (port->gss->enc && hba->conntype == ctHostNoGSS)
+			if (port->gss && port->gss->enc &&
+				hba->conntype == ctHostNoGSS)
 				continue;
-			else if (!port->gss->enc && hba->conntype == ctHostGSS)
+			else if (!(port->gss && port->gss->enc) &&
+					 hba->conntype == ctHostGSS)
 				continue;
 #else
 			if (hba->conntype == ctHostGSS)
diff --git a/src/backend/libpq/pqcomm.c b/src/backend/libpq/pqcomm.c
index 0b511008fc..3ea7c6167e 100644
--- a/src/backend/libpq/pqcomm.c
+++ b/src/backend/libpq/pqcomm.c
@@ -256,29 +256,26 @@ socket_close(int code, Datum arg)
 	/* Nothing to do in a standalone backend, where MyProcPort is NULL. */
 	if (MyProcPort != NULL)
 	{
-#if defined(ENABLE_GSS) || defined(ENABLE_SSPI)
 #ifdef ENABLE_GSS
-		OM_uint32	min_s;
-
 		/*
 		 * Shutdown GSSAPI layer.  This section does nothing when interrupting
 		 * BackendInitialize(), because pg_GSS_recvauth() makes first use of
 		 * "ctx" and "cred".
+		 *
+		 * Note that we don't bother to free MyProcPort->gss, since we're
+		 * about to exit anyway.
 		 */
-		if (MyProcPort->gss->ctx != GSS_C_NO_CONTEXT)
-			gss_delete_sec_context(&min_s, &MyProcPort->gss->ctx, NULL);
+		if (MyProcPort->gss)
+		{
+			OM_uint32	min_s;
 
-		if (MyProcPort->gss->cred != GSS_C_NO_CREDENTIAL)
-			gss_release_cred(&min_s, &MyProcPort->gss->cred);
-#endif							/* ENABLE_GSS */
+			if (MyProcPort->gss->ctx != GSS_C_NO_CONTEXT)
+				gss_delete_sec_context(&min_s, &MyProcPort->gss->ctx, NULL);
 
-		/*
-		 * GSS and SSPI share the port->gss struct.  Since nowhere else does a
-		 * postmaster child free this, doing so is safe when interrupting
-		 * BackendInitialize().
-		 */
-		free(MyProcPort->gss);
-#endif							/* ENABLE_GSS || ENABLE_SSPI */
+			if (MyProcPort->gss->cred != GSS_C_NO_CREDENTIAL)
+				gss_release_cred(&min_s, &MyProcPort->gss->cred);
+		}
+#endif							/* ENABLE_GSS */
 
 		/*
 		 * Cleanly shut down SSL layer.  Nowhere else does a postmaster child
diff --git a/src/backend/postmaster/pgstat.c b/src/backend/postmaster/pgstat.c
index 71f2b90ca8..7fba907479 100644
--- a/src/backend/postmaster/pgstat.c
+++ b/src/backend/postmaster/pgstat.c
@@ -2888,6 +2888,11 @@ BackendStatusShmemSize(void)
 	/* BackendSslStatusBuffer: */
 	size = add_size(size,
 					mul_size(sizeof(PgBackendSSLStatus), NumBackendStatSlots));
+#endif
+#ifdef ENABLE_GSS
+	/* BackendGssStatusBuffer: */
+	size = add_size(size,
+					mul_size(sizeof(PgBackendGSSStatus), NumBackendStatSlots));
 #endif
 	return size;
 }
@@ -3172,12 +3177,13 @@ pgstat_bestart(void)
 #ifdef ENABLE_GSS
 	if (MyProcPort && MyProcPort->gss != NULL)
 	{
+		const char *princ = be_gssapi_get_princ(MyProcPort);
+
 		lbeentry.st_gss = true;
 		lgssstatus.gss_auth = be_gssapi_get_auth(MyProcPort);
 		lgssstatus.gss_enc = be_gssapi_get_enc(MyProcPort);
-
-		if (lgssstatus.gss_auth)
-			strlcpy(lgssstatus.gss_princ, be_gssapi_get_princ(MyProcPort), NAMEDATALEN);
+		if (princ)
+			strlcpy(lgssstatus.gss_princ, princ, NAMEDATALEN);
 	}
 	else
 	{
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index bf883184b1..0bb85a18f6 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -2063,6 +2063,7 @@ retry1:
 	else if (proto == NEGOTIATE_GSS_CODE && !gss_done)
 	{
 		char		GSSok = 'N';
+
 #ifdef ENABLE_GSS
 		/* No GSSAPI encryption when on Unix socket */
 		if (!IS_AF_UNIX(port->laddr.addr.ss_family))
@@ -2531,37 +2532,19 @@ ConnCreate(int serverFd)
 		return NULL;
 	}
 
-	/*
-	 * Allocate GSSAPI specific state struct
-	 */
-#ifndef EXEC_BACKEND
-#if defined(ENABLE_GSS) || defined(ENABLE_SSPI)
-	port->gss = (pg_gssinfo *) calloc(1, sizeof(pg_gssinfo));
-	if (!port->gss)
-	{
-		ereport(LOG,
-				(errcode(ERRCODE_OUT_OF_MEMORY),
-				 errmsg("out of memory")));
-		ExitPostmaster(1);
-	}
-#endif
-#endif
-
 	return port;
 }
 
 
 /*
  * ConnFree -- free a local connection data structure
+ *
+ * Caller has already closed the socket if any, so there's not much
+ * to do here.
  */
 static void
 ConnFree(Port *conn)
 {
-#ifdef USE_SSL
-	secure_close(conn);
-#endif
-	if (conn->gss)
-		free(conn->gss);
 	free(conn);
 }
 
@@ -4917,18 +4900,6 @@ SubPostmasterMain(int argc, char *argv[])
 	/* Setup as postmaster child */
 	InitPostmasterChild();
 
-	/*
-	 * Set up memory area for GSS information. Mirrors the code in ConnCreate
-	 * for the non-exec case.
-	 */
-#if defined(ENABLE_GSS) || defined(ENABLE_SSPI)
-	port.gss = (pg_gssinfo *) calloc(1, sizeof(pg_gssinfo));
-	if (!port.gss)
-		ereport(FATAL,
-				(errcode(ERRCODE_OUT_OF_MEMORY),
-				 errmsg("out of memory")));
-#endif
-
 	/*
 	 * If appropriate, physically re-attach to shared memory segment. We want
 	 * to do this before going any further to ensure that we can attach at the
diff --git a/src/backend/utils/init/postinit.c b/src/backend/utils/init/postinit.c
index 82d451569d..9723e457ce 100644
--- a/src/backend/utils/init/postinit.c
+++ b/src/backend/utils/init/postinit.c
@@ -270,11 +270,22 @@ PerformAuthentication(Port *port)
 							 be_tls_get_compression(port) ? _("on") : _("off"));
 #endif
 #ifdef ENABLE_GSS
-		if (be_gssapi_get_princ(port))
-			appendStringInfo(&logmsg, _(" GSS (authenticated=%s, encrypted=%s, principal=%s)"),
-							 be_gssapi_get_auth(port) ? _("yes") : _("no"),
-							 be_gssapi_get_enc(port) ? _("yes") : _("no"),
-							 be_gssapi_get_princ(port));
+		if (port->gss)
+		{
+			const char *princ = be_gssapi_get_princ(port);
+
+			if (princ)
+				appendStringInfo(&logmsg,
+								 _(" GSS (authenticated=%s, encrypted=%s, principal=%s)"),
+								 be_gssapi_get_auth(port) ? _("yes") : _("no"),
+								 be_gssapi_get_enc(port) ? _("yes") : _("no"),
+								 princ);
+			else
+				appendStringInfo(&logmsg,
+								 _(" GSS (authenticated=%s, encrypted=%s)"),
+								 be_gssapi_get_auth(port) ? _("yes") : _("no"),
+								 be_gssapi_get_enc(port) ? _("yes") : _("no"));
+		}
 #endif
 
 		ereport(LOG, errmsg_internal("%s", logmsg.data));
diff --git a/src/include/libpq/libpq-be.h b/src/include/libpq/libpq-be.h
index 0a23281ad5..fa778e1192 100644
--- a/src/include/libpq/libpq-be.h
+++ b/src/include/libpq/libpq-be.h
@@ -176,8 +176,9 @@ typedef struct Port
 #if defined(ENABLE_GSS) || defined(ENABLE_SSPI)
 
 	/*
-	 * If GSSAPI is supported, store GSSAPI information. Otherwise, store a
-	 * NULL pointer to make sure offsets in the struct remain the same.
+	 * If GSSAPI is supported and used on this connection, store GSSAPI
+	 * information.  Even when GSSAPI is not compiled in, store a NULL pointer
+	 * to keep struct offsets the same (for extension ABI compatibility).
 	 */
 	pg_gssinfo *gss;
 #else
diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
index 7f65310c14..aad7f982bf 100644
--- a/src/backend/libpq/auth.c
+++ b/src/backend/libpq/auth.c
@@ -382,17 +382,6 @@ ClientAuthentication(Port *port)
 					 errmsg("connection requires a valid client certificate")));
 	}
 
-#ifdef ENABLE_GSS
-	if (port->gss && port->gss->enc && port->hba->auth_method != uaReject &&
-		port->hba->auth_method != uaImplicitReject &&
-		port->hba->auth_method != uaTrust &&
-		port->hba->auth_method != uaGSS)
-	{
-		ereport(FATAL, (errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
-						errmsg("GSSAPI encryption can only be used with gss, trust, or reject authentication methods")));
-	}
-#endif
-
 	/*
 	 * Now proceed to do the actual authentication check
 	 */
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index 41ca0791ea..99319b273a 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -1447,19 +1447,6 @@ parse_hba_line(TokenizedLine *tok_line, int elevel)
 		*err_msg = "gssapi authentication is not supported on local sockets";
 		return NULL;
 	}
-	if (parsedline->conntype == ctHostGSS &&
-		parsedline->auth_method != uaGSS &&
-		parsedline->auth_method != uaReject &&
-		parsedline->auth_method != uaTrust)
-	{
-		ereport(elevel,
-				(errcode(ERRCODE_CONFIG_FILE_ERROR),
-				 errmsg("GSSAPI encryption only supports gss, trust, or reject authentication"),
-				 errcontext("line %d of configuration file \"%s\"",
-							line_num, HbaFileName)));
-		*err_msg = "GSSAPI encryption only supports gss, trust, or reject authentication";
-		return NULL;
-	}
 
 	if (parsedline->conntype != ctLocal &&
 		parsedline->auth_method == uaPeer)
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index a0a9ac9eed..9a5c9318ce 100644
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@ -198,14 +198,6 @@ hostnogssenc  database  userhostgssenc record is ignored except for logging
        a warning that it cannot match any connections.
       
-
-      
-        Note that the only supported
-        authentication methods for use
-        with GSSAPI encryption
-        are gss, reject,
-        and trust.
-      
      
     
 
@@ -1201,14 +1193,13 @@ omicron         bryanh                  guest1
     GSSAPI is an industry-standard protocol
     for secure authentication defined in
     RFC 2743.
-
     PostgreSQL
-    supports GSSAPI for use as either an encrypted,
-    authenticated layer, or for authentication only.
+    supports GSSAPI for authentication,
+    communications encryption, or both.
     GSSAPI provides automatic authentication
     (single sign-on) for systems that support it. The authentication itself is
     secure.  If GSSAPI encryption
-    (see hostgssenc) or SSL encryption are
+    or SSL encryption is
     used, the data sent along the database connection will be encrypted;
     otherwise, it will not.
    
@@ -1220,37 +1211,46 @@ omicron         bryanh                  guest1
 
    
     When GSSAPI uses
-    Kerberos, it uses a standard principal
-    in the format
+    Kerberos, it uses a standard service
+    principal (authentication identity) name in the format
     servicename/hostname@realm.
-    The PostgreSQL server will accept any principal that is included in the keytab used by
-    the server, but care needs to be taken to specify the correct principal details when
-    making the connection from the client using the krbsrvname connection parameter. (See
-    also .) The installation default can be
-    changed from the default postgres at build time using
-    ./configure --with-krb-srvnam=whatever.
-    In most environments,
-    this parameter never needs to be changed.
-    Some Kerberos implementations might require a different service name,
-    such as Microsoft Active Directory which requires the service name
-    to be in upper case (POSTGRES).
-   
-   
-    hostname is the fully qualified host name of the
-    server machine. The service principal's realm is the preferred realm
-    of the server machine.
-   
-
-   
-    Client principals can be mapped to different PostgreSQL
-    database user names with pg_ident.conf.  For example,
+    The principal name used by a particular installation is not encoded in
+    the PostgreSQL server in any way; rather it
+    is specified in the keytab file that the server
+    reads to determine its identity.  If multiple principals are listed in
+    the keytab file, the server will accept any one of them.
+    The server's realm name is the preferred realm specified in the Kerberos
+    configuration file(s) accessible to the server.
+   
+
+   
+    When connecting, the client must know the principal name of the server
+    it intends to connect to.  The servicename
+    part of the principal is ordinarily postgres,
+    but another value can be selected via libpq's
+     connection parameter.
+    The hostname part is the fully qualified
+    host name that libpq is told to connect to.
+    The realm name is the preferred realm specified in the Kerberos
+    configuration file(s) accessible to the client.
+   
+
+   
+    The client will also have a principal name for its own identity
+    (and it must have a valid ticket for this principal).  To
+    use GSSAPI for authentication, the client
+    principal must be associated with
+    a PostgreSQL database user name.
+    The pg_ident.conf configuration file can be used
+    to map principals to user names; for example,
     pgusername@realm could be mapped to just pgusername.
     Alternatively, you can use the full username@realm principal as
     the role name in PostgreSQL without any mapping.
    
 
    
-    PostgreSQL also supports a parameter to strip the realm from
+    PostgreSQL also supports mapping
+    client principals to user names by just stripping the realm from
     the principal.  This method is supported for backwards compatibility and is
     strongly discouraged as it is then impossible to distinguish different users
     with the same user name but coming from different realms.  To enable this,
@@ -1264,39 +1264,34 @@ omicron         bryanh                  guest1
    
 
    
-    Make sure that your server keytab file is readable (and preferably
-    only readable, not writable) by the PostgreSQL
-    server account.  (See also .) The location
-    of the key file is specified by the  configuration
     parameter. The default is
-    /usr/local/pgsql/etc/krb5.keytab (or whatever
-    directory was specified as sysconfdir at build time).
+    FILE:/usr/local/pgsql/etc/krb5.keytab
+    (where the directory part is whatever was specified
+    as sysconfdir at build time).
     For security reasons, it is recommended to use a separate keytab
     just for the PostgreSQL server rather
-    than opening up permissions on the system keytab file.
+    than allowing the server to read the system keytab file.
+    Make sure that your server keytab file is readable (and preferably
+    only readable, not writable) by the PostgreSQL
+    server account.  (See also .)
    
+
    
-    The keytab file is generated by the Kerberos software; see the
-    Kerberos documentation for details. The following example is
-   for MIT-compatible Kerberos 5 implementations:
+    The keytab file is generated using the Kerberos software; see the
+    Kerberos documentation for details. The following example shows
+    doing this using the kadmin tool of
+    MIT-compatible Kerberos 5 implementations:
 
-kadmin% ank -randkey postgres/server.my.domain.org
+kadmin% addprinc -randkey postgres/server.my.domain.org
 kadmin% ktadd -k krb5.keytab postgres/server.my.domain.org
 
    
 
    
-    When connecting to the database make sure you have a ticket for a
-    principal matching the requested database user name. For example, for
-    database user name fred, principal
-    fred@EXAMPLE.COM would be able to connect. To also allow
-    principal fred/users.example.com@EXAMPLE.COM, use a user name
-    map, as described in .
-   
-
-   
-    The following configuration options are supported for GSSAPI:
+    The following authentication options are supported for
+    the GSSAPI authentication method:
     
      
       include_realm
@@ -1319,7 +1314,7 @@ omicron         bryanh                  guest1
       map
       
        
-        Allows for mapping between system and database user names. See
+        Allows mapping from client principals to database user names. See
          for details.  For a GSSAPI/Kerberos
         principal, such as username@EXAMPLE.COM (or, less
         commonly, username/hostbased@EXAMPLE.COM), the
@@ -1346,6 +1341,15 @@ omicron         bryanh                  guest1
      
     
    
+
+   
+    In addition to these settings, which can be different for
+    different pg_hba.conf entries, there is the
+    server-wide  configuration
+    parameter.  If that is set to true, client principals are matched to
+    user map entries case-insensitively.  krb_realm, if
+    set, is also matched case-insensitively.
+   
   
 
   
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 67c5d4c36b..a5db58d468 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -1581,6 +1581,16 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
         connection.SSLwith libpq
        
+
+       
+        Note that if GSSAPI encryption is possible,
+        that will be used in preference to SSL
+        encryption, regardless of the value of sslmode.
+        To force use of SSL encryption in an
+        environment that has working GSSAPI
+        infrastructure (such as a Kerberos server), also
+        set gssencmode to disable.
+       
       
      
 
@@ -1784,6 +1794,15 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
         This must match the service name specified in the server
         configuration for Kerberos authentication to succeed. (See also
         .)
+        The default value is normally postgres,
+        but that can be changed when
+        building PostgreSQL via
+        the  option
+        of configure.
+        In most environments, this parameter never needs to be changed.
+        Some Kerberos implementations might require a different service name,
+        such as Microsoft Active Directory which requires the service name
+        to be in upper case (POSTGRES).
        
       
      
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 4899bacda7..98b42bb269 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -1454,6 +1454,10 @@ SELCT 1/0;
     SSL-encrypted.  To continue after
     N, send the usual StartupMessage and proceed without
     encryption.
+    (Alternatively, it is permissible to issue a GSSENCRequest message
+    after an N response to try to
+    use GSSAPI encryption instead
+    of SSL.)
    
 
    
@@ -1509,20 +1513,14 @@ SELCT 1/0;
     result from the server, until it returns no output.  When sending the
     results of gss_init_sec_context() to the server,
     prepend the length of the message as a four byte integer in network byte
-    order.  If this is successful, then use gss_wrap() to
-    encrypt the usual StartupMessage and all subsequent data, prepending the
-    length of the result from gss_wrap() as a four byte
-    integer in network byte order to the actual encrypted payload.  Note that
-    the server will only accept encrypted packets from the client which are less
-    than 16kB; gss_wrap_size_limit() should be used by the
-    client to determine the size of the unencrypted message which will fit
-    within this limit and larger messages should be broken up into multiple
-    gss_wrap() calls.  Typical segments are 8kB of
-    unencrypted data, resulting in encrypted packets of slightly larger than 8kB
-    but well within the 16kB maximum.  The server can be expected to not send
-    encrypted packets of larger than 16kB to the client.  To continue after
+    order.
+    To continue after
     N, send the usual StartupMessage and proceed without
     encryption.
+    (Alternatively, it is permissible to issue an SSLRequest message
+    after an N response to try to
+    use SSL encryption instead
+    of GSSAPI.)
    
 
    
@@ -1532,9 +1530,7 @@ SELCT 1/0;
     support to PostgreSQL.  In this case the
     connection must be closed, but the frontend might choose to open a fresh
     connection and proceed without requesting GSSAPI
-    encryption.  Given the length limits specified above, the ErrorMessage can
-    not be confused with a proper response from the server with an appropriate
-    length.
+    encryption.
    
 
    
@@ -1542,6 +1538,22 @@ SELCT 1/0;
     opened to send a CancelRequest message.
    
 
+   
+    Once GSSAPI encryption has been successfully
+    established, use gss_wrap() to
+    encrypt the usual StartupMessage and all subsequent data, prepending the
+    length of the result from gss_wrap() as a four byte
+    integer in network byte order to the actual encrypted payload.  Note that
+    the server will only accept encrypted packets from the client which are less
+    than 16kB; gss_wrap_size_limit() should be used by the
+    client to determine the size of the unencrypted message which will fit
+    within this limit and larger messages should be broken up into multiple
+    gss_wrap() calls.  Typical segments are 8kB of
+    unencrypted data, resulting in encrypted packets of slightly larger than 8kB
+    but well within the 16kB maximum.  The server can be expected to not send
+    encrypted packets of larger than 16kB to the client.
+   
+
    
     While the protocol itself does not provide a way for the server to
     force GSSAPI encryption, the administrator can
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 17e938148c..283352d3a4 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -2563,7 +2563,7 @@ openssl x509 -req -in server.csr -text -days 365 \
    PostgreSQL also has native support for
    using GSSAPI to encrypt client/server communications for
    increased security.  Support requires that a GSSAPI
-   implementation (such as MIT krb5) is installed on both client and server
+   implementation (such as MIT Kerberos) is installed on both client and server
    systems, and that support in PostgreSQL is
    enabled at build time (see ).
   
@@ -2582,6 +2582,16 @@ openssl x509 -req -in server.csr -text -days 365 \
     some or all connections.
    
 
+   
+    When using GSSAPI for encryption, it is common to
+    use GSSAPI for authentication as well, since the
+    underlying mechanism will determine both client and server identities
+    (according to the GSSAPI implementation) in any
+    case.  But this is not required;
+    another PostgreSQL authentication method
+    can be chosen to perform additional verification.
+   
+
    
     Other than configuration of the negotiation
     behavior, GSSAPI encryption requires no setup beyond

Re: SV: SV: SV: Problem with ssl and psql in Postgresql 13

Gustavsson Mikael  writes:
> pgsql-13 with require:
> $ /usr/pgsql-13/bin/psql "dbname=postgres user=kalle host=server sslmode=require"
> Password for user kalle:
> psql (13.1)
> Type "help" for help.

That is just bizarre.  libpq should not ignore the sslmode=require option
like that, unless it thinks it's making a Unix-socket connection, which
it should not think given the host specification.  (There's not a slash
in your server's real name, is there?  But if there was, v11 should
misbehave too.)

It seems like there must be some environment setting, or maybe a service
file, changing the behavior from what it should be on its face.  But
that theory has big flaws too: an explicit sslmode=require setting should
not be overridable from environment, and even if it was, why wouldn't v11
act the same?

The only other conclusion I can think of is that your copy of libpq.so
is broken.  Maybe you should try redownloading/reinstalling v13.

			regards, tom lane

Re: Problem with ssl and psql in Postgresql 13

Hi.

At Thu, 17 Dec 2020 07:21:08 +0000, Gustavsson Mikael  wrote in 
> But not from psql 13:
> $ /usr/pgsql-13/bin/psql -d postgres -Ukalle -hserver -W
> Password:
> psql: error: FATAL:  no pg_hba.conf entry for host "nnn.nn.n.nnn", user "kalle", database "postgres", SSL off
> FATAL:  no pg_hba.conf entry for host "nnn.nn.n.nnn", user "kalle", database "postgres", SSL off

It looks like the option "ssl" (in postgresql.conf) is turned off on
the v13 server.  You will find lines like the following in the server
log in that case.

LOG:  hostssl record cannot match because SSL is disabled
HINT:  Set ssl = on in postgresql.conf.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Re: Problem with ssl and psql in Postgresql 13

Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> I wrote:
> > Gustavsson Mikael  writes:
> >> So if i set gssencmode=disable on my pgsql-13 to postgres 13 server connection i get an SSL connection.
> 
> > It looks like, if there is a credentials cache and gssencmode isn't
> > explicitly disabled, we try GSS first.  If the server refuses that:
> > ...
> > that is, it decides the connection it has is good enough.  This
> > is not OK if SSL should have been used.
> 
> No, I misread the code; what will happen next is that an SSL connection
> will be tried.  At least, it looks like that should happen, and it does
> happen for me.
> 
> However: it is true (and undocumented, so we have at least a docs bug
> to fix) that v12-and-later libpq will try for GSS encryption first,
> and if it succeeds then it will not consider using SSL, regardless of
> sslmode.  So about 95% of your report could be explained by assuming
> that you have a working Kerberos environment and the newer libpq is
> preferring GSS encryption over SSL.  There is just one thing this
> theory is failing to explain: instead of "SSL connection", psql
> should have printed "GSSAPI-encrypted connection" in your test
> shown in .  It didn't,
> so this can't be the true explanation.  I think what must be
> happening is that libpq is trying for GSS (hence you have at least
> a credentials cache somewhere), failing to establish it, and then
> for some reason advancing to the startup-packet step without
> trying for SSL.  But I can't see how to get the state machine to
> do that.

Not sure how much it helps, but yes, the general idea is that if you've
got a Kerberos credential cache, then we're going to try GSS encryption
first and, if that succeeds, we'll use it.

The docs do say this-

https://www.postgresql.org/docs/current/libpq-connect.html

under gssencmode / prefer (default)

if there are GSSAPI credentials present (i.e., in a credentials cache),
first try a GSSAPI-encrypted connection; if that fails or there are
no credentials, try a non-GSSAPI-encrypted connection. This is the
default when PostgreSQL has been compiled with GSSAPI support.

Though we also say under sslmode / prefer (default) -

first try an SSL connection; if that fails, try a non-SSL connection

Obviously they can't both be 'first', so it would probably make sense to
update the documentation, though exactly how I'm not sure.  Perhaps
under sslmode / prefer:

first try an SSL connection (note, however, that if there are GSSAPI
credentials present and gssencmode is also set to 'prefer', then a
GSSAPI-encrypted connection will be attempted first); if that fails, try
a non-SSL connection

?

Or perhaps a Note would be better to explain that we try GSSAPI
encryption first if GSSAPI credentials exist and both are set to
'prefer'.  The whole situation around 'prefer' is pretty grotty for all
cases, though I suppose that isn't really news these days.

Thanks,

Stephen

Re: Problem with ssl and psql in Postgresql 13

Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost  writes:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >> However: it is true (and undocumented, so we have at least a docs bug
> >> to fix) that v12-and-later libpq will try for GSS encryption first,
> >> and if it succeeds then it will not consider using SSL, regardless of
> >> sslmode.  So about 95% of your report could be explained by assuming
> >> that you have a working Kerberos environment and the newer libpq is
> >> preferring GSS encryption over SSL.  There is just one thing this
> >> theory is failing to explain: instead of "SSL connection", psql
> >> should have printed "GSSAPI-encrypted connection" in your test
> >> shown in .  It didn't,
> >> so this can't be the true explanation.  I think what must be
> >> happening is that libpq is trying for GSS (hence you have at least
> >> a credentials cache somewhere), failing to establish it, and then
> >> for some reason advancing to the startup-packet step without
> >> trying for SSL.  But I can't see how to get the state machine to
> >> do that.
> 
> > Though we also say under sslmode / prefer (default) -
> >   first try an SSL connection; if that fails, try a non-SSL connection
> > Obviously they can't both be 'first', so it would probably make sense to
> > update the documentation, though exactly how I'm not sure.
> 
> Yeah; the problem is that the sslmode docs don't mention that GSS comes
> first.  I was thinking of adding verbiage along the lines of "Note that
> if GSS encryption is possible, that will be used in preference to SSL,
> regardless of the value of sslmode".

Sure, that seems alright to me.

> In the meantime, I did spot a code path that would explain the symptoms:
> pqsecure_open_gss() clears allow_ssl_try sooner than it oughta.  If
> gss_wrap_size_limit() failed for some reason, we'd abandon the GSS
> connection and try another one, and we would *not* try to SSL-ify
> the new one.  While that's clearly a bug, I'm dubious that it explains
> this report, because it hardly seems likely that gss_wrap_size_limit()
> would fail when we've already successfully negotiated an encrypted
> connection.  Can you think of a plausible reason for that to happen?

There are certainly some very odd GSSAPI implementations out there
(including hacked up things particularly on Macs that we've seen..),
though I've not run into one where I've seen that call fail.

If it did fail though, surely the error messages would make that
clear, and we're not seeing that here..?  If we do succeed with a GSS
connection (which seems extremely unlikely to just happen without the
individual setting the system up knowing that they've created an
appropriate Kerberos keytab with a postgres service princ...), then, as
you say up-thread, psql should have printed out that we made a GSSAPI
encrypted connection.

I'm not sure how, but it sure seems like somehow, in this case, we're
going through the GSSAPI encryption code because we find GSSAPI
credentials (entirely possible, even if you're not using them for
talking to PG), the server responds with a "I haven't got support for
that" in some fashion, and we're skipping SSL at that point.  How that's
happening isn't clear to me though, but the idea that it's because
gss_wrap_size_limit() is failing seems very unlikely.

Thanks,

Stephen

Re: Problem with ssl and psql in Postgresql 13

At Wed, 23 Dec 2020 17:34:05 -0500, Tom Lane  wrote in 
> Oh ... wait a second.  I've just managed to partially reproduce this
> report.  Assume that we have a working Kerberos environment on both

If I kninit'ed and pg_hba.conf doesn't have a hostgssenc line and has
a hostssl line, I got the following error from psql.

$ psql -d postgres --set=sslmode=require -Uhoriguti -hmyhost.mydomain
psql: error: FATAL:  no pg_hba.conf entry for host "192.168.56.101", user "horiguti", database "postgres", SSL off
FATAL:  no pg_hba.conf entry for host "192.168.56.101", user "horiguti", database "postgres", SSL off

The state machine enables gssenc if a valid credential is available
regardless of whether a valid gsshostenc definition is available or not.

I rembmer that I am annoyed a bit by this behavior, but I didn't care
of that since I thought that SSL and GSS are not used togehter in an
environemt.

> ends.  Then libpq will establish a connection with GSS encryption
> and continue on with the usual PG authentication exchange.  If that
> part fails, then this logic (fe_connect.c around line 3350):
> 
>                     /*
>                      * If gssencmode is "prefer" and we're using GSSAPI, retry
>                      * without it.
>                      */
>                     if (conn->gssenc && conn->gssencmode[0] == 'p')
>                     {
>                         /* postmaster expects us to drop the connection */
>                         conn->try_gss = false;
>                         pqDropConnection(conn, true);
>                         conn->status = CONNECTION_NEEDED;
>                         goto keep_going;
>                     }
>
> drops the connection and tries again without GSS.  But *we already
> cleared allow_ssl_try*, in pqsecure_open_gss, so the next try will
> not bother with SSL either.
> So this directly explains the original report: if the only applicable
> pg_hba.conf entry is "hostssl", right here is where libpq will see
> that error, and it will go around and fail again because the next
> try uses neither GSS nor SSL.
>
> However, in the tests Mikael ran after backing that pg_hba.conf entry
> off to just "host", pg_hba wouldn't have caused an authentication-stage
> failure, so it's not so clear why we'd have looped back at this step.

In the hostssl case, there are two errors emitted on the server side:

[24494] FATAL:  no pg_hba.conf entry for host "192.168.56.101", user "horiguti", database "postgres", SSL off
[24495] FATAL:  no pg_hba.conf entry for host "192.168.56.101", user "horiguti", database "postgres", SSL off

However, the first line is bogus. It should be like the following.

FATAL:  no pg_hba.conf entry for host "192.168.56.101", user "horiguti", database "postgres", GSSENC on
FATAL:  no pg_hba.conf entry for host "192.168.56.101", user "horiguti", database "postgres", SSL off

The attached the first patch does that.
The client picks up only the second error to show from psql.

If I changed the hostssl to just host, host line matches
GSSENC-connection and authentication succeeds without an error.

> We'd need to explain the later cases to have a full theory.  It's
> plenty plausible that something else caused an auth-stage failure,
> but if so, why would the second GSS-free try work?

Does my expample above works?

As the result, psql loses the cause of the first failure and shows the
bogus message. On the other hand the server doesn't know the second
try is the result of the failure of the first try. If we want to show
meaningful messages to users, psql should show both the two messages,
or need to modify the protocol to pass around the information on the
failure of the previous try.

> In any case, that allow_ssl_try reset in pqsecure_open_gss is definitely
> even more broken than I thought before.  I think we need to rejigger the
> state machine so that it doesn't do that at all, but instead skips SSL
> establishment when GSS is already active via an explicit test, rather
> than munging the state variables.

It could make things simpler, but I'm not sure though. Anyway the
states are needed since PQconnectPoll(the state machine) needs to once
exit for negotiation and each of the two paths needs a re-entry point.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
index 3d80930968..204630e383 100644
--- a/src/backend/libpq/auth.c
+++ b/src/backend/libpq/auth.c
@@ -511,6 +511,26 @@ ClientAuthentication(Port *port)
 				}
 				else
 				{
+#ifdef ENABLE_GSS
+#ifdef USE_SSL
+					ereport(FATAL,
+							(errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
+							 errmsg("no pg_hba.conf entry for host \"%s\", user \"%s\", database \"%s\", %s, %s",
+									hostinfo, port->user_name,
+									port->database_name,
+									port->ssl_in_use ? _("SSL on") : _("SSL off"),
+									port->gss->enc ? _("GSSENC on") : _("GSSENC off")),
+							 HOSTNAME_LOOKUP_DETAIL(port)));
+#else /* USE_SSL */
+					ereport(FATAL,
+							(errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
+							 errmsg("no pg_hba.conf entry for host \"%s\", user \"%s\", database \"%s\", %s",
+									hostinfo, port->user_name,
+									port->database_name,
+									port->gss->enc ? _("GSSENC on") : _("GSSENC off")),
+							 HOSTNAME_LOOKUP_DETAIL(port)));
+#endif /* USE_SSL */
+#else  /* ENABLE_GSS */
 #ifdef USE_SSL
 					ereport(FATAL,
 							(errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
@@ -526,6 +546,7 @@ ClientAuthentication(Port *port)
 									hostinfo, port->user_name,
 									port->database_name),
 							 HOSTNAME_LOOKUP_DETAIL(port)));
+#endif
 #endif
 				}
 				break;

Re: Problem with ssl and psql in Postgresql 13

At Thu, 24 Dec 2020 11:54:32 -0500, Tom Lane  wrote in 
> I wrote:
> > Kyotaro Horiguchi  writes:
> >> The attached the first patch does that.
> 
> > +1, it seems like a clear oversight that the GSSENC patches didn't adjust
> > these messages.  The reason SSL state is mentioned is that it's relevant
> > to which pg_hba entry gets chosen; and once we invented "hostgssenc"
> > entries, GSSENC state is also relevant.
> 
> Thinking a little more about that: there are not four distinct states,
> because GSS and SSL can't both be enabled (ProcessStartupPacket enforces
> that).  So I propose that instead of adding a new field, we make the
> existing field say one of three things: "GSS encryption", "SSL
> encryption", or "no encryption".  As per attached.  In the back branches,
> it might be best to spell these as "GSS encryption", "SSL on", and "SSL
> off", just to minimize the cosmetic change.

Looks good to me.

I tried the same case where

- did kinit
- pg_hba has hostssl line only

I saw the following lines in server log, which seems good.

FATAL:  no pg_hba.conf entry for host "192.168.56.101", user "horiguti@MYDOMAIN.COM", database "postgres", GSS encryption
FATAL:  no pg_hba.conf entry for host "192.168.56.101", user "horiguti@MYDOMAIN.COM", database "postgres", no encryption

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Re: Problem with ssl and psql in Postgresql 13

Greetings,

First, thanks a lot for working on all of this and improving things!

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> I've got one last complaint about the backend GSS code: we are doing
> things randomly differently in the two places that install
> krb_server_keyfile as the active KRB5_KTNAME value.  secure_open_gssapi()
> sets KRB5_KTNAME unconditionally (and doesn't bother to check for error,
> either, not a good thing in a security-critical operation).  But the older
> code in pg_GSS_recvauth() is written to not override KRB5_KTNAME if it's
> already set.  This of-course-totally-undocumented behavior seems like a
> fairly bad idea to me: as things stand, the client-side choice of whether
> to initiate GSS encryption or not could result in two different server
> keytabs being used.

I agree that we should be consistent and that always setting the
environment variable if krb_server_keyfile has been set is the right
approach.

> I think we'd be best off to always override KRB5_KTNAME if we have a
> nonempty krb_server_keyfile setting, so the attached proposed patch
> makes both functions do it the same way.  (I did not make an effort
> to remove the dependency on setenv, given the nearby thread to
> standardize on that.)

+1.

> I'm not sure whether there's any documentation change that needs to
> be made.  The docs don't suggest that you're allowed to set
> krb_server_keyfile to an empty string in the first place, so maybe
> we needn't explain what happens if you do.

Perhaps saying something about 'system default' or 'taken from the
environment' might make sense.  That said, the system default almost
always ends up not being usable since it'll be owned by root and we
won't run as root.  Perhaps there are some who prefer to set it via the
environment variable, though I don't think I've ever seen that myself.

I didn't look too closely at the patch itself but on a once-over it
seemed fine to me.

Thanks,

Stephen

Re: SV: Problem with ssl and psql in Postgresql 13

Svensson Peter  writes:
> Yes, libpq patch solved our problem.

Thanks for confirming!  I've pushed that patch and the server-side
fixes, so it'll be in February's releases.

			regards, tom lane

Re: Problem with ssl and psql in Postgresql 13

I've got one last complaint about the backend GSS code: we are doing
things randomly differently in the two places that install
krb_server_keyfile as the active KRB5_KTNAME value.  secure_open_gssapi()
sets KRB5_KTNAME unconditionally (and doesn't bother to check for error,
either, not a good thing in a security-critical operation).  But the older
code in pg_GSS_recvauth() is written to not override KRB5_KTNAME if it's
already set.  This of-course-totally-undocumented behavior seems like a
fairly bad idea to me: as things stand, the client-side choice of whether
to initiate GSS encryption or not could result in two different server
keytabs being used.

I think we'd be best off to always override KRB5_KTNAME if we have a
nonempty krb_server_keyfile setting, so the attached proposed patch
makes both functions do it the same way.  (I did not make an effort
to remove the dependency on setenv, given the nearby thread to
standardize on that.)

I'm not sure whether there's any documentation change that needs to
be made.  The docs don't suggest that you're allowed to set
krb_server_keyfile to an empty string in the first place, so maybe
we needn't explain what happens if you do.

			regards, tom lane

diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
index 515ae95fe1..681448da2c 100644
--- a/src/backend/libpq/auth.c
+++ b/src/backend/libpq/auth.c
@@ -1054,29 +1054,18 @@ pg_GSS_recvauth(Port *port)
 				(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
 				 errmsg("GSSAPI is not supported in protocol version 2")));
 
-	if (pg_krb_server_keyfile && strlen(pg_krb_server_keyfile) > 0)
+	/*
+	 * Use the configured keytab, if there is one.  Unfortunately, Heimdal
+	 * doesn't support the cred store extensions, so use the env var.
+	 */
+	if (pg_krb_server_keyfile != NULL && pg_krb_server_keyfile[0] != '\0')
 	{
-		/*
-		 * Set default Kerberos keytab file for the Krb5 mechanism.
-		 *
-		 * setenv("KRB5_KTNAME", pg_krb_server_keyfile, 0); except setenv()
-		 * not always available.
-		 */
-		if (getenv("KRB5_KTNAME") == NULL)
+		if (setenv("KRB5_KTNAME", pg_krb_server_keyfile, 1) != 0)
 		{
-			size_t		kt_len = strlen(pg_krb_server_keyfile) + 14;
-			char	   *kt_path = malloc(kt_len);
-
-			if (!kt_path ||
-				snprintf(kt_path, kt_len, "KRB5_KTNAME=%s",
-						 pg_krb_server_keyfile) != kt_len - 2 ||
-				putenv(kt_path) != 0)
-			{
-				ereport(LOG,
-						(errcode(ERRCODE_OUT_OF_MEMORY),
-						 errmsg("out of memory")));
-				return STATUS_ERROR;
-			}
+			/* The only likely failure cause is OOM, so report it that way */
+			ereport(FATAL,
+					(errcode(ERRCODE_OUT_OF_MEMORY),
+					 errmsg("out of memory")));
 		}
 	}
 
diff --git a/src/backend/libpq/be-secure-gssapi.c b/src/backend/libpq/be-secure-gssapi.c
index 1747fccb14..e139870c27 100644
--- a/src/backend/libpq/be-secure-gssapi.c
+++ b/src/backend/libpq/be-secure-gssapi.c
@@ -525,8 +525,16 @@ secure_open_gssapi(Port *port)
 	 * Use the configured keytab, if there is one.  Unfortunately, Heimdal
 	 * doesn't support the cred store extensions, so use the env var.
 	 */
-	if (pg_krb_server_keyfile != NULL && strlen(pg_krb_server_keyfile) > 0)
-		setenv("KRB5_KTNAME", pg_krb_server_keyfile, 1);
+	if (pg_krb_server_keyfile != NULL && pg_krb_server_keyfile[0] != '\0')
+	{
+		if (setenv("KRB5_KTNAME", pg_krb_server_keyfile, 1) != 0)
+		{
+			/* The only likely failure cause is OOM, so report it that way */
+			ereport(FATAL,
+					(errcode(ERRCODE_OUT_OF_MEMORY),
+					 errmsg("out of memory")));
+		}
+	}
 
 	while (true)
 	{

Re: Problem with ssl and psql in Postgresql 13

Stephen Frost  writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> I think we'd be best off to always override KRB5_KTNAME if we have a
>> nonempty krb_server_keyfile setting, so the attached proposed patch
>> makes both functions do it the same way.  (I did not make an effort
>> to remove the dependency on setenv, given the nearby thread to
>> standardize on that.)

> +1.

Done, thanks for looking at the patch.

>> I'm not sure whether there's any documentation change that needs to
>> be made.  The docs don't suggest that you're allowed to set
>> krb_server_keyfile to an empty string in the first place, so maybe
>> we needn't explain what happens if you do.

> Perhaps saying something about 'system default' or 'taken from the
> environment' might make sense.

I went with "If this parameter is set to an empty string, it is ignored
and a system-dependent default is used."  I don't think we need to go
into more detail than that, since as you say it's unlikely to be a
useful case.

			regards, tom lane

SV: Problem with ssl and psql in Postgresql 13

SV: SV: SV: Problem with ssl and psql in Postgresql 13

Re: SV: Problem with ssl and psql in Postgresql 13

Gustavsson Mikael  writes:
> Clarification, its the same postgresql13 server. I just connect with different psql-clients.

Perhaps turning on log_connections on the server would offer some
insight.  It sort of looks like the v13 client is trying to connect
with SSL, failing for some unknown reason, and falling back to non-SSL
which also fails.

			regards, tom lane

SV: SV: Problem with ssl and psql in Postgresql 13

Re: SV: SV: SV: SV: Problem with ssl and psql in Postgresql 13

Gustavsson Mikael  writes:
> I did a final test before logging out for Christmas because i found a thread in hackers discussing some issue with GSS and SSL.
> So if i set gssencmode=disable on my pgsql-13 to postgres 13 server connection i get an SSL connection.

Oooh ... that's the missing ingredient.  Do you have a GSS credentials
cache on the client side, but no support on the server side?

It looks like, if there is a credentials cache and gssencmode isn't
explicitly disabled, we try GSS first.  If the server refuses that:

                    if (gss_ok == 'N')
                    {
                        /* Server doesn't want GSSAPI; fall back if we can */
                        if (conn->gssencmode[0] == 'r')
                        {
                            appendPQExpBufferStr(&conn->errorMessage,
                                                 libpq_gettext("server doesn't support GSSAPI encryption, but it was required\n"));
                            goto error_return;
                        }

                        conn->try_gss = false;
                        conn->status = CONNECTION_MADE;
                        return PGRES_POLLING_WRITING;
                    }

that is, it decides the connection it has is good enough.  This
is not OK if SSL should have been used.

			regards, tom lane

Re: SV: SV: SV: SV: Problem with ssl and psql in Postgresql 13

I wrote:
> Gustavsson Mikael  writes:
>> So if i set gssencmode=disable on my pgsql-13 to postgres 13 server connection i get an SSL connection.

> It looks like, if there is a credentials cache and gssencmode isn't
> explicitly disabled, we try GSS first.  If the server refuses that:
> ...
> that is, it decides the connection it has is good enough.  This
> is not OK if SSL should have been used.

No, I misread the code; what will happen next is that an SSL connection
will be tried.  At least, it looks like that should happen, and it does
happen for me.

However: it is true (and undocumented, so we have at least a docs bug
to fix) that v12-and-later libpq will try for GSS encryption first,
and if it succeeds then it will not consider using SSL, regardless of
sslmode.  So about 95% of your report could be explained by assuming
that you have a working Kerberos environment and the newer libpq is
preferring GSS encryption over SSL.  There is just one thing this
theory is failing to explain: instead of "SSL connection", psql
should have printed "GSSAPI-encrypted connection" in your test
shown in .  It didn't,
so this can't be the true explanation.  I think what must be
happening is that libpq is trying for GSS (hence you have at least
a credentials cache somewhere), failing to establish it, and then
for some reason advancing to the startup-packet step without
trying for SSL.  But I can't see how to get the state machine to
do that.

Have you got any environment variables, service files, etc
that would affect libpq's behavior?

			regards, tom lane

Re: Problem with ssl and psql in Postgresql 13

Stephen Frost  writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> However: it is true (and undocumented, so we have at least a docs bug
>> to fix) that v12-and-later libpq will try for GSS encryption first,
>> and if it succeeds then it will not consider using SSL, regardless of
>> sslmode.  So about 95% of your report could be explained by assuming
>> that you have a working Kerberos environment and the newer libpq is
>> preferring GSS encryption over SSL.  There is just one thing this
>> theory is failing to explain: instead of "SSL connection", psql
>> should have printed "GSSAPI-encrypted connection" in your test
>> shown in .  It didn't,
>> so this can't be the true explanation.  I think what must be
>> happening is that libpq is trying for GSS (hence you have at least
>> a credentials cache somewhere), failing to establish it, and then
>> for some reason advancing to the startup-packet step without
>> trying for SSL.  But I can't see how to get the state machine to
>> do that.

> Though we also say under sslmode / prefer (default) -
>   first try an SSL connection; if that fails, try a non-SSL connection
> Obviously they can't both be 'first', so it would probably make sense to
> update the documentation, though exactly how I'm not sure.

Yeah; the problem is that the sslmode docs don't mention that GSS comes
first.  I was thinking of adding verbiage along the lines of "Note that
if GSS encryption is possible, that will be used in preference to SSL,
regardless of the value of sslmode".

In the meantime, I did spot a code path that would explain the symptoms:
pqsecure_open_gss() clears allow_ssl_try sooner than it oughta.  If
gss_wrap_size_limit() failed for some reason, we'd abandon the GSS
connection and try another one, and we would *not* try to SSL-ify
the new one.  While that's clearly a bug, I'm dubious that it explains
this report, because it hardly seems likely that gss_wrap_size_limit()
would fail when we've already successfully negotiated an encrypted
connection.  Can you think of a plausible reason for that to happen?

			regards, tom lane

Re: Problem with ssl and psql in Postgresql 13

Stephen Frost  writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> In the meantime, I did spot a code path that would explain the symptoms:
>> pqsecure_open_gss() clears allow_ssl_try sooner than it oughta.  If
>> gss_wrap_size_limit() failed for some reason, we'd abandon the GSS
>> connection and try another one, and we would *not* try to SSL-ify
>> the new one.

> There are certainly some very odd GSSAPI implementations out there
> (including hacked up things particularly on Macs that we've seen..),
> though I've not run into one where I've seen that call fail.

The OP said he's on RHEL 8.3, so it ought to be mostly-stock Kerberos.
I've just been digging through the SRPM to see if they'd done anything
odd for FIPS mode or the like, and I'm not really finding anything.

> If it did fail though, surely the error messages would make that
> clear, and we're not seeing that here..?

No, because we won't report the failure from gss_wrap_size_limit;
we just discard that connection and try again.

> I'm not sure how, but it sure seems like somehow, in this case, we're
> going through the GSSAPI encryption code because we find GSSAPI
> credentials (entirely possible, even if you're not using them for
> talking to PG), the server responds with a "I haven't got support for
> that" in some fashion, and we're skipping SSL at that point.  How that's
> happening isn't clear to me though, but the idea that it's because
> gss_wrap_size_limit() is failing seems very unlikely.

I already spent most of the day on theories like that, without any
success.  I agree that this theory seems quite unlikely, but you
remember what Sherlock Holmes said.

			regards, tom lane

Re: Problem with ssl and psql in Postgresql 13

Oh ... wait a second.  I've just managed to partially reproduce this
report.  Assume that we have a working Kerberos environment on both
ends.  Then libpq will establish a connection with GSS encryption
and continue on with the usual PG authentication exchange.  If that
part fails, then this logic (fe_connect.c around line 3350):

                    /*
                     * If gssencmode is "prefer" and we're using GSSAPI, retry
                     * without it.
                     */
                    if (conn->gssenc && conn->gssencmode[0] == 'p')
                    {
                        /* postmaster expects us to drop the connection */
                        conn->try_gss = false;
                        pqDropConnection(conn, true);
                        conn->status = CONNECTION_NEEDED;
                        goto keep_going;
                    }

drops the connection and tries again without GSS.  But *we already
cleared allow_ssl_try*, in pqsecure_open_gss, so the next try will
not bother with SSL either.

So this directly explains the original report: if the only applicable
pg_hba.conf entry is "hostssl", right here is where libpq will see
that error, and it will go around and fail again because the next
try uses neither GSS nor SSL.

However, in the tests Mikael ran after backing that pg_hba.conf entry
off to just "host", pg_hba wouldn't have caused an authentication-stage
failure, so it's not so clear why we'd have looped back at this step.
We'd need to explain the later cases to have a full theory.  It's
plenty plausible that something else caused an auth-stage failure,
but if so, why would the second GSS-free try work?

In any case, that allow_ssl_try reset in pqsecure_open_gss is definitely
even more broken than I thought before.  I think we need to rejigger the
state machine so that it doesn't do that at all, but instead skips SSL
establishment when GSS is already active via an explicit test, rather
than munging the state variables.

			regards, tom lane

Re: Problem with ssl and psql in Postgresql 13

Kyotaro Horiguchi  writes:
> At Wed, 23 Dec 2020 17:34:05 -0500, Tom Lane  wrote in 
>> However, in the tests Mikael ran after backing that pg_hba.conf entry
>> off to just "host", pg_hba wouldn't have caused an authentication-stage
>> failure, so it's not so clear why we'd have looped back at this step.

> In the hostssl case, there are two errors emitted on the server side:
> [24494] FATAL:  no pg_hba.conf entry for host "192.168.56.101", user "horiguti", database "postgres", SSL off
> [24495] FATAL:  no pg_hba.conf entry for host "192.168.56.101", user "horiguti", database "postgres", SSL off
> However, the first line is bogus. It should be like the following.
> FATAL:  no pg_hba.conf entry for host "192.168.56.101", user "horiguti", database "postgres", GSSENC on
> FATAL:  no pg_hba.conf entry for host "192.168.56.101", user "horiguti", database "postgres", SSL off
> The attached the first patch does that.

+1, it seems like a clear oversight that the GSSENC patches didn't adjust
these messages.  The reason SSL state is mentioned is that it's relevant
to which pg_hba entry gets chosen; and once we invented "hostgssenc"
entries, GSSENC state is also relevant.  I'm not sure though if we want
to spell it like "GSSENC on", or "GSS encryption on", or something else.
Stephen or other onlookers, any comments?

>> We'd need to explain the later cases to have a full theory.  It's
>> plenty plausible that something else caused an auth-stage failure,
>> but if so, why would the second GSS-free try work?

> Does my expample above works?

I don't see how it explains Mikael's later tests, but maybe I'm missing
something.

			regards, tom lane

Re: Problem with ssl and psql in Postgresql 13

I wrote:
> Kyotaro Horiguchi  writes:
>> The attached the first patch does that.

> +1, it seems like a clear oversight that the GSSENC patches didn't adjust
> these messages.  The reason SSL state is mentioned is that it's relevant
> to which pg_hba entry gets chosen; and once we invented "hostgssenc"
> entries, GSSENC state is also relevant.

Thinking a little more about that: there are not four distinct states,
because GSS and SSL can't both be enabled (ProcessStartupPacket enforces
that).  So I propose that instead of adding a new field, we make the
existing field say one of three things: "GSS encryption", "SSL
encryption", or "no encryption".  As per attached.  In the back branches,
it might be best to spell these as "GSS encryption", "SSL on", and "SSL
off", just to minimize the cosmetic change.

			regards, tom lane

diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
index 3d80930968..45572161cb 100644
--- a/src/backend/libpq/auth.c
+++ b/src/backend/libpq/auth.c
@@ -412,44 +412,37 @@ ClientAuthentication(Port *port)
 			 */
 			{
 				char		hostinfo[NI_MAXHOST];
+				const char *encryption_state;
 
 				pg_getnameinfo_all(&port->raddr.addr, port->raddr.salen,
 								   hostinfo, sizeof(hostinfo),
 								   NULL, 0,
 								   NI_NUMERICHOST);
 
-				if (am_walsender)
-				{
+				encryption_state =
+#ifdef ENABLE_GSS
+					port->gss->enc ? _("GSS encryption") :
+#endif
 #ifdef USE_SSL
+					port->ssl_in_use ? _("SSL encryption") :
+#endif
+					_("no encryption");
+
+				if (am_walsender)
 					ereport(FATAL,
 							(errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
+					/* translator: last %s describes encryption state */
 							 errmsg("pg_hba.conf rejects replication connection for host \"%s\", user \"%s\", %s",
 									hostinfo, port->user_name,
-									port->ssl_in_use ? _("SSL on") : _("SSL off"))));
-#else
-					ereport(FATAL,
-							(errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
-							 errmsg("pg_hba.conf rejects replication connection for host \"%s\", user \"%s\"",
-									hostinfo, port->user_name)));
-#endif
-				}
+									encryption_state)));
 				else
-				{
-#ifdef USE_SSL
 					ereport(FATAL,
 							(errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
+					/* translator: last %s describes encryption state */
 							 errmsg("pg_hba.conf rejects connection for host \"%s\", user \"%s\", database \"%s\", %s",
 									hostinfo, port->user_name,
 									port->database_name,
-									port->ssl_in_use ? _("SSL on") : _("SSL off"))));
-#else
-					ereport(FATAL,
-							(errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
-							 errmsg("pg_hba.conf rejects connection for host \"%s\", user \"%s\", database \"%s\"",
-									hostinfo, port->user_name,
-									port->database_name)));
-#endif
-				}
+									encryption_state)));
 				break;
 			}
 
@@ -465,12 +458,22 @@ ClientAuthentication(Port *port)
 			 */
 			{
 				char		hostinfo[NI_MAXHOST];
+				const char *encryption_state;
 
 				pg_getnameinfo_all(&port->raddr.addr, port->raddr.salen,
 								   hostinfo, sizeof(hostinfo),
 								   NULL, 0,
 								   NI_NUMERICHOST);
 
+				encryption_state =
+#ifdef ENABLE_GSS
+					port->gss->enc ? _("GSS encryption") :
+#endif
+#ifdef USE_SSL
+					port->ssl_in_use ? _("SSL encryption") :
+#endif
+					_("no encryption");
+
 #define HOSTNAME_LOOKUP_DETAIL(port) \
 				(port->remote_hostname ? \
 				 (port->remote_hostname_resolv == +1 ? \
@@ -493,41 +496,22 @@ ClientAuthentication(Port *port)
 					0))
 
 				if (am_walsender)
-				{
-#ifdef USE_SSL
 					ereport(FATAL,
 							(errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
+					/* translator: last %s describes encryption state */
 							 errmsg("no pg_hba.conf entry for replication connection from host \"%s\", user \"%s\", %s",
 									hostinfo, port->user_name,
-									port->ssl_in_use ? _("SSL on") : _("SSL off")),
+									encryption_state),
 							 HOSTNAME_LOOKUP_DETAIL(port)));
-#else
-					ereport(FATAL,
-							(errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
-							 errmsg("no pg_hba.conf entry for replication connection from host \"%s\", user \"%s\"",
-									hostinfo, port->user_name),
-							 HOSTNAME_LOOKUP_DETAIL(port)));
-#endif
-				}
 				else
-				{
-#ifdef USE_SSL
 					ereport(FATAL,
 							(errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
+					/* translator: last %s describes encryption state */
 							 errmsg("no pg_hba.conf entry for host \"%s\", user \"%s\", database \"%s\", %s",
 									hostinfo, port->user_name,
 									port->database_name,
-									port->ssl_in_use ? _("SSL on") : _("SSL off")),
-							 HOSTNAME_LOOKUP_DETAIL(port)));
-#else
-					ereport(FATAL,
-							(errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
-							 errmsg("no pg_hba.conf entry for host \"%s\", user \"%s\", database \"%s\"",
-									hostinfo, port->user_name,
-									port->database_name),
+									encryption_state),
 							 HOSTNAME_LOOKUP_DETAIL(port)));
-#endif
-				}
 				break;
 			}
 

Re: SV: SV: Problem with ssl and psql in Postgresql 13

Gustavsson Mikael  writes:
> $ /usr/pgsql-13/bin/psql "dbname=postgres user=kalle host=server sslmode=require"
> psql: error: FATAL:  no pg_hba.conf entry for host "nn.nnn.n.nnn", user "kalle", database "postgres", SSL off
> FATAL:  no pg_hba.conf entry for host "nn.nnn.n.nnn", user "kalle", database "postgres", SSL off

It'd be useful to verify that that version of psql+libpq is actually
built with ssl support.  Try

ldd /usr/pgsql-13/bin/psql

and then repeat "ldd" on whichever libpq.so is mentioned in the output.

			regards, tom lane

SV: SV: Problem with ssl and psql in Postgresql 13

SV: SV: Problem with ssl and psql in Postgresql 13

SV: SV: SV: SV: Problem with ssl and psql in Postgresql 13

Re: SV: Problem with ssl and psql in Postgresql 13

That's setting a variable, not a parameter.

You need something like

psql "dbname=postgres user=kalle host=server sslmode=require"

Or
PGSSLMODE=require /usr/bin/pgsql-same-as-you-had-before

//Magnus

On Thu, Dec 17, 2020 at 5:00 PM Gustavsson Mikael
 wrote:
>
> Hi Magnus,
>
>
> The clients 11 and 13 is on the same host.
>
>
> Hmm, I get the same error if I set sslmode=require.
>
>
> $ /usr/pgsql-13/bin/psql -d postgres --set=sslmode=require -Ukalle -hserver -W
> Password:
> psql: error: FATAL:  no pg_hba.conf entry for host "nn.nnn.n.nnn", user "kalle", database "postgres", SSL off
> FATAL:  no pg_hba.conf entry for host "nn.nnn.n.nnn", user "kalle", database "postgres", SSL off
>
> KR Mikael Gustavsson, SMHI
>
>
> ________________________________
> Från: Magnus Hagander 
> Skickat: den 17 december 2020 15:52:55
> Till: Gustavsson Mikael
> Kopia: Tom Lane; Kyotaro Horiguchi; pgsql-general@postgresql.org; Svensson Peter
> Ämne: Re: SV: Problem with ssl and psql in Postgresql 13
>
> On Thu, Dec 17, 2020 at 3:36 PM Gustavsson Mikael
>  wrote:
> >
> >
> > Hi,
> >
> > log_connections is on. The ERR message is correct, we do not have an entry for SSL off.
> > The question is why psql(13) is trying to connect without ssl?
> >
> > 2020-12-17T14:25:09.565566+00:00 server INFO [30-1] pgpid=2422778 pguser=[unknown] pghost=nnn.nn.n.nnn pgdb=[unknown] pgapp=[unknown] LOG:  connection received: host=nnn.nn.n.nnn port=40112
> > 2020-12-17T14:25:09.566411+00:00 server ERR [31-1] pgpid=2422778 pguser=kalle pghost=nnn.nn.n.nnn pgdb=postgres pgapp=[unknown] FATAL:  no pg_hba.conf entry for host "nnn.nn.n.nnn", user "kalle", database "postgres", SSL off
>
>
> By default psql/libpq will fall back to a clear text connection if the
> ssl encrypted one failed. Specify sslmode=require (or preferably
> higher) in the connection string or set PGSSLMODE=require on the
> client to disable that behavior. If you do that, my guess is you will
> see a direct connection failure instead of that error?
>
> PostgreSQL 13 did change the default value for minimum tls version to
> 1.2. But that seems unlikely to be the problem since you get TLS 1.3
> when you use the old version...
>
> I assume you're running both the 11 and the 13 client on the same host?


-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/

Re: SV: Problem with ssl and psql in Postgresql 13

On Thu, Dec 17, 2020 at 3:36 PM Gustavsson Mikael
 wrote:
>
>
> Hi,
>
> log_connections is on. The ERR message is correct, we do not have an entry for SSL off.
> The question is why psql(13) is trying to connect without ssl?
>
> 2020-12-17T14:25:09.565566+00:00 server INFO [30-1] pgpid=2422778 pguser=[unknown] pghost=nnn.nn.n.nnn pgdb=[unknown] pgapp=[unknown] LOG:  connection received: host=nnn.nn.n.nnn port=40112
> 2020-12-17T14:25:09.566411+00:00 server ERR [31-1] pgpid=2422778 pguser=kalle pghost=nnn.nn.n.nnn pgdb=postgres pgapp=[unknown] FATAL:  no pg_hba.conf entry for host "nnn.nn.n.nnn", user "kalle", database "postgres", SSL off


By default psql/libpq will fall back to a clear text connection if the
ssl encrypted one failed. Specify sslmode=require (or preferably
higher) in the connection string or set PGSSLMODE=require on the
client to disable that behavior. If you do that, my guess is you will
see a direct connection failure instead of that error?

PostgreSQL 13 did change the default value for minimum tls version to
1.2. But that seems unlikely to be the problem since you get TLS 1.3
when you use the old version...

I assume you're running both the 11 and the 13 client on the same host?

-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/

SV: SV: SV: Problem with ssl and psql in Postgresql 13

SV: SV: SV: SV: Problem with ssl and psql in Postgresql 13

Problem with ssl and psql in Postgresql 13