JDBC Client Encryption Type Setup - encryption

Question

I'm trying to force my client application to connect to an encrypted Oracle 11g server using AES256 instead of RC4_256. We have been notified that the RC4_256 encryption type will be disabled "soon".
We are using the latest 11g drivers with c3p0 as our connection pool. Below is the bean config.
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
<property name="driverClass" value="oracle.jdbc.OracleDriver"/>
<property name="jdbcUrl" value="${jdbc.url}"/>
<!-- other pool properties -->
<property name="properties">
<props>
<prop key="user">${jdbc.username}</prop>
<prop key="password">${jdbc.password}</prop>
<!-- this is one set of many I've tried -->
<prop key="oracle.net.encryption_client">REQUIRED</prop>
<prop key="oracle.net.encryption_types_client">( AES256 )</prop>
</props>
</property>
</bean>
I've tried many permutations using oracle.net.encryption_types_client, and oracle.net.encryption_client, CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_LEVEL, CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_TYPES. I've named them as is in the Oracle docs, as Java properties, etc.
I haven't been able to get it to connect using anything but RC4_256.
I'm using the following query on the database server to see how my client is connecting. The Network_Service_Banner from the v$session_connect_info table shows how it's connecting. Here is the current message I'm getting
Oracle Advanced Security: RC4_256 encryption service adapter for
Solaris: Version 11.2.0.3.0 - Prod
select s.username,s.machine,s.program,S.LOGON_TIME,s1.*
from v$session s, v$session_connect_info s1
where s.sid = s1.sid and s.username in ('MYAPP') and s.machine = 'MY-PC'
order by S.LOGON_TIME DESC, s.sid
Any help would be appreciated as I'm wrapped around the axle at this point.

Answer 1

I will take a shot at this, since I too am reading on this subject within the recent days. It appears that we need to make changes to the SQLNET.ora files on the server and/or the client to make this work.
Refer to this link where there is an illustration of how to use AES to connect to the database. specifically, take a look at Example 9-3 Setting Data Encryption and Integrity Parameters. Above this example are the settings needed to be done in the sqlnet.ora files to enable AES encryption. These are quoted below from the link
SQLNET.ENCRYPTION_SERVER = ACCEPTED
SQLNET.CRYPTO_CHECKSUM_SERVER = ACCEPTED
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER= (MD5, SHA1)
SQLNET.ENCRYPTION_TYPES_SERVER= (AES256, AES192, AES128)
SQLNET.CRYPTO_SEED = 2z0hslkdharUJCFtkwbjOLbgwsj7vkqt3bGoUylihnvkhgkdsbdskkKGhdk
Quoting from this link:
For both data encryption and integrity algorithms, the server selects
the first algorithm listed in its sqlnet.ora file that matches an
algorithm listed in the client sqlnet.ora file, or in the client
installed list if the client lists no algorithms in its sqlnet.ora
file. If there are no entries in the server sqlnet.ora file, the
server sequentially searches its installed list to match an item on
the client side—either in the client sqlnet.ora file or in the client
installed list. If no match can be made and one side of the connection
REQUIRED the algorithm type (data encryption or integrity), the
connection fails. Otherwise, the connection succeeds with the
algorithm type inactive.
If you read through the page mentioned above and refer to the table Table A-6 SQLNET.ENCRYPTION_TYPES_SERVER Parameter Attributes under section A.2.1.5 SQLNET.ENCRYPTION_TYPES_SERVER Parameter , we see that the first encryption algorithm to be matched by the server is RC4_256 which in your case may be matching the client end of the installed encryption algorithms and that is the reason the connection may succeed. However, when you specify another algorithm such as AES 256, this algorithm may not be negotiable by the client and server resulting in a connection failure.
The page listed above, details the necessary settings for enabling data integrity and encryption.
Hope this gives you a step towards the solution

Answer 2

It turns out that the c3p0 configuration is really strait forward.
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
<property name="driverClass" value="oracle.jdbc.OracleDriver"/>
<property name="jdbcUrl" value="${jdbc.url}"/>
<!-- other pool properties -->
<property name="properties">
<props>
<prop key="user">${jdbc.username}</prop>
<prop key="password">${jdbc.password}</prop>
<prop key="oracle.net.encryption_client">REQUIRED</prop>
<prop key="oracle.net.encryption_types_client">(AES256)</prop>
<prop key="oracle.net.crypto_checksum_client">REQUIRED</prop>
<prop key="oracle.net.crypto_checksum_types_client">(SHA1)</prop>
</props>
</property>
</bean>
It wasn't working in our case because we had two different version of the jdbc drivers in the class path and the older one was getting loaded first.
After removing the old jdbc jar, it switched to AES256 as the config dictated.