Re: A solution to the SSL customizing problem

On Monday 11 October 2004 22:07, Kris Jurka wrote:
> 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).
>

I would guess that if you care enough about security to begin with, you would
probably want to take the whole package - assuming it's not too much work.


> > 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.
>

I suggested this version because it seemed to be a problem to offer an
interface to the user.
If you can offer one it's a nice feature to be able to supply a keystore.
I made a suggestion in another post of this thread where the user can supply
either a SSLContextFactory or a KeyStore. I am curious what you'll think
about that.

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

Well, without my proposal you can't ;-)
With it, you can put a keystore file with the certificate in the same dir
where the applet is and read that file via http(s). If you could provide
pgjdbc with a keystore object, you would only have to load it with the file.
Here, you have to save the keystore to some temp directory, set
org.postgresql.trustStore to the temp file, make the connection and finally
delete the temp file. Needs a signed applet.

>
> > 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?

After saving the cert and in subsequent connections you would switch back to
normal mode with validation. Now that the certificate is in your store,
everything goes fine.

Looks like this:

1. Applet tries  "jdbc://foo/bar" and fails with no certificate exception.
2. Applet connects to "jdbc://foo/bar?ssl_trustandsave" and immediately
afterwards closes the connection
3. Applet loads keystore, identifies the new certificate and tells user
"Warning, can't verify identity of DB server, continue?". If the answer is
no, it will delete the entry from the store.

(if confirmed)5. Applet connects to "jdbc://foo/bar" and will succeed.

The shorter version (if you don't care about cert details)

2. Applet asks user "Can't verify identity of DB server, continue?"
3. Applet connects this once with trustandsave



Uli