8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | 23c | Misc | PL/SQL | SQL | RAC | WebLogic | Linux
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.
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.
ACCEPTED: The client or server will allow both encrypted and non-encrypted connections. This is the default if the parameter is not set.
REJECTED: The client or server will refuse encrypted traffic.
REQUESTED: The client or server will request encrypted traffic if it is possible, but will accept non-encrypted traffic if encryption is not possible.
REQUIRED: The client or server will only accept encrypted traffic.
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.
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.
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 SQLNET.CRYPTO_CHECKSUM_SERVER SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER # Client SQLNET.CRYPTO_CHECKSUM_CLIENT SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT
SQLNET.CRYPTO_CHECKSUM_[SERVER|CLIENT] parameters have the same allowed values as the
SQLNET.ENCRYPTION_[SERVER|CLIENT] parameters, with the same style of negotiations.
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:
- Configuring Network Data Encryption and Integrity for Oracle Servers and Clients
- Configuration of TCP/IP with SSL and TLS for Database Connections
Hope this helps. Regards Tim...