Re: A solution to the SSL customizing problem

On Monday 11 October 2004 18:40, Tom Lane wrote:
> Ulrich Meis <kenobi(at)halifax(dot)rwth-aachen(dot)de> writes:
> > I propose a different solution.
>
> One small question --- have you checked that this behaves reasonably
> with both a CVS-tip postmaster and prior releases? CVS tip does do
> certificate presentation and checking, whereas that stuff was
> mistakenly disabled in 7.4. (I think all the relevant changes are
> present in 8.0beta3, but not earlier.)

No, I only tested on 7.4.5 (plz see notes below).
But it does present its certificate, I saved it a hundred times ;-)
I don't think Java would accept a SSL connection without presentation of a
certificate.

Using a different trustStore and trust policy by itself doesn't change the
behavior towards postmaster.The custom SSLContext and the resulting
SSLContextFactory use the defaults in all other cases, so in effect there
shouldn't be any difference in behavior.
In other words if the postmaster works with the current driver, it will work
with the customization, too.

If you are concerned about getting errors in connections that don't use one of
the introduced features, please take a look at the first three lines of
createSocket

*********
public Socket createSocket(Socket socket, String host, int port, boolean
autoClose) throws IOException {
if ((System.getProperty("org.postgresql.Driver.trustStore") == null)
&&
(System.getProperty("org.postgresql.ssl_trustandsave") ==
null))
return ((SSLSocketFactory)
SSLSocketFactory.getDefault()).createSocket(socket, host, port, autoClose);
*********

If no custom behavior is specified, the class uses the same line of code as
you can find in the current Driver.java.
That way bugs in the new class are only exposed if you use a feature.

Uli