jTDS - SQL Server and Sybase JDBC driver / Bugs / #725 jTDS driver ssl connection hangs with JRE 1.8

technocrat - 2014-05-05

Few additional notes:
1. When I remove this property and run the code on JRE 1.8, it works fine.
2. When I run the code on JRE 1.7 with this property then also it works fine.

Also database server I am using is Microsoft Sql Server 2008 R2.

Last edit: technocrat 2014-05-06

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

technocrat - 2014-05-07

Hi Momo,

Update: I tried connecting to database with ssl connection using Microsoft JDBC driver and it is working perfectly fine on both JRE 1.7 and 1.8.

Please let us know if you could help us debugging the issue in jTDS.

Last edit: technocrat 2014-05-07

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

lkoniecki - 2014-05-14

There is a problem with TdsTlsOutputStream implementation. Since Java 1.8 byte array passed to the write method contains 256 bytes of irrelevant data at the beginning. Off parameter is properly pointing at at the beginning of the relevant data but it is not being used by the OutputStream implementation.

Patch for jtds-1.3.1 in attachment.

It was tested against JRE 1.7.0_45 and 1.8.0_5. It works for TLSv1, TLS1.1 and TLS1.2 and for all Cipher Suites.

One problem spotted: force client side to use TLSv1.2. If SQL Server supports only TLSv1 and client uses set of cipher suites that neither of them is supported by the server side IOException is being thrown. This occurs for jtds-1.3.1 before and after my modifications.

trigger seeding of SecureRandom
done seeding SecureRandom
Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
SSLv3
TLSv1
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_RC4_128_MD5
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
%% No cached client session
*** ClientHello, TLSv1.2
RandomCookie: GMT: 1400058228 bytes = { 219, 87, 43, 211, 81, 215, 117, 228, 167, 4, 151, 65, 180, 10, 236, 190, 41, 118, 73, 140, 160, 41, 248, 31, 212, 170, 217, 74 }
Session ID: {}
Cipher Suites: [TLS_DHE_DSS_WITH_AES_128_CBC_SHA256]
Compression Methods: { 0 }
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA224withECDSA, SHA224withRSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA, MD5withRSA
Extension renegotiation_info, renegotiated_connection: <empty></empty>

main, WRITE: TLSv1.2 Handshake, length = 82
main, handling exception: java.io.IOException
main, SEND TLSv1 ALERT: fatal, description = unexpected_message
main, WRITE: TLSv1 Alert, length = 2
main, called closeSocket()
Cannot connect to database server
java.sql.SQLException: Network error IOException: null
at net.sourceforge.jtds.jdbc.JtdsConnection.<init>(JtdsConnection.java:437)
at net.sourceforge.jtds.jdbc.Driver.connect(Driver.java:184)
at java.sql.DriverManager.getConnection(DriverManager.java:571)
at java.sql.DriverManager.getConnection(DriverManager.java:215)
at Jtds.main(Jtds.java:32)
Caused by: java.io.IOException
at net.sourceforge.jtds.ssl.TdsTlsInputStream.readFully(TdsTlsInputStream.java:137)
at net.sourceforge.jtds.ssl.TdsTlsInputStream.primeBuffer(TdsTlsInputStream.java:100)
at net.sourceforge.jtds.ssl.TdsTlsInputStream.read(TdsTlsInputStream.java:78)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
at sun.security.ssl.InputRecord.read(InputRecord.java:480)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323)
at net.sourceforge.jtds.ssl.SocketFactories$TdsTlsSocketFactory.createSocket(SocketFactories.java:114)
at net.sourceforge.jtds.jdbc.SharedSocket.enableEncryption(SharedSocket.java:331)
at net.sourceforge.jtds.jdbc.TdsCore.negotiateSSL(TdsCore.java:577)
at net.sourceforge.jtds.jdbc.JtdsConnection.<init>(JtdsConnection.java:365)
... 4 more
</init></init>

TdsTlsOutputStream.diff

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Bain - 2014-10-23
  
  Thanks for tracking down this bug. Do you think there is any need for the JDK check. This check does not make sense because an SSL packet is valid anywhere in a buffer. All the check will do is introduce similar bugs if the SSL implementation changes again.
  
  I updated your patch to remove the check.
  
  Last edit: Bain 2014-10-23
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

technocrat - 2014-05-27

Thanks koniecki!
Can you please tell me how to force client side to use TLSv1.2?
Do I need to set any system property for that?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

lkoniecki - 2014-05-27

It is a default on Java 8.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

technocrat - 2014-05-28

But I am getting the same error when I try to run the code on Java 8

