TLSv1.2 with Thin JDBC driver

User_5FQQH

I've set up a secure connection, and the handshake connects using TLSv1.

Is there a way to have it negotiate TLSv1.2?

I'm using ojdbc7.jar from 12.1.0.2

The connection is made using a javax.sql.DataSource reference with org.apache.commons.dbcp.BasicDataSourceFactory

The secure connection works, and it negotiates a TLSv1 connection. However, I've been asked to use TLSv1.2. The client initiates the handshake with:

"*** ClientHello, TLSv1"

Which means the server will negotiate back with TLSv1.

How do I get the client to start the handshake with a hello TLSv1.2?

I've tried setting the following options:

-Djdk.tls.client.protocols=TLSv1.2

-Dhttps.protocols=TLSv1.2

but neither has had an effect.

User_5FQQH

For anyone coming across this issue, here is the answer:

When using ojdbc7 version 12.1.0.2 of the Java Thin JDBC client, there is a known bug (19030178) where the JDBC thin client doesn't recognize TLS 1.1 and 1.2 ciphers.

There is a patch available if you have an Oracle support account.

When connecting to an Oracle 12 server that has TLS 1.2 support, with the patch I now get:

*** ClientHello, TLSv1.2

*** ServerHello, TLSv1.2

and with an Oracle 11 server that only supports TLS 1, I get:

*** ClientHello, TLSv1.2

*** ServerHello, TLSv1

and the communication continues in TLSv1

This is now working as expected.

Unknown

Thanks for reposting but you did NOT post the info I ask you to post:

When you repost provide the code you are using that shows how you are connecting.

Also post any info about how the client JVM is being launched and the properties being set:

And as you were told in your other thread BOTH SIDES have to agree on the protocol to use. So you need to make sure the desired protocol is both supported by the server and configured properly on the server.

But, again, you haven't post ANY info about the server you are using or whether it is configured for the protocol you want to use.

User_5FQQH

1. I described what the code is doing, which I though was enough: it's just a javax.sql.DataSource that is being used.

Does this help?

Reference ref = new Reference("javax.sql.DataSource", "org.apache.commons.dbcp.BasicDataSourceFactory", null);

  ref.add(new StringRefAddr("driverClassName", Configurator.getJDBCDriver()));

  ref.add(new StringRefAddr("url", Configurator.getURL()));

  ref.add(new StringRefAddr("username", Configurator.getUser()));

  ref.add(new StringRefAddr("password", Configurator.getPassword()));

  ref.add(new StringRefAddr("maxActive", Configurator.getMaxActive()));

  ref.add(new StringRefAddr("maxIdle", Configurator.getMaxIdle()));

  ref.add(new StringRefAddr("maxWait", Configurator.getMaxWait()));

  ref.add(new StringRefAddr("defaultAutoCommit", Configurator.getDefaultAutoCommit().toString()));

  ref.add(new StringRefAddr("logAbandoned", Configurator.getLogAbandoned().toString()));

  ref.add(new StringRefAddr("removeAbandoned", Configurator.getRemoveAbandoned().toString()));

  ref.add(new StringRefAddr("removeAbandonedTimeout", Configurator.getRemoveAbandonedTimeOut()));

  ref.add(new StringRefAddr("accessToUnderlyingConnectionAllowed", "true"));

this.resource=new Resource(Configurator.getJNDIName(), ref);

When a connection is needed, this is done:

InitialContext ic = new InitialContext();

DataSource ds = (DataSource)ic.lookup(GCConfigurator.getJNDIName());

conn = ds.getConnection();

I set the trustStore using

-Djavax.net.ssl.trustStore=myTrustStore

-Djavax.net.ssl.trustStoreType=JKS

-Djavax.net.ssl.trustStorePassword=password

2. The client side says "hello" first, and then the server replies with "hello" back indicating if it supports the same protocol or needs a level lower. If the client is saying "hello" with TLSv1, then the server will never return TLSv1.2.

