Thread: PATH: SSL flexibility and documentation
[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.
- 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.)
--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Attachment
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
Kris Jurka wrote:
> Documentation additions should ideally be to the docbook source in
> the doc subdirectory.
Alright. I'll keep that in mind for the future.
As far as this patch, you've obviously thought about it and have the same
general idea as I do, so I'll let you take it from here. I have no vested
interest in this functionality, and I only wrote the patch on the chance that
no one else had gotten around to it and it seemed pretty trivial.
As to your specific comments:
> 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.
That's exactly what I had in mind when I said it would be possible but ugly to
achieve both. Something like:
@SSL@ private javax.net.ssl.SSLSocketFactory factory;
public static void setSSLSocketFactory(Object factoryObj)
{
@SSL@ this.factory = (javax.net.ssl.SSLSocketFactory) factoryObj;
}
So you could still call setSSLSocketFactory even for a driver without SSL
compiled under JDK 1.1; but it wouldn't do anything. Alternatively, perhaps
it should throw an exception. I hate the idea of silently failing at
anything.
> 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>.
Sounds somewhat reasonable, but it does complicate the interface for the
common case. If, instead, you had methods either to set the default factory
*or* use named factories, it wouldn't force anyone to figure out an
interaction between some String parameter and a piece of the connection URL.
I doubt most applications make connections to more than one backend anyway.
> This still doesn't
> solve the problem of trying to use something like this in a
> Datasource [...]
Didn't look into that, though I agree we should definitely worry about
DataSource support... especially with Sun floating around comments like "we
expect that DriverManager will be deprecated in a future JDBC release".
> 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.
Sure. There are options on SSLSocket as well that this doesn't provide access
to. I can't think of a clean way to provide those options, except as yet more
separate parameters on top of this. I can't imagine asking user code to hand
us back an SSLSocket instance.
--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation