Add documentation section about preventing server spoofing.
authorBruce Momjian
Tue, 25 Dec 2007 04:00:44 +0000 (04:00 +0000)
committerBruce Momjian
Tue, 25 Dec 2007 04:00:44 +0000 (04:00 +0000)
Update SSL documention to be clearer about certificates, and restructure
for clarity.

doc/src/sgml/libpq.sgml
doc/src/sgml/runtime.sgml

index fec498c19a8536cdaff7c8a770dd6d0c46d0cd10..be43ec7814ff8a173ce567b120ebb37a21640ff5 100644 (file)
@@ -1,4 +1,4 @@
-
+
 
 
  <application>libpq</application> - C Library
@@ -5151,16 +5151,33 @@ defaultNoticeProcessor(void *arg, const char *message)
   
 
   
-   If the server demands a client certificate,
+   To verify the server certificate is trustworthy, place certificates of
+   the certificate authorities (CA) you trust in the
+   file ~/.postgresql/root.crt in the user's home directory.
+   (On Microsoft Windows the file is named
+   %APPDATA%\postgresql\root.crt.)
+   libpq will then verify that the server's
+   certificate is signed by one of the trusted certificate authorities.
+   The SSL connection will fail if the server does not present a trusted
+   certificate.  Certificate Revocation List (CRL) entries are also checked
+   if the file ~/.postgresql/root.crl exists
+   (%APPDATA%\postgresql\root.crl on Microsoft
+   Windows).
+  
+
+  
+   If the server requests a trusted client certificate,
    libpq will send the certificate stored in
-   file ~/.postgresql/postgresql.crt within the user's home
-   directory.  A matching private key file
-   ~/.postgresql/postgresql.key must also be present, unless
-   the secret key for the certificate is stored in a hardware token, as
-   specified by PGSSLKEY.  (On Microsoft Windows these
-   files are named %APPDATA%\postgresql\postgresql.crt
-   and %APPDATA%\postgresql\postgresql.key.) The
-   private key file must not be world-readable.
+   file ~/.postgresql/postgresql.crt in the user's home
+   directory.  The certificate must be signed by one of the certificate
+   authorities (CA) trusted by the server.  A matching
+   private key file ~/.postgresql/postgresql.key must also
+   be present, unless the secret key for the certificate is stored in a
+   hardware token, as specified by PGSSLKEY.  (On Microsoft
+   Windows these files are named
+   %APPDATA%\postgresql\postgresql.crt and
+   %APPDATA%\postgresql\postgresql.key.) The private
+   key file must not be world-readable.
   
 
   
@@ -5175,20 +5192,6 @@ defaultNoticeProcessor(void *arg, const char *message)
    the hardware token.
   
 
-  
-   If the file ~/.postgresql/root.crt is present in the user's
-   home directory, libpq will use the
-   certificate list stored therein to verify the server's certificate.
-   (On Microsoft Windows the file is named
-   %APPDATA%\postgresql\root.crt.) The SSL connection
-   will fail if the server does not present a certificate; therefore, to
-   use this feature the server must have a server.crt file.
-   Certificate Revocation List (CRL) entries are also checked if the file
-   ~/.postgresql/root.crl exists
-   (%APPDATA%\postgresql\root.crl on Microsoft
-   Windows).
-  
-
   
    If you are using SSL inside your application (in addition
    to inside libpq), you can use
@@ -5197,7 +5200,6 @@ defaultNoticeProcessor(void *arg, const char *message)
    application.
   
 
-
  
 
 
index 1ba11602e8470359a4a8c43d715fde8f171a253c..b9f312daeda7f29b3e05a5650497bca03f8ef03b 100644 (file)
@@ -1,4 +1,4 @@
-
+
 
 
  Operating System Environment
@@ -1373,6 +1373,42 @@ $ kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`
   
  
 
+  Preventing Server Spoofing
+
+  
+   server spoofing
+  
+
+  
+   While the server is running, it is not possible for a malicious user
+   to interfere with client/server communications.  However, when the
+   server is down it is possible for a local user to spoof the normal
+   server by starting their own server.  The spoof server could read
+   passwords and queries sent by clients, but could not return any data
+   because the PGDATA 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.
+  
+
+  
+   The simplest way to prevent invalid servers for local
+   connections is to use a Unix domain socket directory (
+   linkend="guc-unix-socket-directory">) that has write permission only
+   for a trusted local user.  This prevents a malicious user from creating
+   their own socket file in that directory.  For TCP connections the server
+   must accept only hostssl connections (
+   linkend="auth-pg-hba-conf">) and have SSL
+   server.key (key) and
+   server.crt (certificate) files (
+   linkend="ssl-tcp">). The TCP client must connect using
+   sslmode='require' () and have
+   a ~/.postgresql/root.crt SSL certificate (
+   linkend="libpq-ssl">).
+  
+  
  
   Encryption Options
 
@@ -1545,97 +1581,105 @@ $ kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`
    PostgreSQL server can be started with
    SSL enabled by setting the parameter
     to on in
-   postgresql.conf. When
-   starting in SSL mode, the server will look for the
-   files server.key and server.crt in the
-   data directory, which must contain the server private key
-   and certificate, respectively. These files must be set up correctly
-   before an SSL-enabled server can start. 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.
+   postgresql.conf.  The server will listen for both standard
+   and SSL connections on the same TCP port, and will negotiate
+   with any connecting client on whether to use SSL.  By
+   default, this is at the client's option; see 
+   linkend="auth-pg-hba-conf"> about how to set up the server to require
+   use of SSL for some or all connections.
   
 
   
