#767 SSL handshake hangs on JRE 1.7 because TdsTlsOutputStream.write() gets called with multiple TLS records

[Michael Ben Yosef]

This bug is closely related to #725 jTDS driver ssl connection hangs with JRE 1.8, which is patched in Patch #129 and fixed in r1286. That bug was due to TdsTlsOutputStream.write(b, off, len) assuming that the offset off is always 0.

Using a build of the current SVN HEAD for the branch jTDS 1.3 Stable (r1289) we get a connection from a JtdsDataSource with a setSsl("require") and everything works fine when running on a 1.8 JRE. However, we still encounter the same hanging symptom as in #725 when running on a 1.7 JRE. The suggested workaround of setting jsse.enableCBCProtection=false fixes the problem, but is undesirable.

While inspecting variables in the debugger, I discovered that TdsTlsOutputStream.write(b, off, len) is being called with more than one TLS record at a time, when it expects at most one, i.e. there is more than one record in the interval b[off] to b[off+len-1]. This means that len is longer than expected and the code

if( contentType < Ssl.TYPE_CHANGECIPHERSPEC || contentType > Ssl.TYPE_APPLICATIONDATA || length != len - Ssl.TLS_HEADER_SIZE )
 {
     // assume SSLv2 client hello
     putTdsPacket( b, off, len );
     return;
 }

causes the bytes to be incorrectly treated as an SSLv2 client hello, as the comment says.

I am not sure which exact JRE versions this affects. It seems reasonable for FilterOutputStream.write() (the method being overriden) to be called with more than one TLS record, though.

In any case, the fix is simple - SVN diff attached. Instead of expecting one TLS record, we put the previous processing code in a loop, continuing to process TLS records as long as they can be identified.

We would be very grateful if this patch or a similar one could be committed to jTDS 1.3 Stable.

[Markus Heberling]

I have this problem with Java8 and the patch fixes it. Would be great if it could be integrated into SVN.