Thread: Customizing SSL with jdbc

Hi
   I am using the jdbc driver for postgresql 7.4.5. I would like it to
use a custom SSLSocketFactory. It seems like the Driver uses the
javax.net.ssl.SSLSocketFactory.getDefault() method to create a socket
factory. Other than compiling the Driver with a different class, is
there any other way of doing this? For eg would it be worthwhile to
provide a method in the org.postgresql.Driver class that lets one set
the class that would then be aksed in the makeSSL method to create the
SSLSocketFactory instance.?
Chinmoy

On Tue, 7 Sep 2004, chinmoy wrote:

> Hi
>    I am using the jdbc driver for postgresql 7.4.5. I would like it to
> use a custom SSLSocketFactory. It seems like the Driver uses the
> javax.net.ssl.SSLSocketFactory.getDefault() method to create a socket
> factory. Other than compiling the Driver with a different class, is
> there any other way of doing this? For eg would it be worthwhile to
> provide a method in the org.postgresql.Driver class that lets one set
> the class that would then be aksed in the makeSSL method to create the
> SSLSocketFactory instance.?
> Chinmoy
>

There was some discussion of this, notably to provide a ssl connection
without adding the servers certificate to the jvm's trust store (which can
be a pain).  Recently Oliver had proposed adjusting our ssl url parameter
to add some more options like request vs. require to use ssl if available.
I had considered adding a noauth or similar option to try and meet these
requirements.  What's special about your SSLSocketFactory?  Is it
something others would be interested in as a generally useful thing or
something very specific?

The problem with adding a call to org.postgresql.Driver is that it must
use a static variable that affects all connections.  It would be better to
use a url parameter somehow.  See the discussions here:

http://archives.postgresql.org/pgsql-jdbc/2004-02/msg00184.php

http://archives.postgresql.org/pgsql-jdbc/2004-02/msg00199.php

Kris Jurka

On Mon, 2004-09-13 at 07:47, chinmoy wrote:
> Hi
>     Thanks for the reply. The only thing special about the factory is
> that it has access to the server certificate that is bundled with the
> client jars and is not installed in the jvm's trust store. I agree the
> static method is not the way to go as it affects all the connections. In
> my specific case it is okay as I know all the clients using the
> connections in  agiven client jvm.

What about an additional URL parameter like
sslfactoryfactory=com.mycompany.myfactory, where the provided class must
implement something like:

package org.postgresql;

interface SSLSocketFactoryFactory {
    public SSLSocketFactory getFactory();
}

Seems like this could work.  Thoughts?  Any other SSL options and things
people would want to tweak?

Kris Jurka

Kris
    Thanks again. This would certainly work for my scenario. A similar option for client authentication might also be useful.
Chinmoy.

Kris Jurka wrote:

On Mon, 2004-09-13 at 07:47, chinmoy wrote: 

Hi   Thanks for the reply. The only thing special about the factory is 
that it has access to the server certificate that is bundled with the 
client jars and is not installed in the jvm's trust store. I agree the 
static method is not the way to go as it affects all the connections. In 
my specific case it is okay as I know all the clients using the 
connections in  agiven client jvm.   

What about an additional URL parameter like
sslfactoryfactory=com.mycompany.myfactory, where the provided class must
implement something like:

package org.postgresql;

interface SSLSocketFactoryFactory {public SSLSocketFactory getFactory();
}

Seems like this could work.  Thoughts?  Any other SSL options and things
people would want to tweak?

Kris Jurka
 

On Tue, 14 Sep 2004, chinmoy gangolli wrote:

> Kris
>     Thanks again. This would certainly work for my scenario. A similar
> option for client authentication might also be useful.

Are you talking about SSL client authentication?  I don't know much about
ssl to begin with and pg's ability to verify a client is completely
undocumented.  Could you explain a little more about what you'd like to
see it do here?

Kris Jurka

Kris Jurka wrote:
> On Mon, 2004-09-13 at 07:47, chinmoy wrote:
>
>>Hi
>>    Thanks for the reply. The only thing special about the factory is
>>that it has access to the server certificate that is bundled with the
>>client jars and is not installed in the jvm's trust store. I agree the
>>static method is not the way to go as it affects all the connections. In
>>my specific case it is okay as I know all the clients using the
>>connections in  agiven client jvm.
>
>
> What about an additional URL parameter like
> sslfactoryfactory=com.mycompany.myfactory, where the provided class must
> implement something like:
>
> package org.postgresql;
>
> interface SSLSocketFactoryFactory {
>     public SSLSocketFactory getFactory();
> }
>
> Seems like this could work.  Thoughts?  Any other SSL options and things
> people would want to tweak?

I'm not sure how that extra level of indirection gives you anything.
Haven't you just gone from "how do I configure my new SSLSocketFactory
instance without context?" to "how do I configure my new
SSLSocketFactoryFactory instance without context?" ?

If we want per-connection SSL configurability (not just per-JVM) then it
seems like we have to pass an actual instance to the driver at runtime.
URL parameters aren't going to do the job unless we also pass
factory-specific configuration info in the URL somehow, and that assumes
that you can actually represent that info in the URL (e.g. you have more
than just an object reference to your keystore..)

I also dislike having the driver do any classloading of client classes
itself. It causes havoc in a managed environment where the JDBC driver
may be loaded in its own classloader that does not have access to the
application classes. I added the new variant of PGConnection.addDataType
to solve exactly this problem; let's not reintroduce it elsewhere.

-O

On Thu, 16 Sep 2004, Oliver Jowett wrote:

> I'm not sure how that extra level of indirection gives you anything.
> Haven't you just gone from "how do I configure my new SSLSocketFactory
> instance without context?" to "how do I configure my new
> SSLSocketFactoryFactory instance without context?" ?

The class itself is the context. That is, if you need to say have a number
of keystore locations each one gets its own wrapper factory class.  Its
definitely ugly, but so is programmatically setting things on the
org.postgresql.Driver class.  That approach also requires you getting in
there to touch the Driver class before a connection is established, which
is unclear to me how to accomplish in an application server environment
where a pool is setup for you.

Kris Jurka

Kris Jurka wrote:
>
> On Thu, 16 Sep 2004, Oliver Jowett wrote:
>
>
>>I'm not sure how that extra level of indirection gives you anything.
>>Haven't you just gone from "how do I configure my new SSLSocketFactory
>>instance without context?" to "how do I configure my new
>>SSLSocketFactoryFactory instance without context?" ?
>
>
> The class itself is the context. That is, if you need to say have a number
> of keystore locations each one gets its own wrapper factory class.

I still don't see why this requires an extra interface; you can do this
using only SSLSocketFactory itself.

> Its
> definitely ugly,

Hideously ugly, in fact..

> but so is programmatically setting things on the
> org.postgresql.Driver class.  That approach also requires you getting in
> there to touch the Driver class before a connection is established, which
> is unclear to me how to accomplish in an application server environment
> where a pool is setup for you.

You'd do it on the DataSource as part of configuring the appserver's
pool. I wonder how we can do this generically though -- I will need to
dig through the javabean spec for details of what sort of accessors you
can use for setting something like a SSLSocketFactory subclass. Ideally
the appserver should let the administrator instantiate a
(javabean-accessor-implementing) SSLSocketFactory subclass by class name
(& presumably classpath), configure it, then set it onto the
DataSource.. and the whole lot gets serialized into JNDI, etc.

(note that in this scenario the appserver doesn't need to know anything
postgresql-driver-specific)

-O