A solution to the SSL customizing problem - Mailing list pgsql-jdbc
From | Ulrich Meis |
---|---|
Subject | A solution to the SSL customizing problem |
Date | |
Msg-id | 200410111752.33375.kenobi@halifax.rwth-aachen.de Whole thread Raw |
Responses |
Re: A solution to the SSL customizing problem
Re: A solution to the SSL customizing problem Re: A solution to the SSL customizing problem Re: A solution to the SSL customizing problem |
List | pgsql-jdbc |
I have read previous posts and the proposal that the user should supply a SSLSocketFactory. Besides the obvious question - how - I see an additional problem in that approach: It's anything but user friendly. All you want is a secure connection to postgres and you end up digging deeply into the JSSE spec. Even if all you want is turn validation off, you will have to have some knowledge of the spec. The really hard bit comes when you want to retrieve the certificate from the server. You are using SSL because you are concerned about security, so you probably want checking. Now you will have to give your own TrustManager implementation that saves the certificate received for checking. Furthermore, you will have to save that certificate somehow and you'll end up handling keystores and stuff. What an effort just for this feature! ********** I propose a different solution. There are three modes I can think of when opening a connection: 1. Disabling validation. Not interesting for a user with security concerns - you loose half of SSL's functionality. 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. 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. ************** What I did for the driver is the following: Anologously to javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword I introduced org.postgresql.trustStore and org.postgresql.trustStorePassword Now you can specify your own trustStore for pgjdbc connections. If it doesn't exist, it will be created for you. Additionally I introduced the trust-and-save mode. Currently I look for a property org.postgresql.ssl_trustandsave but this would better be handled in a URL parameter like "ssl_trustandsave". When the driver is in trust-and-save mode, it will trust any server you connect to and save its certificate in the trustStore. In an application, you would first run in normal mode. If the connection fails, you ask the user if he wants to trust the unknown key and if he agrees, you connect again with ssl_trustandsave mode activated and the key is saved. In subsequent connections, you turn ssl_trustandsave off. ********** Implementation: I introduced a class org.postgresql.util.PGSSLSocketFactory and changed one line in org.postgresql.Driver and method makeSSL from javax.net.ssl.SSLSocketFactory factory = (javax.net.ssl.SSLSocketFactory) javax.net.ssl.SSLSocketFactory.getDefault(); to org.postgresql.util.PGSSLSocketFactory factory = org.postgresql.util.PGSSLSocketFactory.getInstance(); . What do you think? Kind Regards, Uli
Attachment
pgsql-jdbc by date: