Algorithm preference in SQLNET.ENCRYPTION_TYPES_SERVER

If you have clients connecting to a server and the clients don't specify a specific encryption algorithm in SQLNET.ENCRYPTION_TYPES_CLIENT, be aware that the order of the algorithms listed in SQLNET.ORA on the server side matters...

If you don't specify SQLNET.ENCRYPTION_TYPES_CLIENT from a 12.2 client configuration, a SQLNet client side trace shows the following possibilities, the choices are listed from most secure to least secure:

(3775811968) [04-OCT-2018 19:47:44:284] nam_gic: Counting # of items in "SQLNET.ENCRYPTION_TYPES_CLIENT" parameter
(3775811968) [04-OCT-2018 19:47:44:284] nam_gic: Parameter not found
(3775811968) [04-OCT-2018 19:47:44:284] nam_gic: exit
(3775811968) [04-OCT-2018 19:47:44:284] naesno: Using default value "all available algorithms"
(3775811968) [04-OCT-2018 19:47:44:284] naeshow: entry
(3775811968) [04-OCT-2018 19:47:44:284] naeshow: These are the encryption algorithms that the client will accept:
(3775811968) [04-OCT-2018 19:47:44:284] naeshow: Choice 0: no algorithm; encryption inactive
(3775811968) [04-OCT-2018 19:47:44:284] naeshow: Choice 1: 'AES256' (ID 17)
(3775811968) [04-OCT-2018 19:47:44:284] naeshow: Choice 2: 'RC4_256' (ID 6)
(3775811968) [04-OCT-2018 19:47:44:284] naeshow: Choice 3: 'AES192' (ID 16)
(3775811968) [04-OCT-2018 19:47:44:284] naeshow: Choice 4: '3DES168' (ID 12)
(3775811968) [04-OCT-2018 19:47:44:284] naeshow: Choice 5: 'AES128' (ID 15)
(3775811968) [04-OCT-2018 19:47:44:284] naeshow: Choice 6: 'RC4_128' (ID 10)
(3775811968) [04-OCT-2018 19:47:44:284] naeshow: Choice 7: '3DES112' (ID 11)
(3775811968) [04-OCT-2018 19:47:44:284] naeshow: Choice 8: 'RC4_56' (ID 8)
(3775811968) [04-OCT-2018 19:47:44:284] naeshow: Choice 9: 'DES' (ID 2)
(3775811968) [04-OCT-2018 19:47:44:284] naeshow: Choice 10: 'RC4_40' (ID 1)
(3775811968) [04-OCT-2018 19:47:44:284] naeshow: Choice 11: 'DES40' (ID 3)

What is not clear is how the Client choice vs Server choice will be resolved. I did not find a clear description of this negotiation if the client side preference was not specified in SQLNET.ENCRYPTION_TYPES_CLIENT.

The negotiation is directed by the server and the order of the choices in SQLNET.ENCRYPTION_TYPES_SERVER matters. Here is the result of a negotiation with the server SQLNET.ORA configured two different ways:

1) SQLNET.ORA has 3DES168 first in ENCRYPTION_TYPES_SERVER parameter:

SQLNET.ENCRYPTION_SERVER = required
SQLNET.ENCRYPTION_TYPES_SERVER= (3DES168, AES256)

SQLNet trace output:

(2557825408) [04-OCT-2018 19:42:13:988] naeecom: The server chose the '3DES168' encryption algorithm

2) SQLNET.ORA has AES356 first in ENCRYPTION_TYPES_SERVER parameter:

SQLNET.ENCRYPTION_SERVER = required
SQLNET.ENCRYPTION_TYPES_SERVER= (AES256, 3DES168)

SQLPLUS connection made, no preference for encryption algorithm supplied.

SQLNet trace output:

(3775811968) [04-OCT-2018 19:47:44:470] naeecom: The server chose the 'AES256' encryption algorithm

Note: You may also be able to review connection details using the following query:

select NETWORK_SERVICE_BANNER from v$session_connect_info where SID = sys_context('USERENV','SID');
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
SHA256 Crypto-checksumming service adapter for Linux: Version 12.2.0.1.0 - Production

Why does this matter?
In my case this matters because of the performance of the algorithms. I had been trying to root out a customer's performance issue after switching to Encrypted network connections. After searching for algorithm benchmarks I found the following paper which compared AES and 3DES168, the two algorithms that I was dealing with in my own issue. Performance Analysis of the Encryption Algorithms
as Solution to Cloud Database Security
The paper showed a significanct performance penalty picking 3DES168 over AES.

References:

Add new comment