8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | 23c | Misc | PL/SQL | SQL | RAC | WebLogic | Linux

Home » Articles » Misc » Here

Native Network Encryption for Database Connections

From 10g Release 2 onward, Native Network Encryption and TCP/IP with SSL/TLS are no longer part of the Advanced Security Option. Native network encryption gives you the ability to encrypt database connections, without the configuration overhead of TCP/IP and SSL/TLS and without the need to open and listen on different ports.

Network encryption is of prime importance to you if you are considering moving your databases to the cloud.

Related articles.


All configuration is done in the "sqlnet.ora" files on the client and server. The server side configuration parameters are as follows.


The server can also be considered a client if it is making client calls, so you may want to include the client settings if appropriate.

The client side configuration parameters are as follows.


The possible values for the SQLNET.ENCRYPTION_[SERVER|CLIENT] parameters are as follows.

The combination of the client and server settings will determine if encryption is used, not used or the connection is rejected, as described in the encryption negotiations matrix here.

The SQLNET.ENCRYPTION_TYPES_[SERVER|CLIENT] parameters accept a comma-separated list of encryption algorithms. Available algorithms are listed here. If no encryption type is set, all available encryption algorithms are considered.


As you can see from the encryption negotiations matrix, there are many combinations that are possible. Here are a few to give you a feel for what is possible.

If we require AES256 encryption on all connections to the server, we would add the following to the server side "sqlnet.ora" file. The client does not need to be altered as the default settings (ACCEPTED and no named encryption algorithm) will allow it to successfully negotiate a connection.


If we want to force encryption from a client, while not affecting any other connections to the server, we would add the following to the client "sqlnet.ora" file. The server does not need to be altered as the default settings (ACCEPTED and no named encryption algorithm) will allow it to successfully negotiate a connection.


If we would prefer clients to use encrypted connections to the server, but will accept non-encrypted connections, we would add the following to the server side "sqlnet.ora".



Changes to the contents of the "sqlnet.ora" files affect all connections made using that ORACLE_HOME. As a result, certain requirements may be difficult to guarantee without manually configuring TCP/IP and SSL/TLS. For example, imagine you need to make sure an individual client always uses encryption, whilst allowing other connections to the server to remain unencrypted. If you force encryption on the server you have gone against your requirement by affecting all other connections. You can force encryption for the specific client, but you can't guarantee someone won't change the "sqlnet.ora" settings on that client at a later time, therefore going against your requirement.

In such a case, it might be better to manually configure TCP/IP and SSL/TLS, as it allows you to guarantee how the connections on being handled on both sides and makes the point-to-point configuration explicit.

Data Integrity

The advanced security data integrity functionality is separate to network encryption, but it is often discussed in the same context and in the same sections of the manuals. The configuration is similar to that of network encryption, using the following parameters in the server and/or client "sqlnet.ora" files.

# Server

# Client

The SQLNET.CRYPTO_CHECKSUM_[SERVER|CLIENT] parameters have the same allowed values as the SQLNET.ENCRYPTION_[SERVER|CLIENT] parameters, with the same style of negotiations.

The SQLNET.CRYPTO_CHECKSUM_TYPES_[SERVER|CLIENT] parameters only accepts the SHA1 value prior to 12c. From 12c onward they also accept MD5, SHA1, SHA256, SHA384 and SHA512, with SHA256 being the default.

For more information see:

Hope this helps. Regards Tim...

Back to the Top.