SSLHandshakeException after upgrade from jdk1.8.0_45 to jdk1.8.0_52

[Jessarah Fl]

Hi

I have a db server that uses H2 db.

It has worked well since many years, and jdk's updates.  However when after from 8 u45 to 8 u51 it now fails to connect: URL:jdbc:h2:ssl://my-sol-10-server:57397//usr/data/ecdb

On java 8 u51 there are about 9 root Certificates removed. 

If I got back to 45 then all is well.  Any ideas how to fix it.  


Error:
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
        at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
        at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
        at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
        at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
        at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
        at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
        at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
        at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:747)
        at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
        at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
        at java.io.DataOutputStream.flush(DataOutputStream.java:123)
        at org.h2.value.Transfer.flush(Transfer.java:97)
        at org.h2.engine.SessionRemote.done(SessionRemote.java:598)
        at org.h2.engine.SessionRemote.initTransfer(SessionRemote.java:119)
        at org.h2.engine.SessionRemote.connectServer(SessionRemote.java:430)


Is there a simple java programmatic fix w/o having to create signed certificates on my system?

thanks

[Manfred Rosenboom]

Hi Jessarah,

I have the same problem. See my post

H2 TCP server and SSL: how to use it?
https://groups.google.com/forum/#!topic/h2-database/GE4Y9KUDBkA

I have tried it first time with Java 8 Update 60 and 66. With the last Java 6/7 versions it runs without any problems. Seems that some of the changes described here http://www.oracle.com/technetwork/java/javase/8u51-relnotes-2587590.html have broken the H2 code.

Best
Manfred

[Jessarah Fl]

Hi Manfred,

Yes, I experience that from 45 to 51 and java 8u51 remove 1024 bit certificates.  I think that is what broke it.

I only want the encryption and do not want to have ea client load a certificate, as it all in the intranet.

regards,

Jess

--
You received this message because you are subscribed to a topic in the Google Groups "H2 Database" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/h2-database/fZ1Vr-sl4z4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to h2-database...@googlegroups.com.
To post to this group, send email to h2-da...@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[C Punk]

I can confirm this happens. Any help would be appreciated.

My systems:
- OpenJDK Runtime Environment (build 1.8.0_72-internal-b05) -- Debian GNU/Linux stretch/sid
- OpenJDK Runtime Environment (IcedTea 2.5.6) (7u79-2.5.6-1~deb8u1) -- Debian GNU/Linux 8

I am testing as follows:

1) Server:
java -server -classpath ./h2-1.4.190.jar -Djavax.net.debug=SSL org.h2.tools.Server -web -webAllowOthers -tcp -tcpSSL -tcpAllowOthers

2) Client:
java -Djavax.net.debug=SSL -cp h2-1.4.190.jar:. Test

...where the class Test is the result of:
javac Test.java

...where Test.java is:
--------------------------code-----------------------------
import java.sql.*;
import java.util.*;

public class Test {
    public static String SERVER_IP = "localhost";
    public static String SERVER_PORT = "9092";

    public static void main(String[] a) throws Exception {
   
        Class.forName("org.h2.Driver");
        String url = "jdbc:h2:ssl://" + SERVER_IP + ":" + SERVER_PORT + "/~/test";
        Properties prop = new Properties();
        prop.setProperty("user", "sa");
        prop.put("password", "");

        Connection conn = null;
        try {
            conn = DriverManager.getConnection(url, prop);
        } finally {
            // nothing here
        }

        System.out.println("Connected.");
        conn.close();
    }
}
------------------------ end code -----------------------

My SSL debug output suggests that CipherFactory.java tries to enable anonymous TLS cipher suits,
but SSL negotiation is ignoring that. To confirm, I edited CipherFactory.java in the following manner:

----------------------------- code --------------------------
private static String[] enableAnonymous(String[] enabled, String[] supported) {
        HashSet<String> set = new HashSet<String>();
        Collections.addAll(set, enabled);
        for (String x : supported) {
            if (!x.startsWith("SSL") &&
                    x.indexOf("_anon_") >= 0 &&
                    x.indexOf("_AES_") >= 0 &&
                    x.indexOf("_SHA") >= 0) {
                System.out.println("Enabling [" + x + "].");
                set.add(x);
            }
        }
        return set.toArray(new String[0]);
    }

    private static String[] disableSSL(String[] enabled) {
        HashSet<String> set = new HashSet<String>();
        for (String x : enabled) {
            if (!x.startsWith("SSL")) {
                System.out.println("Disabling [" + x + "].");
                set.add(x);
            }
        }
        return set.toArray(new String[0]);
    }
----------------------------- end code --------------------------

Then rebuilt using:

