| PostgreSQL 9.4.1 Documentation | |||
|---|---|---|---|
| Prev | Up | Chapter 31.libpq - C Library | Next |
31.18. SSL Support
PostgreSQL has native support for usingSSL connections to encrypt client/server communications for increased security. SeeSection 17.9 for details about the server-sideSSL functionality. libpq reads the system-wideOpenSSL configuration file. By default, this file is namedopenssl.cnf and is located in the directory reported byopenssl version -d. This default can be overridden by setting environment variableOPENSSL_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,SSL certificate verification must be used. If the parametersslmode is set toverify-ca, libpq will verify that the server is trustworthy by checking the certificate chain up to a trusted certificate authority (CA). Ifsslmode is set toverify-full, libpq willalso verify that the server host name matches its certificate. The SSL connection will fail if the server certificate cannot be verified.verify-full is recommended in most security-sensitive environments. Inverify-full mode, thecn (Common Name) attribute of the certificate is matched against the host name. If thecn attribute starts with an asterisk (*), it will be treated as a wildcard, and will match all charactersexcept 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, the certificate(s) of one or more trustedCAs must be placed in the file~/.postgresql/root.crt in the user's home directory. If intermediateCAs appear inroot.crt, the file must also contain certificate chains to their rootCAs. (On Microsoft Windows the file is named%APPDATA%\postgresql\root.crt.) 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 parameterssslrootcert andsslcrl or the environment variablesPGSSLROOTCERT andPGSSLCRL. Note: For backwards compatibility with earlier versions of PostgreSQL, if a root CA file exists, the behavior ofsslmode=require will be the same as that ofverify-ca, meaning the server certificate is validated against the CA. Relying on this behavior is discouraged, and applications that need certificate validation should always useverify-ca orverify-full. If the server requests a trusted client certificate,libpq will send the certificate stored in 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. The private key file must not allow any access to world or group; achieve this by the commandchmod 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 parameterssslcert andsslkey or the environment variablesPGSSLCERT andPGSSLKEY. In some cases, the client certificate might be signed by an"intermediate" certificate authority, rather than one that is directly trusted by the server. To use such a certificate, append the certificate of the signing authority to thepostgresql.crt file, then its parent authority's certificate, and so on up to a certificate authority,"root" or"intermediate", that is trusted by the server, i.e. signed by a certificate in the server'sroot.crt file. Note that the client's~/.postgresql/root.crt lists the top-level CAs that are considered trusted for signing server certificates. In principle it need not list the CA that signed the client's certificate, though in most cases that CA would also be trusted for server certificates. The different values for thesslmode 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 dataeven 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 onboth 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 thesslmode parameter toverify-full orverify-ca, and providing the system with a root certificate to verify against. This is analogous to using anhttpsURL 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. AllSSL options carry overhead in the form of encryption and key-exchange, so there is a tradeoff that has to be made between performance and security.Table 31-1 illustrates the risks the differentsslmode values protect against, and what statement they make about security and overhead. Table 31-1. SSL Mode Descriptions The difference betweenverify-ca andverify-full depends on the policy of the rootCA. If a publicCA is used,verify-ca allows connections to a server thatsomebody else may have registered with theCA. In this case,verify-full should always be used. If a localCA is used, or even a self-signed certificate, usingverify-ca often provides enough protection. The default value forsslmode isprefer. 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 31-2 summarizes the files that are relevant to the SSL setup on the client. Table 31-2. Libpq/Client SSL File Usage If your application initializeslibssl and/orlibcrypto libraries andlibpq is built withSSL support, you should call Allows applications to select which security libraries to initialize. Whendo_ssl is non-zero,libpq will initialize theOpenSSL library before first opening a database connection. Whendo_crypto is non-zero, thelibcrypto library will be initialized. By default (if If your application uses and initializes eitherOpenSSL or its underlyinglibcrypto library, youmust 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. Allows applications to select which security libraries to initialize. This function is equivalent toPQinitOpenSSL(do_ssl, do_ssl). It is sufficient for applications that initialize both or neither ofOpenSSL andlibcrypto.31.18.1. Client Verification of Server Certificates
31.18.2. Client Certificates
31.18.3. Protection Provided in Different Modes
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. 31.18.4. SSL Client 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 31.18.5. SSL Library Initialization
PQinitOpenSSL to telllibpq that thelibssl and/orlibcrypto libraries have been initialized by your application, so thatlibpq will not also initialize those libraries. Seehttp://h71000.www7.hp.com/doc/83final/BA554_90007/ch04.html for details on the SSL API.PQinitOpenSSLvoid PQinitOpenSSL(int do_ssl, int do_crypto);
PQinitOpenSSL is not called), both libraries are initialized. When SSL support is not compiled in, this function is present but does nothing.PQinitSSLvoid PQinitSSL(int do_ssl);
PQinitSSL has been present sincePostgreSQL 8.0, whilePQinitOpenSSL was added inPostgreSQL 8.4, soPQinitSSL might be preferable for applications that need to work with older versions oflibpq.