Attached patch cleans up the certificate verification in libpq, and adds
a configuration paraqmeter to control it. The new parameter is
"sslverify", and can be set to:
* cn = default = will validate that the certificate chains to a trusted
root, *and* that the cn on the certificate matches the hostname
specificed in the connection. This is the only option that prevents
man-in-the-middle attacks completely, and therefor is the default.
* cert = what we had before if there was a root certificate file = will
validate that the certificate chains to a trusted root, but ignore the cn.
* none = will disable certificate validation completely
This means that the connection string is now in charge of the security
policy, and not just the "if file exists or not". IMHO this is the only
proper way to do it. Now, if you for some reason loose the root
certificate file, libpq will refuse to connect unless you have
explicitly told it to connect without verifying the certificate.
Previously if you accidentally lost the file, you would connect
insecurely without knowing about it.
The error messages from the patch requires the
libpq-error-message-stacking patch as well (or something like it),
otherwise the error message will often get overwritten by a later one if
we retry without SSL.
I intend to follow this up with a similar patch for the server side,
which will make it a connection option instead of being dependent on the
presence of a file. This is depending on the pg_hba options patch,
however, so it's not ready yet.
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2008-10-20 12:51:24|
|Subject: Re: pg_hba options parsing |
|Previous:||From: Tom Lane||Date: 2008-10-20 12:46:07|
|Subject: Re: SQL:2008 LIMIT/OFFSET |