Validate Native Network Encryption on Amazon RDS for Oracle

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 Relational Database Service (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:

NNE	SSL
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:

# cat /usr/lib/oracle/19.6/client64/lib/network/admin/sqlnet.ora
SQLNET.ENCRYPTION_TYPES_CLIENT=AES256

The following output shows the AES256 encryption service used as specified on the client server:

SQL> select network_service_banner from v$session_connect_info where sid in (select distinct sid from v$mystat);

NETWORK_SERVICE_BANNER
----------------------------------------------------------------------------
TCP/IP NT Protocol Adapter for Linux: Version 12.2.0.1.0 - Production
Encryption service for Linux: Version 12.2.0.1.0 - Production
AES256 Encryption service adapter for Linux: Version 12.2.0.1.0 - Production
Crypto-checksumming service for Linux: Version 12.2.0.1.0 - Production
SHA1 Crypto-checksumming service adapter for Linux: Version 12.2.0.1.0 – Production

NNE disabled

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.

SQL> select network_service_banner from v$session_connect_info where sid in (select distinct sid from v$mystat);

NETWORK_SERVICE_BANNER
--------------------------------------------------------------------------------
TCP/IP NT Protocol Adapter for Linux: Version 12.2.0.1.0 - Production
Encryption service for Linux: Version 12.2.0.1.0 - Production
Crypto-checksumming service for Linux: Version 12.2.0.1.0 - Production

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.

(1011145792) [24-FEB-2021 23:09:46:533] na_tns:         Authentication is not active
(1011145792) [24-FEB-2021 23:09:46:533] na_tns:         Encryption is not active
(1011145792) [24-FEB-2021 23:09:46:533] na_tns:         Crypto-checksumming is not active

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.

(1011145792) [24-FEB-2021 23:10:48:897] nsbasic_bsd: 6A 73 65 6C 65 63 74 20  |select.|
(1011145792) [24-FEB-2021 23:10:48:897] nsbasic_bsd: 6E 65 74 77 6F 72 6B 5F  |network_|
(1011145792) [24-FEB-2021 23:10:48:897] nsbasic_bsd: 73 65 72 76 69 63 65 5F  |service_|
(1011145792) [24-FEB-2021 23:10:48:897] nsbasic_bsd: 62 61 6E 6E 65 72 20 66  |banner.f|
(1011145792) [24-FEB-2021 23:10:48:897] nsbasic_bsd: 72 6F 6D 20 76 24 73 65  |rom.v$se|
(1011145792) [24-FEB-2021 23:10:48:897] nsbasic_bsd: 73 73 69 6F 6E 5F 63 6F  |ssion_co|
(1011145792) [24-FEB-2021 23:10:48:897] nsbasic_bsd: 6E 6E 65 63 74 5F 69 6E  |nnect_in|
(1011145792) [24-FEB-2021 23:10:48:897] nsbasic_bsd: 66 6F 20 77 68 65 72 65  |fo.where|

(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: packet dump
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 00 00 01 71 06 00 00 00  |...q....|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 00 00 06 01 02 00 01 00  |........|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 00 00 00 00 0F 00 00 00  |........|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 00 00 00 00 00 00 00 00  |........|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 00 00 00 00 00 00 00 00  |........|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 6D 2B 00 00 00 00 00 00  |m+......|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 00 00 00 00 00 00 11 0C  |........|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 6D 2B 00 00 07 3D 45 6E  |m+...=En|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 63 72 79 70 74 69 6F 6E  |cryption|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 20 73 65 72 76 69 63 65  |.service|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 20 66 6F 72 20 4C 69 6E  |.for.Lin|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 75 78 3A 20 56 65 72 73  |ux:.Vers|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 69 6F 6E 20 31 32 2E 32  |ion.12.2|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 2E 30 2E 31 2E 30 20 2D  |.0.1.0.-|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 20 50 72 6F 64 75 63 74  |.Product|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 69 6F 6E 15 01 00 01 07  |ion.....|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 46 43 72 79 70 74 6F 2D  |FCrypto-|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 63 68 65 63 6B 73 75 6D  |checksum|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 6D 69 6E 67 20 73 65 72  |ming.ser|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 76 69 63 65 20 66 6F 72  |vice.for|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 20 4C 69 6E 75 78 3A 20  |.Linux:.|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 56 65 72 73 69 6F 6E 20  |Version.|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 31 32 2E 32 2E 30 2E 31  |12.2.0.1|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 2E 30 20 2D 20 50 72 6F  |.0.-.Pro|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 64 75 63 74 69 6F 6E 04  |duction.|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 01 00 00 00 0F 00 01 03  |........|
(1011145792) [24-FEB-2021 23:10:48:938] nsbasic_brc: 00 00 00 7B 05 00 00 00  |...{....|

NNE enabled

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:

select network_service_banner from v$session_connect_info where sid in (select distinct sid from v$mystat);

The following output shows that the encryption is using the RC4_256 encryption algorithm, and crypto checksum is using the SHA1 algorithm to checksum.

 NETWORK_SERVICE_BANNER
--------------------------------------------------------------------------------
TCP/IP NT Protocol Adapter for Linux: Version 12.2.0.1.0 - Production
Encryption service for Linux: Version 12.2.0.1.0 - Production
RC4_256 Encryption service adapter for Linux: Version 12.2.0.1.0 - Production
Crypto-checksumming service for Linux: Version 12.2.0.1.0 - Production
SHA1 Crypto-checksumming service adapter for Linux: Version 12.2.0.1.0 - Production

In the trace file generated on the client, encryption and crypto checksum are active:

(709868608) [26-FEB-2021 17:33:43:807] na_tns: Secure Network Services is available.
(709868608) [26-FEB-2021 17:33:43:807] nau_adi: entry
(709868608) [26-FEB-2021 17:33:43:807] nau_adi: exit
(709868608) [26-FEB-2021 17:33:43:807] na_tns:  Authentication is not active
(709868608) [26-FEB-2021 17:33:43:807] na_tns:  Encryption is active, using RC4_256
(709868608) [26-FEB-2021 17:33:43:807] na_tns:  Crypto-checksumming is active, using SHA1
(709868608) [26-FEB-2021 17:33:43:807] na_tns: exit

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.

(709868608) [26-FEB-2021 17:33:43:892] nspsend: packet dump
(709868608) [26-FEB-2021 17:33:43:892] nspsend: 00 00 00 6A 06 20 00 00  |...j....|
(709868608) [26-FEB-2021 17:33:43:892] nspsend: 00 00 5B 21 75 35 59 6A  |..[!u5Yj|
(709868608) [26-FEB-2021 17:33:43:892] nspsend: 76 2C 5D 1C 53 D4 EA 8D  |v,].S...|
(709868608) [26-FEB-2021 17:33:43:892] nspsend: 80 5F 63 7B B4 C0 3C 49  |._c{..<I|
(709868608) [26-FEB-2021 17:33:43:892] nspsend: DE D8 74 A2 CC A4 77 FA  |..t...w.|
(709868608) [26-FEB-2021 17:33:43:892] nspsend: 26 41 54 FB D2 CE 21 D2  |&AT...!.|
(709868608) [26-FEB-2021 17:33:43:892] nspsend: 66 B1 43 56 56 8E 9B 52  |f.CVV..R|
(709868608) [26-FEB-2021 17:33:43:892] nspsend: 5E 35 8D 38 F7 0D 64 88  |^5.8..d.|
(709868608) [26-FEB-2021 17:33:43:892] nspsend: 44 E5 73 22 D2 CF 54 8D  |D.s"..T.|
(709868608) [26-FEB-2021 17:33:43:892] nspsend: 7D 43 94 A5 56 B2 95 1A  |}C..V...|
(709868608) [26-FEB-2021 17:33:43:892] nspsend: FC 50 A0 0B 75 5B CE 73  |.P..u[.s|
(709868608) [26-FEB-2021 17:33:43:892] nspsend: D1 99 D1 B1 0D 8D F6 2E  |........|
(709868608) [26-FEB-2021 17:33:43:892] nspsend: 58 C7 62 B1 CA 26 F9 FD  |X.b..&..|
(709868608) [26-FEB-2021 17:33:43:892] nspsend: 00 00                    |..      |
(709868608) [26-FEB-2021 17:33:43:892] nspsend: 106 bytes to transport
(709868608) [26-FEB-2021 17:33:43:892] nspsend: normal exit
(709868608) [26-FEB-2021 17:33:43:892] nsdofls: exit (0)

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:

 # cat sqlnet.ora 
SQLNET.ENCRYPTION_CLIENT=REJECTED

$ sqlplus admin@rdsdb
SQL*Plus: Release 19.0.0.0.0 - Production on Fri Feb 26 20:27:21 2021
Version 19.6.0.0.0
Copyright (c) 1982, 2019, Oracle.  All rights reserved.
ERROR:
ORA-12660: Encryption or crypto-checksumming parameters incompatible

Summary

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.

AWS Database Blog