directory would still be secure because
   of directory permissions. Spoofing is possible because any user can
   start a database server; a client cannot identify an invalid server
   unless it is specially configured.
  </para>

  <para>
   One way to prevent spoofing of <literal>local</literal>
   connections is to use a Unix domain socket directory (<xref
   linkend="guc-unix-socket-directories"/>) that has write permission only
   for a trusted local user.  This prevents a malicious user from creating
   their own socket file in that directory.  If you are concerned that
   some applications might still reference <filename>/tmp</filename> for the
   socket file and hence be vulnerable to spoofing, during operating system
   startup create a symbolic link <filename>/tmp/.s.PGSQL.5432</filename> that points
   to the relocated socket file.  You also might need to modify your
   <filename>/tmp</filename> cleanup script to prevent removal of the symbolic link.
  </para>

  <para>
   Another option for <literal>local</literal> connections is for clients to use
   <link linkend="libpq-connect-requirepeer"><literal>requirepeer</literal></link>
   to specify the required owner of the server process connected to
   the socket.
  </para>

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

  <para>
   To prevent spoofing with SSL, the server
   must be configured to accept only <literal>hostssl</literal> connections (<xref
   linkend="auth-pg-hba-conf"/>) and have SSL key and certificate files
   (<xref linkend="ssl-tcp"/>). The TCP client must connect using
   <literal>sslmode=verify-ca</literal> or
   <literal>verify-full</literal> and have the appropriate root certificate
   file installed (<xref linkend="libq-ssl-certificates"/>). Alternatively the
   <link linkend="libpq-connect-sslrootcert">system CA pool</link>, as defined
   by the SSL implementation, can be used using <literal>sslrootcert=system</literal>; in
   this case, <literal>sslmode=verify-full</literal> is forced for safety, since
   it is generally trivial to obtain certificates which are signed by a public
   CA.
  </para>

  <para>
   To prevent server spoofing from occurring when using
   <link linkend="auth-password">scram-sha-256</link> password authentication
   over a network, you should ensure that you connect to the server using SSL
   and with one of the anti-spoofing methods described in the previous
   paragraph. Additionally, the SCRAM implementation in
   <application>libpq</application> cannot protect the entire authentication
   exchange, but using the <literal>channel_binding=require</literal> connection
   parameter provides a mitigation against server spoofing. An attacker that
   uses a rogue server to intercept a SCRAM exchange can use offline analysis to
   potentially determine the hashed password from the client.
  </para>

  <para>
    To prevent spoofing with GSSAPI, the server must be configured to accept
    only <literal>hostgssenc</literal> connections
    (<xref linkend="auth-pg-hba-conf"/>) and use <literal>gss</literal>
    authentication with them.  The TCP client must connect
    using <literal>gssencmode=require</literal>.
  </para>
 </sect1>

 <sect1 id="encryption-options">
  <title>Encryption Options</title>

  <indexterm zone="encryption-options">
   <primary>encryption</primary>
  </indexterm>

  <para>
   <productname>PostgreSQL</productname> offers encryption at several
   levels, and provides flexibility in protecting data from disclosure
   due to database server theft, unscrupulous administrators, and
   insecure networks. Encryption might also be required to secure
   sensitive data such as medical records or financial transactions.
  </para>

  <variablelist>

  <varlistentry>
   <term>Password Encryption</term>
   <listitem>

    <para>
     Database