<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <HTML ><HEAD ><TITLE >SSL Support</TITLE ><META NAME="GENERATOR" CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK REV="MADE" HREF="mailto:pgsql-docs@postgresql.org"><LINK REL="HOME" TITLE="PostgreSQL 8.4.8 Documentation" HREF="index.html"><LINK REL="UP" TITLE="libpq - C Library" HREF="libpq.html"><LINK REL="PREVIOUS" TITLE="LDAP Lookup of Connection Parameters" HREF="libpq-ldap.html"><LINK REL="NEXT" TITLE="Behavior in Threaded Programs" HREF="libpq-threading.html"><LINK REL="STYLESHEET" TYPE="text/css" HREF="stylesheet.css"><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1"><META NAME="creation" CONTENT="2011-04-15T03:27:09"></HEAD ><BODY CLASS="SECT1" ><DIV CLASS="NAVHEADER" ><TABLE SUMMARY="Header navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TH COLSPAN="5" ALIGN="center" VALIGN="bottom" >PostgreSQL 8.4.8 Documentation</TH ></TR ><TR ><TD WIDTH="10%" ALIGN="left" VALIGN="top" ><A HREF="libpq-ldap.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="10%" ALIGN="left" VALIGN="top" ><A HREF="libpq.html" >Fast Backward</A ></TD ><TD WIDTH="60%" ALIGN="center" VALIGN="bottom" >Chapter 30. <SPAN CLASS="APPLICATION" >libpq</SPAN > - C Library</TD ><TD WIDTH="10%" ALIGN="right" VALIGN="top" ><A HREF="libpq.html" >Fast Forward</A ></TD ><TD WIDTH="10%" ALIGN="right" VALIGN="top" ><A HREF="libpq-threading.html" ACCESSKEY="N" >Next</A ></TD ></TR ></TABLE ><HR ALIGN="LEFT" WIDTH="100%"></DIV ><DIV CLASS="SECT1" ><H1 CLASS="SECT1" ><A NAME="LIBPQ-SSL" >30.17. SSL Support</A ></H1 ><A NAME="AEN35915" ></A ><P > <SPAN CLASS="PRODUCTNAME" >PostgreSQL</SPAN > has native support for using <ACRONYM CLASS="ACRONYM" >SSL</ACRONYM > connections to encrypt client/server communications for increased security. See <A HREF="ssl-tcp.html" >Section 17.8</A > for details about the server-side <ACRONYM CLASS="ACRONYM" >SSL</ACRONYM > functionality. </P ><P > <SPAN CLASS="APPLICATION" >libpq</SPAN > reads the system-wide <SPAN CLASS="PRODUCTNAME" >OpenSSL</SPAN > configuration file. By default, this file is named <TT CLASS="FILENAME" >openssl.cnf</TT > and is located in the directory reported by <TT CLASS="LITERAL" >openssl version -d</TT >. This default can be overridden by setting environment variable <TT CLASS="ENVAR" >OPENSSL_CONF</TT > to the name of the desired configuration file. </P ><DIV CLASS="SECT2" ><H2 CLASS="SECT2" ><A NAME="LIBQ-SSL-CERTIFICATES" >30.17.1. Certificate verification</A ></H2 ><P > By default, <SPAN CLASS="PRODUCTNAME" >PostgreSQL</SPAN > 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 this, <ACRONYM CLASS="ACRONYM" >SSL</ACRONYM > certificate verification must be used. </P ><P > If the parameter <TT CLASS="LITERAL" >sslmode</TT > is set to <TT CLASS="LITERAL" >verify-ca</TT > libpq will verify that the server is trustworthy by checking the certificate chain up to a trusted <ACRONYM CLASS="ACRONYM" >CA</ACRONYM >. If <TT CLASS="LITERAL" >sslmode</TT > is set to <TT CLASS="LITERAL" >verify-full</TT >, libpq will <SPAN CLASS="emphasis" ><I CLASS="EMPHASIS" >also</I ></SPAN > verify that the server hostname matches that of the certificate. The SSL connection will fail if the server certificate cannot be verified. <TT CLASS="LITERAL" >verify-full</TT > is recommended in most security sensitive environments. </P ><P > In <TT CLASS="LITERAL" >verify-full</TT > mode, the <TT CLASS="LITERAL" >cn</TT > attribute of the certificate is matched against the hostname. If the <TT CLASS="LITERAL" >cn</TT > attribute starts with an asterisk (<TT CLASS="LITERAL" >*</TT >), it will be treated as a wildcard, and will match all characters <SPAN CLASS="emphasis" ><I CLASS="EMPHASIS" >except</I ></SPAN > a dot (<TT CLASS="LITERAL" >.</TT >). This means the certificate will not match subdomains. If the connection is made using an IP address instead of a hostname, the IP address will be matched (without doing any DNS lookups). </P ><P > To allow verification, the certificate of a trusted <ACRONYM CLASS="ACRONYM" >CA</ACRONYM > must be placed in the file <TT CLASS="FILENAME" >~/.postgresql/root.crt</TT > in the user's home directory. (On Microsoft Windows the file is named <TT CLASS="FILENAME" >%APPDATA%\postgresql\root.crt</TT >.) </P ><P > Certificate Revocation List (CRL) entries are also checked if the file <TT CLASS="FILENAME" >~/.postgresql/root.crl</TT > exists (<TT CLASS="FILENAME" >%APPDATA%\postgresql\root.crl</TT > on Microsoft Windows). </P ><P > The location of the root certificate store and the CRL can be overridden by the connection parameters <TT CLASS="LITERAL" >sslrootcert</TT > and <TT CLASS="LITERAL" >sslcrl</TT > or the environment variables <TT CLASS="ENVAR" >PGSSLROOTCERT</TT > and <TT CLASS="ENVAR" >PGSSLCRL</TT >. </P ></DIV ><DIV CLASS="SECT2" ><H2 CLASS="SECT2" ><A NAME="LIBPQ-SSL-CLIENTCERT" >30.17.2. Client certificates</A ></H2 ><P > If the server requests a trusted client certificate, <SPAN CLASS="APPLICATION" >libpq</SPAN > will send the certificate stored in file <TT CLASS="FILENAME" >~/.postgresql/postgresql.crt</TT > in the user's home directory. The certificate must be signed by one of the certificate authorities (<ACRONYM CLASS="ACRONYM" >CA</ACRONYM >) trusted by the server. A matching private key file <TT CLASS="FILENAME" >~/.postgresql/postgresql.key</TT > must also be present. The private key file must not allow any access to world or group; achieve this by the command <TT CLASS="COMMAND" >chmod 0600 ~/.postgresql/postgresql.key</TT >. On Microsoft Windows these files are named <TT CLASS="FILENAME" >%APPDATA%\postgresql\postgresql.crt</TT > and <TT CLASS="FILENAME" >%APPDATA%\postgresql\postgresql.key</TT >, 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 <TT CLASS="LITERAL" >sslcert</TT > and <TT CLASS="LITERAL" >sslkey</TT > or the environment variables <TT CLASS="ENVAR" >PGSSLCERT</TT > and <TT CLASS="ENVAR" >PGSSLKEY</TT >. </P ></DIV ><DIV CLASS="SECT2" ><H2 CLASS="SECT2" ><A NAME="LIBPQ-SSL-PROTECTION" >30.17.3. Protection provided in different modes</A ></H2 ><P > The different values for the <TT CLASS="LITERAL" >sslmode</TT > parameter provide different levels of protection, in different environments. SSL itself provides protection against three different types of attacks: </P ><DIV CLASS="TABLE" ><A NAME="LIBPQ-SSL-PROTECT-ATTACKS" ></A ><P ><B >Table 30-2. SSL attacks</B ></P ><TABLE BORDER="1" CLASS="CALSTABLE" ><COL><COL><THEAD ><TR ><TH >Type</TH ><TH >Description</TH ></TR ></THEAD ><TBODY ><TR ><TD >Eavesdropping</TD ><TD >If a third party can listen to the network traffic between the client and the server, it can read both connection information (including the username and password) and the data that is passed. <ACRONYM CLASS="ACRONYM" >SSL</ACRONYM > uses encryption to prevent this. </TD ></TR ><TR ><TD >Man in the middle (<ACRONYM CLASS="ACRONYM" >MITM</ACRONYM >)</TD ><TD >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 <SPAN CLASS="emphasis" ><I CLASS="EMPHASIS" >even if it is encrypted</I ></SPAN >. 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. <ACRONYM CLASS="ACRONYM" >SSL</ACRONYM > uses certificate verification to prevent this, by authenticating the server to the client. </TD ></TR ><TR ><TD >Impersonation</TD ><TD >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. <ACRONYM CLASS="ACRONYM" >SSL</ACRONYM > uses client certificates to prevent this, by making sure that only holders of valid certificates can access the server. </TD ></TR ></TBODY ></TABLE ></DIV ><P > For a connection to be known secure, the two first of these have to be set up on <SPAN CLASS="emphasis" ><I CLASS="EMPHASIS" >both the client and the server</I ></SPAN > 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, this is controlled by setting the <TT CLASS="LITERAL" >sslmode</TT > parameter to <TT CLASS="LITERAL" >verify-full</TT > or <TT CLASS="LITERAL" >verify-ca</TT >, and providing the system with a root certificate to verify against. This is analogous to using a <TT CLASS="LITERAL" >https</TT > <ACRONYM CLASS="ACRONYM" >URL</ACRONYM > for encrypted web browsing. </P ><P > 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 this only in the server configuration. </P ><P > All <ACRONYM CLASS="ACRONYM" >SSL</ACRONYM > options carry overhead in the form of encryption and key-exchange, and it is a tradeoff that has to be made between performance and security. The following table illustrates the risks the different <TT CLASS="LITERAL" >sslmode</TT > values protect against, and what statement they make about security and overhead: </P ><DIV CLASS="TABLE" ><A NAME="LIBPQ-SSL-SSLMODE-STATEMENTS" ></A ><P ><B >Table 30-3. SSL mode descriptions</B ></P ><TABLE BORDER="1" CLASS="CALSTABLE" ><COL><COL><COL><COL><THEAD ><TR ><TH ><TT CLASS="LITERAL" >sslmode</TT ></TH ><TH >Eavesdropping protection</TH ><TH ><ACRONYM CLASS="ACRONYM" >MITM</ACRONYM > protection</TH ><TH >Statement</TH ></TR ></THEAD ><TBODY ><TR ><TD ><TT CLASS="LITERAL" >disabled</TT ></TD ><TD >No</TD ><TD >No</TD ><TD >I don't care about security, and I don't want to pay the overhead of encryption. </TD ></TR ><TR ><TD ><TT CLASS="LITERAL" >allow</TT ></TD ><TD >Maybe</TD ><TD >No</TD ><TD >I don't care about security, but I will pay the overhead of encryption if the server insists on it. </TD ></TR ><TR ><TD ><TT CLASS="LITERAL" >prefer</TT ></TD ><TD >Maybe</TD ><TD >No</TD ><TD >I don't care about encryption, but I wish to pay the overhead of encryption if the server supports it. </TD ></TR ><TR ><TD ><TT CLASS="LITERAL" >require</TT ></TD ><TD >Yes</TD ><TD >No</TD ><TD >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. </TD ></TR ><TR ><TD ><TT CLASS="LITERAL" >verify-ca</TT ></TD ><TD >Yes</TD ><TD ><TT CLASS="LITERAL" >Depends on CA</TT >-policy</TD ><TD >I want my data encrypted, and I accept the overhead. I want to be sure that I connect to a server that I trust. </TD ></TR ><TR ><TD ><TT CLASS="LITERAL" >verify-full</TT ></TD ><TD >Yes</TD ><TD >Yes</TD ><TD >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. </TD ></TR ></TBODY ></TABLE ></DIV ><P > The difference between <TT CLASS="LITERAL" >verify-ca</TT > and <TT CLASS="LITERAL" >verify-full</TT > depends on the policy of the root <ACRONYM CLASS="ACRONYM" >CA</ACRONYM >. If a public <ACRONYM CLASS="ACRONYM" >CA</ACRONYM > is used, <TT CLASS="LITERAL" >verify-ca</TT > allows connections to a server that <SPAN CLASS="emphasis" ><I CLASS="EMPHASIS" >somebody else</I ></SPAN > may have registered with the <ACRONYM CLASS="ACRONYM" >CA</ACRONYM > to succeed. In this case, <TT CLASS="LITERAL" >verify-full</TT > should always be used. If a local <ACRONYM CLASS="ACRONYM" >CA</ACRONYM > is used, or even a self-signed certificate, using <TT CLASS="LITERAL" >verify-ca</TT > often provides enough protection. </P ><P > The default value for <TT CLASS="LITERAL" >sslmode</TT > is <TT CLASS="LITERAL" >prefer</TT >. 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 backwards compatibility, and not recommended in secure deployments. </P ></DIV ><DIV CLASS="SECT2" ><H2 CLASS="SECT2" ><A NAME="LIBPQ-SSL-FILEUSAGE" >30.17.4. SSL File Usage</A ></H2 ><DIV CLASS="TABLE" ><A NAME="LIBPQ-SSL-FILE-USAGE" ></A ><P ><B >Table 30-4. Libpq/Client SSL File Usage</B ></P ><TABLE BORDER="1" CLASS="CALSTABLE" ><COL><COL><COL><THEAD ><TR ><TH >File</TH ><TH >Contents</TH ><TH >Effect</TH ></TR ></THEAD ><TBODY ><TR ><TD ><TT CLASS="FILENAME" >~/.postgresql/postgresql.crt</TT ></TD ><TD >client certificate</TD ><TD >requested by server</TD ></TR ><TR ><TD ><TT CLASS="FILENAME" >~/.postgresql/postgresql.key</TT ></TD ><TD >client private key</TD ><TD >proves client certificate sent by owner; does not indicate certificate owner is trustworthy</TD ></TR ><TR ><TD ><TT CLASS="FILENAME" >~/.postgresql/root.crt</TT ></TD ><TD >trusted certificate authorities</TD ><TD >checks server certificate is signed by a trusted certificate authority</TD ></TR ><TR ><TD ><TT CLASS="FILENAME" >~/.postgresql/root.crl</TT ></TD ><TD >certificates revoked by certificate authorities</TD ><TD >server certificate must not be on this list</TD ></TR ></TBODY ></TABLE ></DIV ></DIV ><DIV CLASS="SECT2" ><H2 CLASS="SECT2" ><A NAME="LIBPQ-SSL-INITIALIZE" >30.17.5. SSL library initialization</A ></H2 ><P > If your application initializes <TT CLASS="LITERAL" >libssl</TT > and/or <TT CLASS="LITERAL" >libcrypto</TT > libraries and <SPAN CLASS="APPLICATION" >libpq</SPAN > is built with <ACRONYM CLASS="ACRONYM" >SSL</ACRONYM > support, you should call <CODE CLASS="FUNCTION" >PQinitOpenSSL</CODE > to tell <SPAN CLASS="APPLICATION" >libpq</SPAN > that the <TT CLASS="LITERAL" >libssl</TT > and/or <TT CLASS="LITERAL" >libcrypto</TT > libraries have been initialized by your application, so that <SPAN CLASS="APPLICATION" >libpq</SPAN > will not also initialize those libraries. See <A HREF="http://h71000.www7.hp.com/doc/83final/BA554_90007/ch04.html" TARGET="_top" >http://h71000.www7.hp.com/doc/83final/BA554_90007/ch04.html</A > for details on the SSL API. </P ><P > <P ></P ></P><DIV CLASS="VARIABLELIST" ><DL ><DT ><A NAME="LIBPQ-PQINITOPENSSL" ></A ><CODE CLASS="FUNCTION" >PQinitOpenSSL</CODE > <A NAME="AEN36123" ></A ></DT ><DD ><P > Allows applications to select which security libraries to initialize. </P><PRE CLASS="SYNOPSIS" > void PQinitOpenSSL(int do_ssl, int do_crypto); </PRE ><P> </P ><P > When <TT CLASS="PARAMETER" >do_ssl</TT > is non-zero, <SPAN CLASS="APPLICATION" >libpq</SPAN > will initialize the <SPAN CLASS="APPLICATION" >OpenSSL</SPAN > library before first opening a database connection. When <TT CLASS="PARAMETER" >do_crypto</TT > is non-zero, the <TT CLASS="LITERAL" >libcrypto</TT > library will be initialized. By default (if <CODE CLASS="FUNCTION" >PQinitOpenSSL</CODE > is not called), both libraries are initialized. When SSL support is not compiled in, this function is present but does nothing. </P ><P > If your application uses and initializes either <SPAN CLASS="APPLICATION" >OpenSSL</SPAN > or its underlying <TT CLASS="LITERAL" >libcrypto</TT > library, you <SPAN CLASS="emphasis" ><I CLASS="EMPHASIS" >must</I ></SPAN > 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. </P ></DD ><DT ><A NAME="LIBPQ-PQINITSSL" ></A ><CODE CLASS="FUNCTION" >PQinitSSL</CODE > <A NAME="AEN36142" ></A ></DT ><DD ><P > Allows applications to select which security libraries to initialize. </P><PRE CLASS="SYNOPSIS" > void PQinitSSL(int do_ssl); </PRE ><P> </P ><P > This function is equivalent to <TT CLASS="LITERAL" >PQinitOpenSSL(do_ssl, do_ssl)</TT >. It is sufficient for applications that initialize both or neither of <SPAN CLASS="APPLICATION" >OpenSSL</SPAN > and <TT CLASS="LITERAL" >libcrypto</TT >. </P ><P > <CODE CLASS="FUNCTION" >PQinitSSL</CODE > has been present since <SPAN CLASS="PRODUCTNAME" >PostgreSQL</SPAN > 8.0, while <CODE CLASS="FUNCTION" >PQinitOpenSSL</CODE > was added in <SPAN CLASS="PRODUCTNAME" >PostgreSQL</SPAN > 8.4, so <CODE CLASS="FUNCTION" >PQinitSSL</CODE > might be preferable for applications that need to work with older versions of <SPAN CLASS="APPLICATION" >libpq</SPAN >. </P ></DD ></DL ></DIV ><P> </P ></DIV ></DIV ><DIV CLASS="NAVFOOTER" ><HR ALIGN="LEFT" WIDTH="100%"><TABLE SUMMARY="Footer navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" ><A HREF="libpq-ldap.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="index.html" ACCESSKEY="H" >Home</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" ><A HREF="libpq-threading.html" ACCESSKEY="N" >Next</A ></TD ></TR ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" >LDAP Lookup of Connection Parameters</TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="libpq.html" ACCESSKEY="U" >Up</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" >Behavior in Threaded Programs</TD ></TR ></TABLE ></DIV ></BODY ></HTML >