Re: A solution to the SSL customizing problem

On Monday 11 October 2004 22:59, you wrote:
> Ulrich Meis wrote:
> > I propose a different solution. [...]
>
> This seems like a subset of the other solutions suggested. If you can
> configure the SSLSocketFactory used, you can use a class just like the
> one you provided without requiring that everyone uses it.

Viewpoint one: configurability.

I agree, someone could write that same class.
There is just one thing that will take a few more lines of code: retrieving
the certificate from the server.
In an application you don't get your hands on the actual socket that the
driver uses. The only way I see to get the server's certificate is to
implement your own TrustManager.

Surely, providing your own SSLSocketFactory is more configurable.
Why not offer providing a SSLSocketFactory, too?

Viewpoint two: usability.

I think all most people want is to have an SSL connection running and don't
care too much about the details.
The proposed features allow them to handle the problem that everyone runs into
when using SSL: how to get the server's certificate into your trustStore?

This is a big problem for applet programmers because applets should just
load&work, you can't tell people about keytool.
With this implementation you can either ship the certificate with the applet
or you can use trustandsave on new servers.

> I'd rather see a flexible solution that can be customized to the needs
> of a particular application. For example, the code that you provided
> assumes that there is one global truststore and that it is a Java-format
> keystore that is accessible locally. Neither of those are necessarily true.

For these cases it would be nice if you could provide your own KeyStore
object...the question is just how.

************
Ok...here comes another solution.
You let the user provide a handler and introduce an id in the URL in case the
user needs per connection handling.

In the Driver class you offer a method(make it empty if compiled without SSL):

setPGSSLHandler(PGSSLHandler handler) {
pgsslhandler=handler;}

and a URL parameter conid=123

and

abstract class PGSSLHandler {

public static final int STANDARD=0;
public static final int CUSTOMFACTORY=1;
public static final int CUSTOMSTORE=2;

abstract public int getHandleType(int conid);
abstract public boolean getTrustAndSave(int conid);

abstract public KeyStore getKeyStore(int conid);
abstract public SSLSocketFactory getSSLSocketFactory(int conid);

}

This is really flexible, you don't need to do any classloading and you don't
need to manage multiple user objects in the driver.

How's that?

Uli