Re: A solution to the SSL customizing problem

On Mon, 11 Oct 2004, Ulrich Meis wrote:

> 1. Disabling validation.
>
> Not interesting for a user with security concerns - you loose half of SSL's
> functionality.

There is certainly a demand for this. While you do lose security it
is the default behavior for other pg clients (notably libpq).

> 2. Enabling validation (standard)
> The problem is that you need to get your hands on the server's certificate.
> If you distribute an applet for a single server, like I do, you can ship the
> server's certificate with your applet. One thing you certainly don't want is
> to tell people how to insert it with a command line tool (keytool) and so a
> nice solution is to provide it in a keystore and point jdbc to it.
> Furthermore you are likely not to have write permissions on the standard
> keystore (if you want to update it in your applet) because it is in a subdir
> of java_home.

I guess the question is what about keystores that are not plain files.
Providing a general means of allowing the client to provide the certs from
any source they desire.

Could you elaborate more on how you package the keystore with your applet?
I wasn't aware you could do that.

> 3. Trust and save (disable validation and save received key)
> Same as with openssl and known_hosts, you accept the host the first time you
> connect, save its certificate and use the standard mode from then on.
> Implementation of this feature is easier within the driver because you have
> access to the SSL connection and can retrieve the certificate(s). As a user
> you can't just pull it off the postgres port because postgres doesn't start
> off in SSL mode. You will have to implement a TrustManager.

I don't understand what the purpose of this is. Why save the cert if you
aren't going to validate? Don't you need some kind of confirm callback to
allow the user to do some kind of verification of the cert?

Kris Jurka