#130 Fix SSL connection issue 690

[Bob Loihl]

I work on a product that has SSL connection requirements and we need to use SSL against java 1.8. We filed defect [690][https://sourceforge.net/p/jtds/bugs/690/] and we're possibly encountering defect [708][https://sourceforge.net/p/jtds/bugs/708/]. We did some debugging and found that we were experiencing an error in the handshake related to the BEAST fix. We fixed and tested SSL connections off of HEAD in svn://svn.code.sf.net/p/jtds/code/branches/jTDS%201.2%20(stable) at revision 1289 which includes the patch for SSL defect [129][https://sourceforge.net/p/jtds/patches/129/]. I don't have a patch to apply against 2.0.

DETAILS BELOW:
This fix addresses the need to use -Djsse.enableCBCProtection=false for jtds to work with SQLServer in SSL mode.  This setting disables the Java SSL fix for the BEAST attack.  The actual code change was simply to change a “not equal” to be a “greater than” compare in an if statement.  However, more background is needed to understand the ‘why’ for this.

-The if block in question exists to deal with the fact that in Java 1.6, even when using TLS 1.0, the SSL Client Hello is sent using SSLv2 ‘framing’. Apparently, that was thought to be ‘a good thing’ as some point back when a client needed to work with SSLv2 servers as well as the new-fangled SSLv3/TLS 1.0 servers. Jtds needs to wrap the Client Hello in a TDS packet, so it needed to detect Client Hello when it is wrapped in TLS 1.0 framing and/or when it is wrapped in SSLv2 framing.  It chose to assume that any packet that violates TLS framing (as an SSLv2 Client Hello would) should be ‘wrapped’ in a TDS frame. The check was to see if the header in the write buffer matched the length of the write buffer. This actually worked… up until the Java 1.6.0_XX update that dealt with the BEAST attack.

-It turns out the way JSSE dealt with the BEAST attack was to ‘split’ application data writes into two SSL frames.  The first frame would have 1 byte of user data and the second would have the rest of the user data.  In order to avoid too much extra overhead on the network, JSSE buffered/packed these two SSL frames into one ‘write’ to the network.  And there was much rejoicing… except for jtds users.

-Now, for the first time, the jtds socket stream filter was presented with writes that contained not one, but two SSL frames.  Remember that ‘invalid TLS frame’ detection that was used to detect SSLv2 Client Hello.  It turns out the jtds filter never anticipated multiple TLS frames in one write.  And, of course, a write buffer with more than one valid TLS frame would fail the ‘header matches write size’ check.  So the jtds filter wrongly wrapped this write in a TDS frame.  And there was much wailing and gnashing of teeth.

-The fix I made was to simply change the test for invalid TLS frame from ‘size in header not equal write size’ to ‘size in header greater than write size’.  This was the minimal impact change… but it is only slightly less bad than what was there.  A more robust fix would involve: 1) an affirmative test for an SSLv2 frame header/size test and 2) proper handling of multiple frames in a single write buffer and, maybe, 3) only enabling any of this stuff during initial handshaking (but I’m not sure about how renegotiations are handled vs TDS, so maybe this last is not appropriate).

[Anonymous]

Honestly with the release of the Microsoft SQL driver you should just switch over to that.

https://docs.microsoft.com/en-us/sql/connect/jdbc/microsoft-jdbc-driver-for-sql-server?view=sql-server-ver15

[Anonymous]

How to apply the .patch file changes in the library in android