Re: PATH: SSL flexibility and documentation

On Wed, 18 Feb 2004, Chris Smith wrote:

> [Sorry, resending -- I first sent this from the wrong email account, and I
> think it got swallowed somewhere because that address is not subscribed to the
> list.]
>
> The attached patch:
>
> - Adds a section to the main driver README file regarding SSL.

Documentation additions should ideally be to the docbook source in the doc
subdirectory. Also incorportating some of the openssl cert/keytool
details mentioned here would be good.

http://archives.postgresql.org/pgsql-jdbc/2003-08/msg00110.php

>
> - Adds and documents a Driver.setSSLSocketFactory, which can be
> used to change the SSLSocketFactory (per my earlier response
> when this came up.
>
> Please check my use of @SSL@ in Driver.java.in. I wasn't sure whether we
> consider it more important to ensure that Driver.java.in compiles against all
> JDK versions, or to ensure that it has a consistent exposed interface in all
> builds. I opted for the former, but the choice can be changed by removing
> @SSL@ around the method declaration for setSSLSocketFactory. (Both could be
> achieved at once with an ugly interface; if that's needed, I can resubmit that
> way.)

Compiling against all JDK versions is required. A consistent interface is
good as well. I was initially thinking about a
setSSLSocketFactory(Object) for the non-ssl case which would do nothing,
but allow code that tried to use this ssl option to compile and run
consistently. That's not entirely consistent and perhaps
setSSLSocketFactory should always take an Object parameter and
conditionally cast it if using SSL.

One thing I don't like about this patch (and the existing logging code) is
the use of static variables which make every Connection act the same way.
One way around this would be to make the API something like
setSSLSocketFactory(String factoryName, Object factory) and then have the
url parameter be ?ssl=<factoryName>. This still doesn't solve the problem
of trying to use something like this in a Datasource unless we seeded the
available ssl socket factories with typical usage scenarios or otherwise
allowed it to be customized by url parameters.

Finally I'd like to take a closer look at the other ssl options that are
available before I committed to an API that might not support them. I
know the server can optionally authenticate the client's cert and there
are some other undocumented ssl things.

Kris Jurka