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