javac -sourcepath src/tools -d bin src/tools/org/h2/build/*.java
java -Xmx256m -cp "bin:/usr/lib/jvm/java-7-openjdk-amd64/lib/tools.jar:temp" org.h2.build.Build jar

...then ran the test code and got the output (among other things):

done seeding SecureRandom
Disabling [TLSv1].
Disabling [TLSv1.1].
Disabling [TLSv1.2].
Enabling [TLS_DH_anon_WITH_AES_256_GCM_SHA384].
Enabling [TLS_DH_anon_WITH_AES_128_GCM_SHA256].
Enabling [TLS_DH_anon_WITH_AES_256_CBC_SHA256].
Enabling [TLS_ECDH_anon_WITH_AES_256_CBC_SHA].
Enabling [TLS_DH_anon_WITH_AES_256_CBC_SHA].
Enabling [TLS_DH_anon_WITH_AES_128_CBC_SHA256].
Enabling [TLS_ECDH_anon_WITH_AES_128_CBC_SHA].
Enabling [TLS_DH_anon_WITH_AES_128_CBC_SHA].
Allow unsafe renegotiation: false
Allow legacy hello messages: true

....and it all ended as others have already described. For more detail, I would also paste:

The full server log: http://pastebin.com/LmVqa9aS
The full client log: http://pastebin.com/8msarqGA

[C Punk]

So, I ran into a dead end, and ran out of time -- I cannot figure our why TLS refuses to work, and I cannot force my customer to start manually adding certificates.

My solution is to use VPN to secure database traffic. Can be done very cheap with Raspberry Pi 2. A recipe which proved very useful to me, ironically publised on BBC Tech News. :D It seems to have the added benefit that Android devices (which usually have trouble with anything from the "javax.security" namespace) would also benefit from it.

Sorry for posting it here, since it's not exactly H2-related, but sort of... like getting-around-H2-limitations-related. :)

http://www.bbc.co.uk/news/technology-33548728

[Tomas Pospichal]

Probably the easiest way to see that there is a problem (for most combinations of client/server JREs) is to simply start an H2 server with SSL and then try to shut it down using the same server tool:

 java -cp ./h2-1.4.190.jar org.h2.tools.Server -tcp -tcpSSL &
# TCP server running at ssl://...

 java -cp ./h2-1.4.190.jar org.h2.tools.Server -tcpShutdown "ssl://localhost"
# Exception in thread ... Connection is broken: "javax.net.ssl.SSLHandshakeException: ... PKIX path building failed


Changes in Java regarding certificates are not related to this issue, but most of the observations in this thread are correct. The server side running on many modern JREs ignores anonymous ciphers (Java 6, 7, or 8). I have put a more detailed description of the causes in https://github.com/h2database/h2database/issues/235

A pull request which restores the ability to use anonymous TLS for H2 connections has been posted too. In general, one would have to update the h2 library on both server and client side to have it working reliably, however.

Regards,
Tomas

[Tomas Pospichal]

It has been a month since I filed the issue #235 about anonymous SSL failures at https://github.com/h2database/h2database/issues/235

Unfortunately, neither the issue nor the associated pull request has led to any
reaction.

Here is a sample list of JREs where anonymous SSL connections fail:
OpenJDK 1.6.0_38 (Linux), OpenJDK 1.7.0_95 (Linux), Oracle JDK 1.8.0_72-b15
(Linux), Oracle JDK 1.8.0_66-b18 (Windows)

The only environments which I have access where the anonymous SSL happens to work are
Oracle JDK 1.6.0_45 (Windows) and Oracle JDK 1.7.0_71 (Windows).

In short, the only versions where the feature works are obsolete and
unsupported versions of Java which do not receive updates
(and anyone using them is likely to migrate away from those, sooner or later).

I am not sure what more I could do to get this problem fixed.

Tomas

[Noel Grandin]

On 2016/02/29 7:35 PM, Tomas Pospichal wrote:
> It has been a month since I filed the issue #235 about anonymous SSL failures at
> https://github.com/h2database/h2database/issues/235
>
> Unfortunately, neither the issue nor the associated pull request has led to any
> reaction.
>

Sorry about that, I had hoped Thomas would have time to look at it, since I'm not sufficiently knowledge in these
matters to really know what is going on there.

Anyhow, I've merged it "on faith", lets see how it goes :-)

Thanks for the patch

[Tomas Pospichal]

Noel, I know that you and Thomas are extremely committed to this project and spend an incredible amount of time improving the library and helping people who run into problems. I was not too happy that this issue seemed to be ignored, but I understand that it is sometimes hard to find time for everything.

At least there is a somewhat optimistic interpretation that perhaps not many people actually depend on the anonymous TLS (which is a rather unorthodox use of the machinery) to care about it.

Tomas