For example, if I run the exact same code against a SQL Server with the MS JDBC:

a. If the SQL Server does not support TLSv1.2 I get:

*** ClientHello, TLSv1.2

*** ServerHello, TLSv1

b. If the SQL Server does support TLSv1.2 I get:

*** ClientHello, TLSv1.2

*** ServerHello, TLSv1.2

Against Oracle with the Oracle JDBC driver I get:

*** ClientHello, TLSv1

*** ServerHello, TLSv1

I would be happy if I could get Oracle to do this:

*** ClientHello, TLSv1.2

*** ServerHello, TLSv1

Then at least I would know that my JDBC driver is attempting v1.2 and I could then start looking at the server.

What I need to know is how to get the client to say "hello" with v1.2 (or if the Oracle JDBC driver even supports v1.2).

Unknown

I don't see ANY mention of TLSv1.2 anywhere in what you posted above and don't see any info about what Java version you are using or how it is being launched.

That code also doesn't show what JDBC jar file and version are being used. Modify the code to print out the version info.

Both the server and client need to be configured to use TLSv1.2 and you need to ENABLE it on both sides depending on the functionality you want to use.

See if this article helps

A journey through tech goodness...: Java 7 and TLSv1.2 - supported, but not enabled by default

Java 7 and TLSv1.2 - supported, but not enabled by default

  
  Lately, I had to investigate how to make a Java 7 client connect to a server resource (in my case a JMS broker server) using sockets or http traffic over secure TLS v1.2 protocol (and only TLS v1.2... all other communication protocols should be refused). This would all have been a breeze if my client app was on Java 8...but being on Java 7, it was a completely different story.

User_5FQQH

I don't see ANY mention of TLSv1.2 anywhere in what you posted above

I'm sorry, I guess I don't understand what you are looking for. In my OP I stated that I was setting the following options:

-Djdk.tls.client.protocols=TLSv1.2

-Dhttps.protocols=TLSv1.2

and don't see any info about what Java version you are using or how it is being launched.

The JRE used to launch is JRE 1.8.0_60

I am currently launching via Eclipse, but in the field it will be run from a service wrapper.

That code also doesn't show what JDBC jar file and version are being used.

In my OP I stated: I'm using ojdbc7.jar from 12.1.0.2

Both the server and client need to be configured to use TLSv1.2 and you need to ENABLE it on both sides depending on the functionality you want to use.

Yes, I understand that. My question is how do I enable it on the client side?

I ran the code from the article you provided to see what gets printed out for supported/enabled protocols. This is what is output:

Supported Protocols: 5

SSLv2Hello

SSLv3

TLSv1

TLSv1.1

TLSv1.2

Enabled Protocols: 3

TLSv1

TLSv1.1

TLSv1.2

Which means that TLSv1.2 is enabled, but the client side is choosing not to use it.

Does ojdb7.jar from 12.1.0.2 have some sort of connection property that needs to be set to use TLSv1.2 as default or is it not supported?

User_5FQQH

For anyone coming across this issue, here is the answer:

When using ojdbc7 version 12.1.0.2 of the Java Thin JDBC client, there is a known bug (19030178) where the JDBC thin client doesn't recognize TLS 1.1 and 1.2 ciphers.

There is a patch available if you have an Oracle support account.

When connecting to an Oracle 12 server that has TLS 1.2 support, with the patch I now get:

*** ClientHello, TLSv1.2

*** ServerHello, TLSv1.2

and with an Oracle 11 server that only supports TLS 1, I get:

*** ClientHello, TLSv1.2

*** ServerHello, TLSv1

and the communication continues in TLSv1

This is now working as expected.

Unknown

For anyone coming across this issue, here is the answer:

When using ojdbc7 version 12.1.0.2 of the Java Thin JDBC client, there is a known bug where the JDBC thin client doesn't recognize TLS 1.1 and 1.2 ciphers.
There is a patch available if you have an Oracle support account.

Please post the 'bug' identifier so we can research it.