java.sql.SQLException: Network error IOException: null
at net.sourceforge.jtds.jdbc.JtdsConnection.(JtdsConnection.java:437)
at net.sourceforge.jtds.jdbc.Driver.connect(Driver.java:184)
at java.sql.DriverManager.getConnection(DriverManager.java:571)
at java.sql.DriverManager.getConnection(DriverManager.java:215)
at Jtds.main(Jtds.java:32)
Caused by: java.io.IOException

Is there anything else I need to set specifically?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

lkoniecki - 2014-05-29

But I am getting the same error when I try to run the code on Java 8

Can you copy-paste your JDBC URL, connection properties as well as how you are creating the connection?

Please enable SSL debug (-Djavax.net.debug=all) and post the content.

Is there anything else I need to set specifically?

jsse.enableCBCProtection=false setting is still required to make the SSL connection working both on JRE7 and JRE8.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- vermicious - 2014-09-03
  
  I'm experiencing the same issue with 1.8 u20:
  
  This thread seems to have died, but I'm having this problem with 1.8 u20. Here's the requested output from my experience with it:
  
  03-09-2014 18:29:51,429 DefaultQuartzScheduler-camel-1_Worker-2 DEBUG (DataSourceUtils.java:110) - Fetching JDBC Connection from DataSource
  03-09-2014 18:29:51,429 DefaultQuartzScheduler-camel-1_Worker-2 DEBUG (DriverManagerDataSource.java:162) - Creating new JDBC DriverManager Connection to [jdbc:jtds:sqlserver://X.X.X.X/dbName;MultipleActiveResultSets=true;ssl=require]
  trigger seeding of SecureRandom
  done seeding SecureRandom
  Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
  Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA
  Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
  Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
  Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
  Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
  Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
  Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384
  Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
  Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
  Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
  Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
  Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
  Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  Allow unsafe renegotiation: false
  Allow legacy hello messages: true
  Is initial handshake: true
  Is secure renegotiation: false
  Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 for SSLv3
  Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 for SSLv3
  Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256 for SSLv3
  Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 for SSLv3
  Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 for SSLv3
  Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 for SSLv3
  Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 for SSLv3
  Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1
  Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1
  Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256 for TLSv1
  Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1
  Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 for TLSv1
  Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1
  Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 for TLSv1
  Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
  Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
  Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
  Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
  Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
  Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
  Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 for TLSv1.1
  %% No cached client session
  *** ClientHello, TLSv1.2
  RandomCookie: GMT: 1409717855 bytes = { 16, 114, 113, 206, 163, 21, 148, 178, 144, 124, 99, 203, 214, 125, 110, 34, 225, 123, 177, 159, 145, 17, 198, 133, 162, 117, 182, 198 }
  Session ID: {}
  Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
  Compression Methods: { 0 }
  Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}
  Extension ec_point_formats, formats: [uncompressed]
  Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA224withECDSA, SHA224withRSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA, MD5withRSA
  
  [write] MD5 and SHA1 hashes: len = 207
  0000: 01 00 00 CB 03 03 54 07 96 5F 10 72 71 CE A3 15 ......T...rq...
  0010: 94 B2 90 7C 63 CB D6 7D 6E 22 E1 7B B1 9F 91 11 ....c...n"......
  0020: C6 85 A2 75 B6 C6 00 00 46 C0 23 C0 27 00 3C C0 ...u....F.#.'.<.
  0030: 25 C0 29 00 67 00 40 C0 09 C0 13 00 2F C0 04 C0 %.).g.@...../...
  0040: 0E 00 33 00 32 C0 07 C0 11 00 05 C0 02 C0 0C C0 ..3.2...........
  0050: 2B C0 2F 00 9C C0 2D C0 31 00 9E 00 A2 C0 08 C0 +./...-.1.......
  0060: 12 00 0A C0 03 C0 0D 00 16 00 13 00 04 00 FF 01 ................
  0070: 00 00 5C 00 0A 00 34 00 32 00 17 00 01 00 03 00 .....4.2.......
  0080: 13 00 15 00 06 00 07 00 09 00 0A 00 18 00 0B 00 ................
  0090: 0C 00 19 00 0D 00 0E 00 0F 00 10 00 11 00 02 00 ................
  00A0: 12 00 04 00 05 00 14 00 08 00 16 00 0B 00 02 01 ................
  00B0: 00 00 0D 00 1A 00 18 06 03 06 01 05 03 05 01 04 ................
  00C0: 03 04 01 03 03 03 01 02 03 02 01 02 02 01 01 ...............
  DefaultQuartzScheduler-camel-1_Worker-2, WRITE: TLSv1.2 Handshake, length = 207
  [Raw write]: length = 212
  0000: 16 03 03 00 CF 01 00 00 CB 03 03 54 07 96 5F 10 ...........T...
  0010: 72 71 CE A3 15 94 B2 90 7C 63 CB D6 7D 6E 22 E1 rq.......c...n".
  0020: 7B B1 9F 91 11 C6 85 A2 75 B6 C6 00 00 46 C0 23 ........u....F.#
  0030: C0 27 00 3C C0 25 C0 29 00 67 00 40 C0 09 C0 13 .'.<.%.).g.@....
  0040: 00 2F C0 04 C0 0E 00 33 00 32 C0 07 C0 11 00 05 ./.....3.2......
  0050: C0 02 C0 0C C0 2B C0 2F 00 9C C0 2D C0 31 00 9E .....+./...-.1..
  0060: 00 A2 C0 08 C0 12 00 0A C0 03 C0 0D 00 16 00 13 ................
  0070: 00 04 00 FF 01 00 00 5C 00 0A 00 34 00 32 00 17 ..........4.2..
  0080: 00 01 00 03 00 13 00 15 00 06 00 07 00 09 00 0A ................
  0090: 00 18 00 0B 00 0C 00 19 00 0D 00 0E 00 0F 00 10 ................
  00A0: 00 11 00 02 00 12 00 04 00 05 00 14 00 08 00 16 ................
  00B0: 00 0B 00 02 01 00 00 0D 00 1A 00 18 06 03 06 01 ................
  00C0: 05 03 05 01 04 03 04 01 03 03 03 01 02 03 02 01 ................
  00D0: 02 02 01 01 ....
  DefaultQuartzScheduler-camel-1_Worker-2, handling exception: java.net.SocketException: Connection reset
  DefaultQuartzScheduler-camel-1_Worker-2, SEND TLSv1.2 ALERT: fatal, description = unexpected_message
  DefaultQuartzScheduler-camel-1_Worker-2, WRITE: TLSv1.2 Alert, length = 2
  DefaultQuartzScheduler-camel-1_Worker-2, Exception sending alert: java.net.SocketException: Broken pipe
  DefaultQuartzScheduler-camel-1_Worker-2, called closeSocket()
  03-09-2014 18:31:29,786 DefaultQuartzScheduler-camel-1_Worker-2 DEBUG (MarkerIgnoringBase.java:72) - Failed delivery for (MessageId: ID-xxxxxxxxxx-34561-1409783384284-0-5 on ExchangeId: ID-xxxxxxxxxx-34561-1409783384284-0-6). On delivery attempt: 0 caught: org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is java.sql.SQLException: Network error IOException: Connection reset
  03-09-2014 18:31:29,790 DefaultQuartzScheduler-camel-1_Worker-2 ERROR (MarkerIgnoringBase.java:161) - Failed delivery for (MessageId: ID-xxxxxxxxxx-34561-1409783384284-0-5 on ExchangeId: ID-xxxxxxxxxx-34561-1409783384284-0-6). Exhausted after delivery attempt: 1 caught: org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is java.sql.SQLException: Network error IOException: Connection reset
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ricardo Vaz Mannrich - 2014-09-26

