A few years back I was pulled into a review after an internal pen test flagged something embarrassing: TDE was configured beautifully — AES256, wallet backed up, master key rotated on schedule, the works — and the traffic between the app servers and the database was still going out in plain text. Anyone on that VLAN with a laptop and Wireshark could have read query results scrolling by like a ticker tape. The database itself was locked down tight. The wire wasn’t.
That’s the thing about TDE — it’s an easy feature to sell to management because “we encrypt data at rest” sounds complete. It isn’t. Data doesn’t sit still. It moves constantly, between app tier and database, between middleware and clients, and if that movement happens over an unencrypted network, TDE is only doing half the job it’s credited with.
This is about the other half — Native Network Encryption (NNE) and SSL/TLS, how sqlnet.ora decides what happens on the wire, and how the SSL handshake gets two systems to trust each other before any real data changes hands.
Why Encrypt Data in Transit at All?
Say an application sends something like “We will go public on Wednesday” over to the database. Nothing fancy, just a normal write.
Unencrypted, it goes out exactly like that:
Whoever’s capturing packets on that segment reads it the same moment it arrives. No decryption needed, no effort required — it’s just sitting there.
Turn encryption on and the same message becomes noise to everyone except the database on the other end:
Same sentence, same destination, completely different outcome if someone’s listening.
Three Things Oracle Is Actually Trying to Protect
I usually break this down into three goals, mostly because people tend to conflate the first two and it causes confusion later.
Confidentiality is about keeping the content private — nobody unauthorized gets to read it.
Data integrity is a different problem entirely. It’s not about who can see the data, it’s about whether the data that arrives is exactly what was sent. Oracle checks for that.
And authentication is the third leg — proving both sides are who they claim to be before anything sensitive gets exchanged. You can have confidentiality without authentication, which, frankly, is a weaker position than most people realize.
What’s on the Menu, Algorithm-Wise
| Algorithm | Description |
|---|---|
| DES | Data Encryption Standard |
| 3DES | Triple DES |
| AES128 | Advanced Encryption Standard |
| AES192 | Advanced Encryption Standard |
| AES256 | Advanced Encryption Standard |
| RSA | Public Key Cryptography |
DES and 3DES are still technically on the list, and technically supported doesn’t mean you should touch them. If I see either one configured on a system I’m reviewing, that’s usually the first thing that goes in my findings report. AES256 is where I land by default — faster and stronger than the legacy options, and there’s rarely a real reason to pick anything else.
Quick aside on why AES works the way it does: it’s symmetric, meaning the same key handles both directions.
One key, both jobs. That simplicity is exactly why it’s fast enough to sit in front of every packet without anyone noticing a performance hit.
Native Network Encryption — the Quiet Workhorse
NNE covers traffic between Oracle clients, the database, JDBC apps, middleware — basically anything speaking Oracle Net. You get encryption, integrity checking, and secure Oracle Net communication, and none of it touches a line of application code. It just works underneath everything.
Every outbound packet gets encrypted client-side before it ever touches the wire:
Only the database on the receiving end can actually decrypt it.
sqlnet.ora Is Where All This Gets Decided
Both sides — client and server — get their own settings in sqlnet.ora.
Server:
SQLNET.ENCRYPTION_SERVER
SQLNET.ENCRYPTION_TYPES_SERVER
Client:
SQLNET.ENCRYPTION_CLIENT
SQLNET.ENCRYPTION_TYPES_CLIENT
Between them, these decide whether encryption’s off, optional, preferred, or flat-out required.
There are four modes to know:
| Mode | Description |
|---|---|
| ACCEPTED | Allowed, not insisted on |
| REJECTED | Off |
| REQUESTED | Preferred |
| REQUIRED | Mandatory |
Here’s roughly what I’d actually put in front of a production system:
Server:
SQLNET.ENCRYPTION_SERVER=REQUIRED
SQLNET.ENCRYPTION_TYPES_SERVER=(AES256)
Client:
SQLNET.ENCRYPTION_CLIENT=REQUESTED
SQLNET.ENCRYPTION_TYPES_CLIENT=(AES256)
That combination gets you AES256 on essentially every connection without a lot of drama.
So what happens if the two sides just don’t agree? Say the server’s REQUIRED and some client comes in REJECTED —
❌ Connection Refused
— and that’s it, the connection dies right there. I know that sounds harsh, and I’ve had application teams complain about it more than once. But I’d rather field a connectivity ticket than discover six months later that a “secured” link had been running in plain text the entire time because Oracle quietly downgraded instead of refusing. Failing loudly here is a feature, not a bug.
Integrity Checking Isn’t the Same Thing as Encryption
Worth separating these mentally: encryption is about privacy, integrity checking is about tampering. Oracle can generate a checksum for every packet, and if a single byte changes somewhere along the path, the packet gets rejected rather than silently accepted.
And you can flip integrity checking on independently of encryption — they share a neighborhood but they’re not the same switch.
Then There’s SSL/TLS
SSL, and its modern replacement TLS, does everything NNE does but adds one thing NNE can’t — real authentication, backed by certificates rather than just a shared secret.
Wallets Hold the Certificates
Each side keeps its certificate tucked inside an Oracle Wallet:
A certificate works like an ID card — it’s how one side proves to the other that it is who it says it is.
Somebody Has to Vouch for Everyone — Enter the CA
A Certificate Authority is that trusted third party. It issues certificates to users, databases, app servers, web servers, whatever needs one. And because client and server both already trust the same CA, they end up trusting each other by extension, even without having “met” before.
The Handshake, Step by Step
Before any actual data moves, trust gets built first:
Nothing else happens until both certificates pass validation.
Written out plainly, it’s five steps: the client asks for a secure connection, sends its own certificate, the server checks that against the CA, the server sends its certificate back, and the client verifies that one too. Clear all five and you’ve got yourself a secure session.
Once that’s done, both sides pick an encryption algorithm, generate session keys, start encrypting traffic, and integrity checking kicks in automatically — all before either side has sent a single byte of actual application data.
Side by Side: NNE vs. SSL/TLS
| Feature | Native Network Encryption | SSL/TLS |
|---|---|---|
| Encrypts Network Traffic | Yes | Yes |
| Data Integrity | Yes | Yes |
| Client Authentication | No | Yes |
| Server Authentication | No | Yes |
| Uses Certificates | No | Yes |
| Uses Oracle Wallet | Optional | Required |
I tell junior DBAs it this way: NNE is the quick option — fast to configure, covers confidentiality and integrity, doesn’t prove identity on either end. SSL/TLS costs more upfront — wallets, certs, a CA relationship to manage — but buys you mutual authentication, which matters a great deal more once you can’t just assume the network in between is friendly.
Best Practices, the Short List
- Default to AES256 everywhere it’s supported
- Set
SQLNET.ENCRYPTION_SERVER=REQUIREDin production, full stop - Turn integrity checking on alongside encryption, not instead of it
- Bring in SSL/TLS wherever mutual authentication actually matters
- Keep certificates inside properly secured Oracle Wallets
- Only pull certificates from a CA your organization genuinely trusts
- Watch certificate expiration dates and renew early
- Test client/server encryption compatibility before go-live, never after
Where This Leaves You
TDE handles data at rest. NNE and SSL/TLS handle the same data while it’s actually moving — which, if you think about it, is most of its life. Get sqlnet.ora set correctly, standardize on AES256, and bring SSL/TLS into the picture wherever authentication genuinely matters, and you’ve closed the exact gap that pen test caught me on all those years ago. The disk was never the problem. The wire was.
