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

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

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.


Add new comment