PostgreSQL has native support for using SSL connections to encrypt client/server communications for increased security. See Section 18.9 for details about the server-side SSL functionality.
libpq 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.
By default, PostgreSQL will not perform any verification of the server certificate. This means that it is possible to spoof the server identity (for example by modifying a DNS record or by taking over the server IP address) without the client knowing. In order to prevent spoofing, the client must be able to verify the server's identity via a chain of trust. A chain of trust is established by placing a root (self-signed) certificate authority (CA) certificate on one computer and a leaf certificate signed by the root certificate on another computer. It is also possible to use an “intermediate” certificate which is signed by the root certificate and signs leaf certificates.
To allow the client to verify the identity of the server, place a root certificate on the client and a leaf certificate signed by the root certificate on the server. To allow the server to verify the identity of the client, place a root certificate on the server and a leaf certificate signed by the root certificate on the client. One or more intermediate certificates (usually stored with the leaf certificate) can also be used to link the leaf certificate to the root certificate.
Once a chain of trust has been established, there are two ways
for the client to validate the leaf certificate sent by the server.
If the parameter sslmode
is set to
verify-ca
, libpq will verify that the
server is trustworthy by checking the certificate chain up to the
root certificate stored on the client. If sslmode
is set to verify-full
, libpq will also verify that the server host name
matches the name stored in the server certificate. The SSL
connection will fail if the server certificate cannot be verified.
verify-full
is recommended in most
security-sensitive environments.
In verify-full
mode, the host name
is matched against the certificate's Subject Alternative Name
attribute(s), or against the Common Name attribute if no Subject
Alternative Name of type dNSName
is
present. If the certificate's name attribute starts with an
asterisk (*
), the asterisk will be
treated as a wildcard, which will match all characters except a dot (.
). This means the certificate will not match
subdomains. If the connection is made using an IP address instead
of a host name, the IP address will be matched (without doing any
DNS lookups).
To allow server certificate verification, one or more root
certificates must be placed in the file ~/.postgresql/root.crt
in the user's home
directory. (On Microsoft Windows the file is named %APPDATA%\postgresql\root.crt
.) Intermediate
certificates should also be added to the file if they are needed to
link the certificate chain sent by the server to the root
certificates stored on the client.
Certificate Revocation List (CRL) entries are also checked if
the file ~/.postgresql/root.crl
exists (%APPDATA%\postgresql\root.crl
on Microsoft Windows).
The location of the root certificate file and the CRL can be
changed by setting the connection parameters sslrootcert
and sslcrl
or the environment variables PGSSLROOTCERT
and PGSSLCRL
.
For backwards compatibility with earlier versions of PostgreSQL,
if a root CA file exists, the behavior of sslmode
=require
will
be the same as that of verify-ca
,
meaning the server certificate is validated against the CA. Relying
on this behavior is discouraged, and applications that need
certificate validation should always use verify-ca
or verify-full
.
If the server attempts to verify the identity of the client by
requesting the client's leaf certificate, libpq will send the certificates stored in
file ~/.postgresql/postgresql.crt
in
the user's home directory. The certificates must chain to the root
certificate trusted by the server. A matching private key file
~/.postgresql/postgresql.key
must
also be present. The private key file must not allow any access to
world or group; achieve this by the command chmod 0600 ~/.postgresql/postgresql.key
. On
Microsoft Windows these files are named %APPDATA%\postgresql\postgresql.crt
and
%APPDATA%\postgresql\postgresql.key
,
and there is no special permissions check since the directory is
presumed secure. The location of the certificate and key files can
be overridden by the connection parameters sslcert
and sslkey
or
the environment variables PGSSLCERT
and
PGSSLKEY
.
The first certificate in postgresql.crt
must be the client's certificate
because it must match the client's private key. “Intermediate”
certificates can be optionally appended to the file — doing so
avoids requiring storage of intermediate certificates on the
server's root.crt
file.
For instructions on creating certificates, see Section 18.9.3.
The different values for the sslmode
parameter provide different levels of
protection. SSL can provide protection against three types of
attacks:
If a third party can examine the network traffic between the client and the server, it can read both connection information (including the user name and password) and the data that is passed. SSL uses encryption to prevent this.
If a third party can modify the data while passing between the client and server, it can pretend to be the server and therefore see and modify data even if it is encrypted. The third party can then forward the connection information and data to the original server, making it impossible to detect this attack. Common vectors to do this include DNS poisoning and address hijacking, whereby the client is directed to a different server than intended. There are also several other attack methods that can accomplish this. SSL uses certificate verification to prevent this, by authenticating the server to the client.
If a third party can pretend to be an authorized client, it can simply access data it should not have access to. Typically this can happen through insecure password management. SSL uses client certificates to prevent this, by making sure that only holders of valid certificates can access the server.
For a connection to be known secure, SSL usage must be
configured on both the client and the
server before the connection is made. If it is only
configured on the server, the client may end up sending sensitive
information (e.g. passwords) before it knows that the server
requires high security. In libpq, secure connections can be ensured
by setting the sslmode
parameter to
verify-full
or verify-ca
, and providing the system with a root
certificate to verify against. This is analogous to using an
https
URL for encrypted web browsing.
Once the server has been authenticated, the client can pass sensitive data. This means that up until this point, the client does not need to know if certificates will be used for authentication, making it safe to specify that only in the server configuration.
All SSL options carry
overhead in the form of encryption and key-exchange, so there is a
trade-off that has to be made between performance and security.
Table 33.1
illustrates the risks the different sslmode
values protect against, and what statement
they make about security and overhead.
Table 33.1. SSL Mode Descriptions
sslmode |
Eavesdropping protection | MITM protection | Statement |
---|---|---|---|
disable |
No | No | I don't care about security, and I don't want to pay the overhead of encryption. |
allow |
Maybe | No | I don't care about security, but I will pay the overhead of encryption if the server insists on it. |
prefer |
Maybe | No | I don't care about encryption, but I wish to pay the overhead of encryption if the server supports it. |
require |
Yes | No | I want my data to be encrypted, and I accept the overhead. I trust that the network will make sure I always connect to the server I want. |
verify-ca |
Yes | Depends on CA -policy |
I want my data encrypted, and I accept the overhead. I want to be sure that I connect to a server that I trust. |
verify-full |
Yes | Yes | I want my data encrypted, and I accept the overhead. I want to be sure that I connect to a server I trust, and that it's the one I specify. |
The difference between verify-ca
and verify-full
depends on the policy
of the root CA. If a public
CA is used, verify-ca
allows connections to a server that
somebody else may have
registered with the CA. In this
case, verify-full
should always be
used. If a local CA is used, or
even a self-signed certificate, using verify-ca
often provides enough protection.
The default value for sslmode
is
prefer
. As is shown in the table, this
makes no sense from a security point of view, and it only promises
performance overhead if possible. It is only provided as the
default for backward compatibility, and is not recommended in
secure deployments.
Table 33.2 summarizes the files that are relevant to the SSL setup on the client.
Table 33.2. Libpq/Client SSL File Usage
File | Contents | Effect |
---|---|---|
~/.postgresql/postgresql.crt |
client certificate | requested by server |
~/.postgresql/postgresql.key |
client private key | proves client certificate sent by owner; does not indicate certificate owner is trustworthy |
~/.postgresql/root.crt |
trusted certificate authorities | checks that server certificate is signed by a trusted certificate authority |
~/.postgresql/root.crl |
certificates revoked by certificate authorities | server certificate must not be on this list |
If your application initializes libssl
and/or libcrypto
libraries and libpq is built with SSL support, you should call PQinitOpenSSL
to tell libpq that the libssl
and/or libcrypto
libraries have been initialized by your
application, so that libpq will
not also initialize those libraries. See http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04.html
for details on the SSL API.
PQinitOpenSSL
Allows applications to select which security libraries to initialize.
void PQinitOpenSSL(int do_ssl, int do_crypto);
When do_ssl
is non-zero,
libpq will initialize the
OpenSSL library before first
opening a database connection. When do_crypto
is non-zero, the
libcrypto
library will be initialized.
By default (if PQinitOpenSSL
is not
called), both libraries are initialized. When SSL support is not
compiled in, this function is present but does nothing.
If your application uses and initializes either OpenSSL or its underlying libcrypto
library, you must call this function with zeroes for
the appropriate parameter(s) before first opening a database
connection. Also be sure that you have done that initialization
before opening a database connection.
PQinitSSL
Allows applications to select which security libraries to initialize.
void PQinitSSL(int do_ssl);
This function is equivalent to PQinitOpenSSL(do_ssl, do_ssl)
. It is sufficient
for applications that initialize both or neither of OpenSSL and libcrypto
.
PQinitSSL
has been present since
PostgreSQL 8.0, while PQinitOpenSSL
was added in PostgreSQL 8.4, so PQinitSSL
might be preferable for applications
that need to work with older versions of libpq.
If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.