options include dm-crypt + LUKS on Linux and GEOM
     modules geli and gbde on FreeBSD.  Many other operating systems
     support this functionality, including Windows.
    </para>

    <para>
     This mechanism prevents unencrypted data from being read from the
     drives if the drives or the entire computer is stolen. This does
     not protect against attacks while the file system is mounted,
     because when mounted, the operating system provides an unencrypted
     view of the data. However, to mount the file system, you need some
     way for the encryption key to be passed to the operating system,
     and sometimes the key is stored somewhere on the host that mounts
     the disk.
    </para>
   </listitem>
  </varlistentry>

  <varlistentry>
   <term>Encrypting Data Across A Network</term>

    <listitem>
     <para>
      SSL connections encrypt all data sent across the network: the
      password, the queries, and the data returned. The
      <filename>pg_hba.conf</filename> file allows administrators to specify
      which hosts can use non-encrypted connections (<literal>host</literal>)
      and which require SSL-encrypted connections
      (<literal>hostssl</literal>). Also, clients can specify that they
      connect to servers only via SSL.
     </para>

     <para>
      GSSAPI-encrypted connections encrypt all data sent across the network,
      including queries and data returned.  (No password is sent across the
      network.)  The <filename>pg_hba.conf</filename> file allows
      administrators to specify which hosts can use non-encrypted connections
      (<literal>host</literal>) and which require GSSAPI-encrypted connections
      (<literal>hostgssenc</literal>).  Also, clients can specify that they
      connect to servers only on GSSAPI-encrypted connections
      (<literal>gssencmode=require</literal>).
     </para>

     <para>
      <application>Stunnel</application> or
      <application>SSH</application> can also be used to encrypt
      transmissions.
     </para>
    </listitem>
  </varlistentry>

  <varlistentry>
   <term>SSL Host Authentication</term>

   <listitem>
    <para>
     It is possible for both the client and server to provide SSL
     certificates to each other. It takes some extra configuration
     on each side, but this provides stronger verification of identity
     than the mere use of passwords. It prevents a computer from
     pretending to be the server just long enough to read the password
     sent by the client. It also helps prevent <quote>man in the middle</quote>
     attacks where a computer between the client and server pretends to
     be the server and reads and passes all data between the client and
     server.
    </para>
   </listitem>
  </varlistentry>

  <varlistentry>
   <term>Client-Side Encryption</term>

   <listitem>
    <para>
     If the system administrator for the server's machine cannot be trusted,
     it is necessary
     for the client to encrypt the data; 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