Working around Java 7 issue with DH-based cipher suites

["Besosa, Michael" <mi...@pearson.com>]

I'm in the process of migrating an application that was successfully using
embedded Derby to the Derby Network Server using SSL in basic mode. I've
run into what seems to be an old issue with Java 7 and cipher suites that
use Diffie-Hellman key exchange. The issue is well described here:

        https://community.oracle.com/thread/2506695

I see exactly the described symptoms: TLS connections are successfully
negotiated for a while, then, after an unpredictable number of successful
negotiations as a result of calling DriverManager.getConnection(), one will
sudden fail with an invalid padding length error that causes a negotiation
failure. This can happen on the first connection attempt or after hundreds
of successful connections. It's completely unpredictable.

I'm seeing this running Java 1.7u79. Apparently it has been present in all
releases since 1.7u6.

The two suggested workarounds are to (1) force selection of a cipher suite
that doesn't use DHE. I don't see a way to coerce Derby into doing that. Or
(2) use a different JCE provider, such as BouncyCastle. However, when I try
to do that, either by editing java.security or dynamically inserting the BC
provider ahead of the Oracle provider, attempts to connect to the server
fail immediately ("connection refused").

I'm out of ideas. Suggestions would be appreciated.

Re: Working around Java 7 issue with DH-based cipher suites

[Rick Hillegas <ri...@gmail.com>]

On 6/25/15 9:37 AM, Besosa, Michael wrote:
> I'm in the process of migrating an application that was successfully 
> using embedded Derby to the Derby Network Server using SSL in basic 
> mode. I've run into what seems to be an old issue with Java 7 and 
> cipher suites that use Diffie-Hellman key exchange. The issue is well 
> described here:
>
> https://community.oracle.com/thread/2506695
>
> I see exactly the described symptoms: TLS connections are successfully 
> negotiated for a while, then, after an unpredictable number of 
> successful negotiations as a result of calling 
> DriverManager.getConnection(), one will sudden fail with an invalid 
> padding length error that causes a negotiation failure. This can 
> happen on the first connection attempt or after hundreds of successful 
> connections. It's completely unpredictable.
>
> I'm seeing this running Java 1.7u79. Apparently it has been present in 
> all releases since 1.7u6.
>
> The two suggested workarounds are to (1) force selection of a cipher 
> suite that doesn't use DHE. I don't see a way to coerce Derby into 
> doing that. Or (2) use a different JCE provider, such as BouncyCastle. 
> However, when I try to do that, either by editing java.security or 
> dynamically inserting the BC provider ahead of the Oracle provider, 
> attempts to connect to the server fail immediately ("connection refused").
>
> I'm out of ideas. Suggestions would be appreciated.
>
Hi Michael,

You are supposed to be able to use any encryption provider which is 
visible on the vm's classpath. See the section on "Specifying an 
alternate encryption provider" in the Derby Security Guide: 
http://db.apache.org/derby/docs/10.11/security/cseccsecure31493.html

I don't know whether this problem affects Java 8 also. Is upgrading your 
vm a possibility?

Hope this helps,
-Rick