+1

I'm experiencing this problem too.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

David Hill - 2014-10-08

show stopper for our organization, projects are activly being ported over to Microsoft drivers, would much prefer to use JTDS

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bain - 2014-10-23

We are also having the same problems.

I have updated the patch provided by lkoniecki to remove the check for the JDK version. I can't see the logic to the initial if statement as it could be a TLS packet no matter where it starts (e.g. it would be perfectly valid for JDK 1.7 to start using an offset other than zero). I don't think it is necessary. I ran the tests under JDK 1.7 and JDK 1.8 and no more failed than is normal (at the moment between 11-14 fail).

Is there a chance we could get this patch applied and released into a new jTDS version?

Last edit: Bain 2014-10-23

fix.patch

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- clahav - 2014-11-13
  
  hi lkoniecki
  
  thanks for the help & effort
  can you please release a new version of the driver that includes the severe ssl fix?
  
  thanks
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

momo - 2014-11-13

Thanks technocrat for reporting this problem, and lkoniecki for investigating and providing a fix. I applied your patch (without Java version check as proposed by Bain) with SVN revision [1286].

Cheers,
momo

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

momo - 2014-11-13

status: open --> closed

assigned_to: momo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Brion Maciel - 2015-05-26
  
  How does one apply the patch? Is there a place to get the patched version?
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - technocrat - 2015-05-27
    
    Is there any plan on releasing the new version which contains this fix?
    
    On Wednesday, May 27, 2015 8:32 AM, Brion Maciel <brion8@users.sf.net> wrote:
    
    How does one apply the patch? Is there a place to get the patched version? [bugs:#725] jTDS driver ssl connection hangs with JRE 1.8Status: closed
    Group: v1.3
    Labels: java8 ssl hang jdbc database connection
    Created: Mon May 05, 2014 11:21 AM UTC by technocrat
    Last Updated: Tue Mar 10, 2015 06:42 PM UTC
    Owner: momoThe jTDS (net.sourceforge.jtds) jdbc driver is hanging after login when SSL is used with JRE 1.8.I am using "ssl=request" connection property in jdbc url to configure secure connection.Here is the stack trace or error:Caused by: java.sql.SQLException: Network error IOException: Connection reset
    at net.sourceforge.jtds.jdbc.JtdsConnection.<init>(JtdsConnection.java:436)
    at net.sourceforge.jtds.jdbc.Driver.connect(Driver.java:184)
    at java.sql.DriverManager.getConnection(DriverManager.java:664)
    at java.sql.DriverManager.getConnection(DriverManager.java:208)I am using jtds-1.3.1 jar. Is there any workaround/fix for this issue?P.S. : I have compiled my code on Java 8 and trying to run it on JRE 1.8.Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/jtds/bugs/725/To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/</init>
    
    Related
    
    Bugs: ~~#725~~
    
    alternate
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - lkoniecki - 2015-05-28
    
    Locally compiled version of 1.3.1 with patch applied
    
    jtds-1.3.1-v20140512.jar
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Tamal - 2015-02-02

Hi momo, I Have faced the same issue in jTDS version 1.3.1. Below is the error log:

ERROR [main] [PoolManager] Failed to get database connection!
java.sql.SQLException: Network error IOException: Connection reset
at net.sourceforge.jtds.jdbc.JtdsConnection.<init>(JtdsConnection.java:434)
at net.sourceforge.jtds.jdbc.Driver.connect(Driver.java:183)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:247)
... 14 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:189)
at java.net.SocketInputStream.read(SocketInputStream.java:121)
at net.sourceforge.jtds.ssl.TdsTlsInputStream.readFully(TdsTlsInputStream.java:131)
at net.sourceforge.jtds.ssl.TdsTlsInputStream.primeBuffer(TdsTlsInputStream.java:100)
at net.sourceforge.jtds.ssl.TdsTlsInputStream.read(TdsTlsInputStream.java:78)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
at sun.security.ssl.InputRecord.read(InputRecord.java:503)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:961)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
at net.sourceforge.jtds.ssl.SocketFactories$TdsTlsSocketFactory.createSocket(SocketFactories.java:101)
at net.sourceforge.jtds.jdbc.SharedSocket.enableEncryption(SharedSocket.java:361)
at net.sourceforge.jtds.jdbc.TdsCore.negotiateSSL(TdsCore.java:554)
at net.sourceforge.jtds.jdbc.JtdsConnection.<init>(JtdsConnection.java:363)
... 24 more</init></init>