-   The server will listen for both standard and SSL
-   connections on the same TCP port, and will negotiate with any
-   connecting client on whether to use SSL.  By default,
-   this is at the client's option; see 
-   linkend="auth-pg-hba-conf"> about how to set up the server to
-   require use of SSL for some or all connections.
+   PostgreSQL reads the system-wide
+   OpenSSL configuration file. By default, this
+   file is named openssl.cnf and is located in the
+   directory reported by openssl version -d.
+   This default can be overridden by setting environment variable
+   OPENSSL_CONF to the name of the desired configuration file.
   
 
   
    OpenSSL supports a wide range of ciphers
-   and authentication algorithms, whose strength varies significantly.
-   You can restrict the list of ciphers that can be used to connect to
-   your server by adjusting the  parameter.
+   and authentication algorithms, of varying strength.  While a list of
+   ciphers can be specified in the OpenSSL
+   configuration file, you can specify ciphers specifically for use by
+   the database server by modifying  in
+   postgresql.conf.
   
 
   
-   PostgreSQL reads the system-wide
-   OpenSSL configuration file. By default, this
-   file is named openssl.cnf and is located in the
-   directory reported by openssl version -d.
-   This default can be overridden by setting environment variable
-   OPENSSL_CONF to the name of the desired configuration file.
+   To start in SSL mode, the files server.crt
+   and server.key must exist in the server's data directory.
+   These files should contain the server certificate and private key,
+   respectively. 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.
+  
+
+  
+   To require the client to supply a trusted certificate, place
+   certificates of the certificate authorities (CA)
+   you trust in the file root.crt in the data
+   directory.  A certificate will then be requested from the client during
+   SSL connection startup.  (See  for a
+   description of how to set up client certificates.)  The server will
+   verify that the client's certificate is signed by one of the trusted
+   certificate authorities.  Certificate Revocation List (CRL) entries
+   are also checked if the file root.crl exists.
+  
+
+  
+   If the root.crt file is not present, client
+   certificates will not be requested or checked.  In this mode, SSL
+   provides encrypted communication but not authentication.
   
 
   
-   For details on how to create your server private key and certificate,
-   refer to the OpenSSL documentation. A
-   self-signed certificate can be used for testing, but a
-   certificate signed by a certificate authority (CA)
-   (either one of the global
-   CAs or a local one) should be used in production so the
-   client can verify the server's identity. To create a quick
-   self-signed certificate, use the following
-   OpenSSL command:
+   The files server.key, server.crt,
+   root.crt, and root.crl
+   are only examined during server start; so you must restart 
+   the server for changes in them to take effect.
+  
+
+  
+   Creating a Self-Signed Certificate
+
+   
+    To create a quick self-signed certificate for the server, use the
+    following OpenSSL command:
 
 openssl req -new -text -out server.req
 
-   Fill out the information that openssl asks for. Make sure
-   you enter the local host name as Common Name; the challenge
-   password can be left blank. The program will generate a key that is
-   passphrase protected; it will not accept a passphrase that is less
-   than four characters long. To remove the passphrase (as you must if
-   you want automatic start-up of the server), run the commands:
+    Fill out the information that openssl asks for. Make sure
+    you enter the local host name as Common Name; the challenge
+    password can be left blank. The program will generate a key that is
+    passphrase protected; it will not accept a passphrase that is less
+    than four characters long. To remove the passphrase (as you must if
+    you want automatic start-up of the server), run the commands:
 
 openssl rsa -in privkey.pem -out server.key
 rm privkey.pem
 
-   Enter the old passphrase to unlock the existing key. Now do:
+    Enter the old passphrase to unlock the existing key. Now do:
 
 openssl req -x509 -in server.req -text -key server.key -out server.crt
 chmod og-rwx server.key
 
-   to turn the certificate into a self-signed certificate and to copy the
-   key and certificate to where the server will look for them.
-  
+    to turn the certificate into a self-signed certificate and to copy
+    the key and certificate to where the server will look for them.
+    For more details on how to create your server private key and
+    certificate, refer to the OpenSSL documentation.
+   
 
-  
-   If verification of client certificates is required, place the
-   certificates of the CA(s) you wish to check for in
-   the file root.crt in the data directory.  When
-   present, a client certificate will be requested from the client
-   during SSL connection startup, and it must have been signed by one of
-   the certificates present in root.crt.  (See 
-   linkend="libpq-ssl"> for a description of how to set up client
-   certificates.) Certificate Revocation List (CRL) entries are also
-   checked if the file root.crl exists.
-  
+   
+    A self-signed certificate can be used for testing, but a certificate
+    signed by a certificate authority (CA) (either one of the
+    global CAs or a local one) should be used in production
+    so the client can verify the server's identity.
+   
 
-  
-   When the root.crt file is not present, client
-   certificates will not be requested or checked.  In this mode, SSL
-   provides communication security but not authentication.
-  
+  
 
-  
-   The files server.key, server.crt,
-   root.crt, and root.crl
-   are only examined during server start; so you must restart 
-   the server to make changes in them take effect.
-