this way, unencrypted data
     never appears on the database server. Data is encrypted on the
     client before being sent to the server, and database results have
     to be decrypted on the client before being used.
    </para>
   </listitem>
  </varlistentry>

  </variablelist>

 </sect1>

 <sect1 id="ssl-tcp">
  <title>Secure TCP/IP Connections with SSL</title>

  <indexterm zone="ssl-tcp">
   <primary>SSL</primary>
   <secondary>TLS</secondary>
  </indexterm>

  <para>
   <productname>PostgreSQL</productname> has native support for using
   <acronym>SSL</acronym> connections to encrypt client/server communications
   for increased security. This requires that
   <productname>OpenSSL</productname> is installed on both client and
   server systems and that support in <productname>PostgreSQL</productname> is
   enabled at build time (see <xref linkend="installation"/>).
  </para>

  <para>
   The terms <acronym>SSL</acronym> and <acronym>TLS</acronym> are often used
   interchangeably to mean a secure encrypted connection using a
   <acronym>TLS</acronym> protocol. <acronym>SSL</acronym> protocols are the
   precursors to <acronym>TLS</acronym> protocols, and the term
   <acronym>SSL</acronym> is still used for encrypted connections even though
   <acronym>SSL</acronym> protocols are no longer supported.
   <acronym>SSL</acronym> is used interchangeably with <acronym>TLS</acronym>
   in <productname>PostgreSQL</productname>.

  </para>
  <sect2 id="ssl-setup">
   <title>Basic Setup</title>

  <para>
   With <acronym>SSL</acronym> support compiled in, the
   <productname>PostgreSQL</productname> server can be started with
   support for encrypted connections using <acronym>TLS</acronym> protocols
   enabled by setting the parameter
   <xref linkend="guc-ssl"/> to <literal>on</literal> in
   <filename>postgresql.conf</filename>.  The server will listen for both normal
   and <acronym>SSL</acronym> connections on the same TCP port, and will negotiate
   with any connecting client on whether to use <acronym>SSL</acronym>.  By
   default, this is at the client's option; see <xref
   linkend="auth-pg-hba-conf"/> about how to set up the server to require
   use of <acronym>SSL</acronym> for some or all connections.
  </para>

  <para>
   To start in <acronym>SSL</acronym> mode, files containing the server certificate
   and private key must exist.  By default, these files are expected to be
   named <filename>server.crt</filename> and <filename>server.key</filename>, respectively, in
   the server's data directory, but other names and locations can be specified
   using the configuration parameters <xref linkend="guc-ssl-cert-file"/>
   and <xref linkend="guc-ssl-key-file"/>.
  </para>

  <para>
   On Unix systems, the permissions on <filename>server.key</filename> must
   disallow any access to world or group; achieve this by the command
   <command>chmod 0600 server.key</command>.  Alternatively, the file can be
   owned by root and have group read access (that is, <literal>0640</literal>
   permissions).  That setup is intended for installations where certificate
   and key files are managed by the operating system.  The user under which
   the <productname>PostgreSQL</productname> server runs should then be made a
   member of the group that has access to those certificate and key files.
  </para>

  <para>
    If the data directory allows group read access then certificate files may
    need to be located outside of the data directory in order to conform to the
    security requirements outlined above.  Generally, group access is enabled
    to allow an unprivileged user to backup the database, and in that case the
    backup software will not be able to read the certificate files and will
    likely error.
  </para>

  <para>
   If the private key is protected with a passphrase, the
   server will prompt for the passphrase and will not start until it has
   been entered.
   Using a passphrase by default disables the ability