Many organizations go through auditing, and have to meet auditing compliance policies that require data to be encrypted over the network from application servers to the database server. Oracle Database provides two types of network security encryption methods: native network encryption (NNE) and Secure Sockets Layer (SSL). Amazon RDS for Oracle supports both types of encryption for all editions of Oracle Database.
In this post, we describe various configurations options for using NNE and a crypto checksum server. We also demonstrate validating NNE application connectivity.
NNE with Amazon RDS for Oracle
NNE gives you the ability to encrypt database connections over the network. It’s one of the simplest ways to set up network encryption between your applications servers and Oracle Database server. You set it up using the option group on the RDS for Oracle instance.
The following table compares NNE to the SSL encryption method:
Easy to configure
Moderately easy to configure
Can use existing listener and doesn’t require a new port
Setup requires a separate database port and a listener
Setup doesn’t require a database wallet
Setup requires a client and server database wallet, in which the database server wallet is fully managed by Amazon RDS
No client setup is required, flexibility exists for choosing the encrypting algorithm
Requires a client setup such as wallet and certificate configurations
Supports encryption algorithms AES, RC4, and 3DES
Supports encryption algorithms AES, RC4, and 3DES
Amazon RDS uses the following default list of encryption algorithms from Oracle. You can limit the algorithms that the DB instance accepts in the option group settings for SQLNET.ENCRYPTION_TYPES_SERVER and SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER. You can specify either one value or a comma-separated list of values based on your requirement. The DB instance uses each algorithm, in order, to attempt to decrypt the client input until an algorithm succeeds or until the end of the list is reached.
Some examples of strongest industry-tested and accepted algorithms for encryption include AES (128 bits and higher) and RC4 (256 bits and higher). AES and RC4 are both symmetric encryption algorithms and are the most commonly used in industries like wireless communications, finance, web security, and VPN. Both algorithms use a single key to encrypt and decrypt the data and are also used for applications for which a large amount of data needs to be encrypted.
Based on your compliance and auditing requirements, you can choose any of the listed algorithms depending on your compliance requirements. To set up NNE on Amazon RDS for Oracle, see NNE option settings.
RC4_256: RSA RC4 (256-bit key size)
AES256: AES (256-bit key size)
AES192: AES (192-bit key size)
3DES168: 3-key Triple-DES (112-bit effective key size)
RC4_128: RSA RC4 (128-bit key size)
AES128: AES (128-bit key size)
3DES112: 2-key Triple-DES (80-bit effective key size)
RC4_56: RSA RC4 (56-bit key size)
DES: Standard DES (56-bit key size)
RC4_40: RSA RC4 (40-bit key size)
DES40: DES40 (40-bit key size)
If you need to use a specific encryption algorithm like AES256, you can set up the encryption by adding the AES256 value to the SQLNET.ENCRYPTION_TYPES_CLIENT parameter in the Oracle client sqlnet.ora file, as in the following code:
The following output shows the AES256 encryption service used as specified on the client server:
If you don’t have any encryption set up in your RDS for Oracle databases, the data isn’t encrypted as it moves to and from a DB instance.
To verify if NNE isn’t enabled, run the following SQL query from the client. The output Encryption service for Linux and Crypto-checksumming service for Linux indicate the capabilities of the client but don’t indicate encryption is enabled.
You can enable tracing on the client side in the sqlnet.ora file, to verify if encryption is enabled or not. The following sample output of the trace file shows no encryption is enabled.
Because encryption isn’t enabled, the data isn’t encrypted and therefore the query and its output (see the following code) are visible over the network.
If you have encryption set up in your RDS for Oracle instance, the data is encrypted as it moves to and from a DB instance. In the following scenario, NNE is enabled, so when you run the following SQL query from the client side, you can observe that the database is using the selected encryption algorithm to encrypt the data and the checksum algorithm to checksum the data.
If the specified value is set to REQUIRED for SQLNET.CRYPTO_CHECKSUM_SERVER and SQLNET.ENCRYPTION_SERVER, the client or server only accept encrypted traffic.
After you enable the NNE option on the Oracle for RDS database, you can run the following query to validate the encryption to and from the RDS for Oracle database:
The following output shows that the encryption is using the RC4_256 encryption algorithm, and crypto checksum is using the SHA1 algorithm to checksum.
In the trace file generated on the client, encryption and crypto checksum are active:
Because the encryption is enabled, the data is also encrypted, and therefore the query and its output (see the following code) is not visible over the network.
Common connection issues
Sometimes, the DB instance rejects a connection request from an application, for example, if a mismatch occurs between the encryption algorithms on the client and the server, or if the client and server have invalid settings. The combination of the client and server settings determines whether encryption is used or not, or whether the connection is rejected.
For example, if the client sqlnet.ora file has the SQLNET.ENCRYPTION_CLIENT=REJECTED parameter and the RDS for Oracle DB instance option group has SQLNET.ENCRYPTION_SERVER =REQUIRED, the connection to the client is rejected with the following error:
This post discussed NNE configuration and its applicable settings on the client side as well as on RDS for Oracle instances. For more information, see Oracle native network encryption.
Try this approach in your environment and see the benefits. We hope this post helps you with your NNE configuration.
About the authors
Jeevith Anumalla is an Oracle Database Cloud Architect with the Professional Services team at Amazon Web Services. He works as database migration specialist to help internal and external Amazon customers to move their on-premises database environment to AWS data stores.
Sagar Patel Sagar Patel is a Senior Database Specialty Architect with the Professional Services team at Amazon Web Services. He works as a database migration specialist to provide technical guidance and help Amazon customers to migrate their on-premises databases to AWS.
Read MoreAWS Database Blog