<para>
The frontend should also be prepared to handle an ErrorMessage
- response to SSLRequest from the server. This would only occur if
- the server predates the addition of <acronym>SSL</acronym> support
- to <productname>PostgreSQL</productname>. (Such servers are now very ancient,
- and likely do not exist in the wild anymore.)
+ response to SSLRequest from the server. The frontend should not display
+ this error message to the user/application, since the server has not been
+ authenticated
+ (<ulink url="https://www.postgresql.org/support/security/CVE-2024-10977/">CVE-2024-10977</ulink>).
In this case the connection must
be closed, but the frontend might choose to open a fresh connection
and proceed without requesting <acronym>SSL</acronym>.
<para>
The frontend should also be prepared to handle an ErrorMessage
- response to GSSENCRequest from the server. This would only occur if
- the server predates the addition of <acronym>GSSAPI</acronym> encryption
- support to <productname>PostgreSQL</productname>. In this case the
- connection must be closed, but the frontend might choose to open a fresh
- connection and proceed without requesting <acronym>GSSAPI</acronym>
- encryption.
+ response to GSSENCRequest from the server. The frontend should not display
+ this error message to the user/application, since the server has not been
+ authenticated
+ (<ulink url="https://www.postgresql.org/support/security/CVE-2024-10977/">CVE-2024-10977</ulink>).
+ In this case the connection must be closed, but the frontend might choose
+ to open a fresh connection and proceed without requesting
+ <acronym>GSSAPI</acronym> encryption.
</para>
<para>
{
/*
* Server failure of some sort, such as failure to
- * fork a backend process. We need to process and
- * report the error message, which might be formatted
- * according to either protocol 2 or protocol 3.
- * Rather than duplicate the code for that, we flip
- * into AWAITING_RESPONSE state and let the code there
- * deal with it. Note we have *not* consumed the "E"
- * byte here.
+ * fork a backend process. Don't bother retrieving
+ * the error message; we should not trust it as the
+ * server has not been authenticated yet.
*/
- conn->status = CONNECTION_AWAITING_RESPONSE;
-
- /*
- * Don't fall back to a plaintext connection after
- * reading the error.
- */
- conn->failed_enc_methods |= conn->allowed_enc_methods & (~conn->current_enc_method);
- goto keep_going;
+ libpq_append_conn_error(conn, "server sent an error response during SSL exchange");
+ goto error_return;
}
else
{
{
/*
* Server failure of some sort, possibly protocol
- * version support failure. We need to process and
- * report the error message, which might be formatted
- * according to either protocol 2 or protocol 3.
- * Rather than duplicate the code for that, we flip
- * into AWAITING_RESPONSE state and let the code there
- * deal with it. Note we have *not* consumed the "E"
- * byte here.
+ * version support failure. Don't bother retrieving
+ * the error message; we should not trust it anyway as
+ * the server has not authenticated yet.
*
* Note that unlike on an error response to
* SSLRequest, we allow falling back to SSL or
* response might mean that we are connecting to a
* pre-v12 server.
*/
- conn->status = CONNECTION_AWAITING_RESPONSE;
- goto keep_going;
+ libpq_append_conn_error(conn, "server sent an error response during GSS encryption exchange");
+ CONNECTION_FAILED();
}
/* mark byte consumed */