Re: SSL patch

Hello,


I'm attaching a tentative patch merging the concepts discussed in this
thread (and based on András Bodor's patch) and on the discussion in this
older thread:
http://archives.postgresql.org/pgsql-jdbc/2011-05/msg00069.php


I've tried to resolve the differences between the two approaches: Libpq
and Java JSSE defaults. I guess there are two categories of potential
users for this: users coming from psql and those coming from the Java
world. They'd probably tend to expect different default settings and
options.


This relies on an SslContextFactory and extending classes.

In this patch, SslContextFactory itself isn't actually used (it could be
with a given option). It would use the default SSLContext (which may be
set via SSLContext.setDefault(...) in Java 6 and above, and thus may not
necessarily be the one initialised via the usual javax.* properties).


There's a BasicSslContextFactory (extending SslContextFactory) which
provide methods to create trust managers, key managers and secure
randoms. These are meant to be overridden, otherwise, it will use the
default (null) to initialise the SSLContext (which is the same as using
the JSSE defaults).
It includes convenience methods to build key and trust managers from
KeyStores.


LibPQSslContextFactory extends BasicSslContextFactory and re-uses most
of András's code, initialised from a set of Properties.
This is the one used when 'sslmode' is set. Note that this is where
there would be a conflict regarding the default values (if not testing
for 'sslmode'), since the default CA file is different from what Java
would use as its default.


PropertiesSslContextFactory extends BasicSslContextFactory but is based
on the work by Marc-André Laverdière and Craig Ringer from the previous
thread.
I've also tweaked it to fall back on the default values from the JSSE,
also allowing for non-file-based keystores (e.g. PKCS#11), as discussed
here:
http://archives.postgresql.org/pgsql-jdbc/2011-11/msg00024.php

This one could certainly be modified to use Properties that are not the
System properties, but info passed in the JDBC URL.



Regarding the hostname verification, I've moved András's verifier into a
separate class (DefaultHostnameVerifier). It's used by default unless a
hostname verifier class name is passed or sslmode is set and set to a
value different from 'verify-full' (in which case
PassthroughHostnameVerifier is used). I've also added the SAN verification.


In addition to the 'sslfactory' parameter (which was there, for an
SSLSocketFactory), I've considered adding a parameter for an
SslContextFactory, but haven't. Any opinions? It might make it easier to
pass more complex SSLContexts directly (e.g. via the of the
SSLContextFactories I've done in http://www.jsslutils.org/), but this
could also be done by using a custom SSLSocketFactory.


I must admit it hasn't been extensively tested, but I'd welcome comments
about this approach. I hope this may help unify this work with the
earlier work (sorry, I wasn't aware of it when I first replied to this
thread a few days ago).


Best wishes,

Bruno.