Oracle Native Network Encryption
As I come across environments where SQL*Net is not encrypted I sometimes also notice that there are two common misconceptions about it:
- First, some are afraid that certificates must be involved and consequently maintaining a PKI infrastructure is deemed too complicated.
- Second, some are afraid of licensing issues, especially in respect to Standard Edition
Let me show you how none of those are true (certs certainly can be involved, but they're not necessary for simple setups).
License Requirements
To quote Database Licensing Information User Manual, Release 23:
Note: Network encryption (native network encryption, network data integrity, and SSL/TLS) and strong authentication services (Kerberos, PKI, and RADIUS) are no longer part of Oracle Advanced Security and are available in all licensed editions of all supported releases of Oracle Database.
I've also checked the same document for versions 19c and 12.1 and they both say the same thing.
Quick disclaimer: this blog simply reflects my understanding of Oracle's licensing documentation, so keep in mind that it is Oracle License Management Services (LMS) that always has the final authority regarding licensing matters.
That being said, it is also certainly a good idea to double check licensing restrictions when you hear about encryption or compression in regard to Standard Edition.
Server Configuration
So, let's setup Native Network Encryption as this is the simplest way of enabling encryption over SQL*Net. This method does not require any certificates and, in most cases, no client configuration. To enable it, we simply need to modify our sqlnet.ora file on the server. Like this:
SQLNET.ENCRYPTION_SERVER = REQUESTED
SQLNET.CRYPTO_CHECKSUM_SERVER = REQUESTED
Or maybe like this if we want to be really strict about it:
SQLNET.ENCRYPTION_SERVER = REQUIRED # default=ACCEPTED
SQLNET.ENCRYPTION_TYPES_SERVER = (AES256) # default=all available algorithms
SQLNET.CRYPTO_CHECKSUM_SERVER = REQUIRED # default=ACCEPTED
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA512) # default=all available algorithms
SQLNET.ALLOW_WEAK_CRYPTO_CLIENTS = FALSE # default=TRUE
Defaults for SQLNET.ENCRYPTION_SERVER and SQLNET.CRYPTO_CHECKSUM_SERVER is ACCEPTED. Which would mean that if a client REQUESTs or REQUIREs encryption then the server will be happy to encrypt the traffic. In our example though, as recommended for maximum security in official documentation, we only allow to establish encrypted connections, thus we specified REQUIRED. This is also why client configuration is not required in most cases: client also has default value for those parameters as ACCEPTED.
SQLNET.ALLOW_WEAK_CRYPTO_CLIENTS is more of a backward compatibility setting. If you need to support older clients then you may probably need to keep it on default value (TRUE).
Regarding algorithms, there is not much choice really. On 19c, there is AES for encryption and SHA for checksum. You can only require specific key lengths (e.g AES256) and hash sizes (e.g. SHA512). Well, to be exact, there are other algorithms (RC4, 3DES) supported, but they're also deprecated.
That's really, in essence, all there is to it.
Client Configuration
Same settings can be used on client, just replace _SERVER with _CLIENT. So, if you're only in control of the client, you can still have connection encrypted, even if your DBA did not touch the sqlnet.ora file. Simply set SQLNET.ENCRYPTION_CLIENT and SQLNET.CRYPTO_CHECKSUM_CLIENT to either REQUESTED or REQUIRED.
Is it Working?
Hackers will of course want to use tcpdump/Wireshark or similar to make it sure, but most of those people probably aren't reading this blog post as they already have some kind of encryption in place. For DBAs who trust performance views, you can simply do a following query:
SELECT network_service_banner
FROM v$session_connect_info
WHERE sid=sys_context('userenv','sid');
If enabled, you'll see (among other rows) those two:
NETWORK_SERVICE_BANNER
------------------------------------------------------------------------------------------
...
AES256 Encryption service adapter for Linux: Version 19.0.1.0.0 - Production
SHA1 Crypto-checksumming service adapter for Linux: Version 19.0.1.0.0 - Production
...
What About Certificates?
... What you seek is called Transport Layer Security (TLS) and it can be configured so that either only server has a certificate or both (client+server). You can also authenticate clients (and servers) this way.
As I prefer to keep my blog posts concise and on-topic, I'll only provide a link to the documentation instead of discussing TLS in this post.