JTDS not connecting with SQL Server 2008 R2 SP2 + SSL with Java 6 U34-35

Question

Environment:
Windows 7 Pro 32-bit
SQL Server 2008 R2 SP2 (Forced Encryption = Yes, No Certificate provided to server)
Java 6 Update 27-35 and Java 7 Update 2-7
jTDS 1.2.2 and 1.2.6
Under the following setup, our Java application is able to connect to the SQL Server database:
- SQL Server 2008 R2 SP2
- Java 6 Update 27-33 or Java 7 Update 2-5
just switching the JVM to the following would cause the application to be unable to connect to the database:
- Java 6 Update 34 or 35, or Java 7 Update 6 or 7
Browsing through the Java 6 Update 34 release notes, it looks like nothing big was changed, so I'm wondering what has changed with Java 6 U34 and Java 7 U6. I was also looking through a packet sniffer, and indeed the behavior of Java 6 Update 33 and lower was different from Java 6 Update 34 (although I couldn't understand the messages being passed, the number of connections and messages were different).
* This is different from the issue with Java 6 Update 29-30 and Java 7 wherein they were patched for the BEAST SSL vulnerability. That was fixed with the SP2 patch for SQL Server 2008 R2, and for SQL Server 2008 you'd need a hotfix aside from SP3. After patching the server with those updates, Java 6 Update 29-33 and Java 7 U1-5 should be able to connect to the database.
* If I do switch off Force Encryption, all Java versions are able to connect to the database.
Edited by: user1357749 on Oct 12, 2012 1:20 AM

Answer 1

Hi,
It's four months later, but my colleague and I have reproduced the same behavior in both our commercial product, and a very simple example class. It's exactly as you describe it, where the latest versions of both Java 6 and 7 (and several previous versions) hang during the first jTDS SQL query to the DB (immediately after the SSL and handshake). It also happens with the Microsoft JDBC driver.
If you disable the BEAST SSL fix (-Djsse.enableCBCProtection=false), then the connections work without any problems. So, while this is different from the original BEAST SSL problem and subsequent fix, it really seems like some additional changes were made to the fix in a later Java release that broke things.
My colleague has filed a bug with Oracle, and is awaiting a response. We also filed a bug at the jTDS project (#690 - http://sourceforge.net/p/jtds/bugs/690/) that has simple reproduction steps. A contributer at the jTDS project agrees that this seems to be a problem with the JRE, and is not specific to jTDS.
I hope that Oracle will address this issue soon. We need to periodically update the JRE due to vulnerabilities, and we need to have SSL for our JDBC connections for security reasons. This bug puts us and others in a difficult position.