JDK 1.8.0_31
SQL Server 2012 - 11.0.3153.0
URL: jdbc:jtds:sqlserver://localhost/mydb;appName=Core Services;TDS=8.0;ssl=authenticate

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jeffery K - 2015-03-10

Is there a way to get a release with this fix in it, made soon? I imagine many users of jtds who talk to servers that use encryption, will have this problem a lot more as java 8 become more prevalent. We use the ssl=request since we deploy a product which uses a customer's database, and we don't know if they will have ssl or not, and even on a non-ssl SQL server, this is failing for us on java 8. We are unable to claim java 8 support until we can get a release with this fix. Any eta on the next GA release?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ori Zuckerman - 2015-12-14

Same here. We use ssl=request as we don't know if the database uses ssl or not. This is a blocker for us. Is there any way to get a release with this fix? Or at least an eta on the next release? The other option is to move to Microsoft JDBC which we strongly prefer not to.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Tamal - 2015-12-14

I have attached the patched JTDS binary. It is compiled with JDK 8.

jtds-1.3.1.jar

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Ori Zuckerman - 2015-12-14
  
  Thank you Tamal, but i need to have an official release.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- juwoco - 2024-08-30
  
  Thanks! You just saved me a lot of emergency work on a legacy system after our db sever went SSL only.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Nida - 2016-01-15

Hi,
This fix actually resolves my issue. When will this be delievered ?

thanks,
Nida

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

jTDS driver ssl connection hangs with JRE 1.8

Group

Searches

Help

#725 jTDS driver ssl connection hangs with JRE 1.8

Related

Discussion

Related