TLSv1.2 with Thin JDBC driver

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).

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?