Home • Explore • Blog • CI
☰



postgresql
24th chunk of `doc/src/sgml/protocol.sgml`
50413ac3dce66e0c5bd3b17720b5843b5c104feda23d50530000000100000fa2
 negotiation until it receives the server's
     single byte response to the <acronym>SSL</acronym> request.  If the
     client begins the <acronym>SSL</acronym> negotiation immediately without
     waiting for the server response to be received it can reduce connection
     latency by one round-trip.  However this comes at the cost of not being
     able to handle the case where the server sends a negative response to the
     <acronym>SSL</acronym> request.  In that case instead of continuing with either GSSAPI or an
     unencrypted connection or a protocol error the server will simply
     disconnect.
   </para>

   <para>
    An initial SSLRequest can also be used in a connection that is being
    opened to send a CancelRequest message.
   </para>

   <para>
     A second alternate way to initiate <acronym>SSL</acronym> encryption is
     available.  The server will recognize connections which immediately
     begin <acronym>SSL</acronym> negotiation without any previous SSLRequest
     packets.  Once the <acronym>SSL</acronym> connection is established the
     server will expect a normal startup-request packet and continue
     negotiation over the encrypted channel.  In this case any other requests
     for encryption will be refused.  This method is not preferred for general
     purpose tools as it cannot negotiate the best connection encryption
     available or handle unencrypted connections.  However it is useful for
     environments where both the server and client are controlled together.
     In that case it avoids one round trip of latency and allows the use of
     network tools that depend on standard <acronym>SSL</acronym> connections.
     When using <acronym>SSL</acronym> connections in this style the client is
     required to use the ALPN extension defined
     by <ulink url="https://tools.ietf.org/html/rfc7301">RFC 7301</ulink> to
     protect against protocol confusion attacks.
     The <productname>PostgreSQL</productname> protocol is "postgresql" as
     registered
     at <ulink url="https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids">IANA
     TLS ALPN Protocol IDs</ulink> registry.
   </para>

   <para>
    While the protocol itself does not provide a way for the server to
    force <acronym>SSL</acronym> encryption, the administrator can
    configure the server to reject unencrypted sessions as a byproduct
    of authentication checking.
   </para>
  </sect2>

  <sect2 id="protocol-flow-gssapi">
   <title><acronym>GSSAPI</acronym> Session Encryption</title>

   <para>
    If <productname>PostgreSQL</productname> was built with
    <acronym>GSSAPI</acronym> support, frontend/backend communications
    can be encrypted using <acronym>GSSAPI</acronym>.  This provides
    communication security in environments where attackers might be
    able to capture the session traffic. For more information on
    encrypting <productname>PostgreSQL</productname> sessions with
    <acronym>GSSAPI</acronym>, see <xref linkend="gssapi-enc"/>.
   </para>

   <para>
    To initiate a <acronym>GSSAPI</acronym>-encrypted connection, the
    frontend initially sends a GSSENCRequest message rather than a
    StartupMessage.  The server then responds with a single byte
    containing <literal>G</literal> or <literal>N</literal>, indicating that it
    is willing or unwilling to perform <acronym>GSSAPI</acronym> encryption,
    respectively.  The frontend might close the connection at this point
    if it is dissatisfied with the response.  To continue after
    <literal>G</literal>, using the GSSAPI C bindings as discussed in
    <ulink url="https://datatracker.ietf.org/doc/html/rfc2744">RFC 2744</ulink>
    or equivalent, perform a <acronym>GSSAPI</acronym> initialization by
    calling <function>gss_init_sec_context()</function> in a loop and sending
    the result to the server, starting with an empty input and then with each
    result from the server, until it
Title: SSL and GSSAPI Encryption in PostgreSQL
Summary
PostgreSQL supports SSL and GSSAPI encryption for secure communication between the frontend and backend, with the client initiating encryption by sending an SSLRequest or GSSENCRequest message, and the server responding with a single byte indicating willingness or unwillingness to perform encryption, after which the client and server negotiate the encryption protocol, with the client required to handle potential error messages and protocol violations, and the server expecting the client to wait for its response before initiating encryption negotiation, or alternatively, the client can immediately begin SSL negotiation without waiting for the server's response, reducing latency but limiting the ability to handle negative responses.