db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@gmail.com>
Subject Re: Working around Java 7 issue with DH-based cipher suites
Date Thu, 25 Jun 2015 20:14:17 GMT
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: 

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

Hope this helps,

View raw message