Gunther Oracle APEX und Datenbank Wiki

Aufgabe: Symmetrische Verschlüsselung der SQL*Net Verbindung im der 23ai / 19c mit der Oracle Native Network Encryption (NNE) sicherstellen.

Neben der reinen Verschlüsselung kann auch über einen Checksum-Algorithmus wie SH-1 sichergestellt werden, das die Daten unterwegs nicht manipuliert wurden.

Wie verhält sich eine 23ai wenn die Umgebung nicht konfiguriert ist? Was ist der Default?

Anmelden und über V$SESSION_CONNECT_INFO prüfen was der Default ist:

#Powershell
set-item -path env:TNS_ADMIN -VALUE C:\oracle\TNS_ADMIN\
cd C:\oracle\product\23\instantclient_23_5
./sqlplus gpi/oracle@GPIDB_23ai
 
 
SELECT *   FROM V$SESSION_CONNECT_INFO WHERE osuser='GuntherPipperr' 
 
                                NETWORK_SERVICE_BANNER  
                                --------------------------------    
DATABASE	GuntherPipperr	TCP/IP NT Protocol Adapter FOR Linux: Version 23.0.0.0.0 - Production	US7ASCII	Heterogeneous	FULL Instant Client	23.5.0.24.07	SQL*PLUS
DATABASE	GuntherPipperr	Encryption service FOR Linux: Version 23.0.0.0.0 - Production	        US7ASCII	Heterogeneous	FULL Instant Client	23.5.0.24.07	SQL*PLUS
DATABASE	GuntherPipperr	Crypto-checksumming service FOR Linux: Version 23.0.0.0.0 - Production	US7ASCII	Heterogeneous	FULL Instant Client	23.5.0.24.07	SQL*PLUS

⇒ Kein Verschlüsselung im Default aktiv!

Für 12c und früher siehe auch ⇒ Das SQL*Net Protokoll mit einer symmetrischen Verschlüsselung wie DES / AES oder RC4 schützen.

23ai ist ja aktuell noch sehr wenig im echten Einsatz (März 2025), aber das Thema Kompatibilität ist gerade bei der Verschlüsselung ein wichtiger Aspekt.

Im Support Portal findet sich dazu dieses Dokumente ⇒ „Client / Server Interoperability Support Matrix for Different Oracle Versions (Doc ID 207303.1)“

Hier ist die Aussage so, das NUR 19c/21c/23c/23ai Clients mit der 23ai zertifiziert zusammen arbeiten können!

In der Datenbank Version 19 ist noch 11.2 / 12.1 / 12.2/ 18 etwas unterstützt und der 23iger Client!

Siehe dazu auch „Oracle Database (RDBMS) Releases Support Status Summary (Doc ID 161818.1)“ und für die Zukunft „Release Schedule of Current Database Releases (Doc ID 742060.1)“ im Support Portal.

Die Verschlüsselung des SQL*Netwerk Protokolls war ein Teil der Secure Network Services (SNS) (vor 8i) bzw. Oracle Advanced Security ab (8i - 11g R1).

Ab 11g R2 (Mitte 2013) wurde die Optionen für alle DB Editionen freigegeben und ist nicht mehr Teil der DB EE Optionen.

Aus dem Lizenz Guide der 23ai unter https://docs.oracle.com/en/database/oracle/oracle-database/23/dblic/Licensing-Information.html 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.

Es steht zur Verfügung laut Doku der 23ai:

• AES 256-bit key AES256
• AES 192-bit key AES192
• AES 128-bit key AES128

Überprüfen über den Server:

Auf einer Linux Maschine:
<code bash>
#Oracle Umgebung setzen:
export ORACLE_HOME=/opt/oracle/product/23ai/dbhomeFree
cd $ORACLE_HOME/bin
 
./adapters
No ntcontab.o! Goodbye...
 
./adapters tnslsnr
Oracle Net transport protocols linked with tnslsnr are:
Oracle Net naming methods linked with tnslsnr are:
Oracle Advanced Security options linked with tnslsnr are:

Klappt seltsamerweise auf meinen 23ai Umgebung (podman Container, Linux9 rpm Installation ) nicht. Bei 19c funktioniert das noch.

Entscheidungsgrundlagen:

• Performance / CPU Bedarf
• Legal Requirement wie die CIS Checklisten / PCI DSS Requirement 3 usw.
• Erreichter Sicherheitsgrad

Vergleich mit openssl:

openssl speed

Aus den Zahlen ist gar kein so großer Unterschied zwischen den Algorithmen zu erkenne, Default ist der AES 256-bit key AES256, da AES meist von der Hardware unterstützt wird, ist das dann der zu wählende Algorithmus.

Oracle verwendet das Advanced Encryption Standard (AES) symmetric cryptosystem (AES-256 als Standard).

Der AES-256 (Advanced Encryption Standard mit 256-Bit-Schlüssel) ist ein symmetrischer Verschlüsselungsalgorithmus, der Daten in 128-Bit-Blöcken ver- und entschlüsselt.

Da der AES-256 hardwarebeschleunigt berechnet werden kann (moderne CPUs unterstützen normalerweise direkt die AES-NI-Instruktionen, ist nicht mit größeren Einschränkungen im Betrieb zu rechnen.

Bei Verbindungen zu älteren Oracle-Versionen (z. B. 19c) kann dann auf AES-128/192 zurückfallen werden.

Für die Schlüsselvereinbarung verwendet Oracle das Diffie-Hellman (DH)-basierte Schlüsselvereinbarung um sichere Sitzungsschlüssel für die Datenübertragung auszuhandeln.

Durch diesen Schlüsselaustausch mit dem DH (bzw. der elliptische Kurvenvariante ECDH) wird ein gemeinsamer Sitzungsschlüssels ohne Übertragung der eigentlichen Schlüssel erzeugt.

Damit später mit mitgeschnittenen Daten nicht auf einen Schlüssel geschlossen werden kann wird mit Perfect Forward Secrecy (PFS) verhindert, dass kompromittierte Langzeitschlüssel vergangene Sitzungen entschlüsseln können.

„Man-in-the-Middle“ Attacken denkbar, z.B. durch einschalten eines Oracle CMAN ( Oracle 21c - SQL*Net Proxy und Firewall mit dem Oracle Connection Manager CMAN implementieren - Einsatz als Standby DB Proxy für ältere Java Apps in die Kommunikation.

Da ja keine Zertifikate zur Identifizierung der Gegenstelle im Einsatz ist, merkt das Protokoll an sich nicht, ob es auch mit dem richtigen Endpunkt verbunden ist.

Alternativ kann dann auf TLS (Transport Layer Security) gesetzt werden, hier in einer Anleitung für die 12c Oracle SQL*Net - SSL - Secure Sockets Layer - für SQL*Net aktivieren .

Beides lässt sich auch in der 23c kombinieren, siehe Doku ⇒ https://docs.oracle.com/en/database/oracle/oracle-database/23/dbseg/configuring-transport-layer-security-encryption.html

Die Verschlüsselung wird über die Datei „sqlnet.ora“ konfiguriert/aktiviert

Im ersten Test war ich der Meinung, das es ja reichen müsste nur den Client zu konfigurieren, der Server müsste das ja per Default können, das scheint aber nicht ausreichend zu sein!

SQLNET.ENCRYPTION_SERVER = REQUIRED
SQLNET.ENCRYPTION_TYPES_CLIENT = AES256

Test mit nur Client Konfiguration

#Powershell
set-item -path env:TNS_ADMIN -VALUE C:\oracle\TNS_ADMIN\
cd C:\oracle\product\23\instantclient_23_5
./sqlplus gpi/oracle@GPIDB_23ai
 
 
SELECT *   FROM V$SESSION_CONNECT_INFO WHERE osuser='GuntherPipperr' 
 
NETWORK_SERVICE_BANNER  
 --------------------------------    
TCP/IP NT Protocol Adapter FOR Linux: Version 23.0.0.0.0 - Production	US7ASCII	Heterogeneous	FULL Instant Client	23.5.0.24.07	SQL*PLUS
Encryption service FOR Linux: Version 23.0.0.0.0 - Production	        US7ASCII	Heterogeneous	FULL Instant Client	23.5.0.24.07	SQL*PLUS
Crypto-checksumming service FOR Linux: Version 23.0.0.0.0 - Production	US7ASCII	Heterogeneous	FULL Instant Client	23.5.0.24.07	SQL*PLUS

Nur der Client ist nicht ausreichend

Auf der Server Seite muss in der sqlnet.ora des Listeners (stets die sqlnet.ora im selben Verzeichnis wie die listener.ora) die Verschlüsselung aktiviert werden!

In einer Cluster Umgebung auf den richtigen Listener achten und auf allen Knoten auch die sqlnet.ora verteilen!

lsnrctl status
 
...
Listener Parameter File   /opt/oracle/product/23ai/dbhomeFree/network/admin/listener.ora
....

D.h. es muss die Sqlnet.ora unter „/opt/oracle/product/23ai/dbhomeFree/network/admin/“ in meiner Umgebung editiert werden.

sqlnet.ora

SQLNET.ENCRYPTION_CLIENT=required

So klappt es nicht, die Verbindung bleibt unverschlüsselt.

sqlnet.ora:

SQLNET.ENCRYPTION_SERVER=required
SQLNET.ENCRYPTION_TYPES_SERVER=(AES256,AES192)
SQLNET.CRYPTO_SEED = 'DiesIsteineLang!Chryp0toS33dalsBeiSp1el'

Empfehlenswert ist auch die Aktivierung einer Checksumme mit:

SQLNET.CRYPTO_CHECKSUM_SERVER       = [accepted | rejected | requested | required]
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (valid_crypto_checksum_algorithm [,valid_crypto_checksum_algorithm])

wie

SQLNET.CRYPTO_CHECKSUM_SERVER=required
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT=(SHA1)

Mögliche Werte:

• SHA1
• SHA256
• SHA384
• SHA512

Nach jeder Änderung der Werte Listener neu starten:

cd $ORACLE_HOME/bin
 
lsnrctl stop 
lsnrctl start
# Datenbank wieder anmelden, sonst dauert es etwas
sqlplus / as sysdba
alter system register
exit
 
./lsnrctl status

testen:

set-item -path env:TNS_ADMIN -value C:\oracle\TNS_ADMIN\
 
C:\oracle\product\23\instantclient_23_5> ./sqlplus sys@//10.10.10.118:1521/freepdb1 AS sysdba
 
SELECT NETWORK_SERVICE_BANNER   FROM V$SESSION_CONNECT_INFO where osuser='GuntherPipperr' 
 
NETWORK_SERVICE_BANNER   
-----------------------
TCP/IP NT Protocol Adapter for Linux: Version 23.0.0.0.0 - Production
Encryption service for Linux: Version 23.0.0.0.0 - Production
=> AES256 Encryption service adapter for Linux: Version 23.0.0.0.0 - Production
Crypto-checksumming service for Linux: Version 23.0.0.0.0 - Production
=>SHA256 Crypto-checksumming service adapter for Linux: Version 23.0.0.0.0 - Production

Wie verhält sich der „jdbcthin“ Treiber? Auf der Java Seite sind keine weiteren Parameter konfiguriert, die SQLnet.ora wird nicht verwendet.

Mit dem aktuellen Treibern kein Problem, allerdings ist es jetzt schwierig einen alten Treiber zu finden ….

Siehe dazu auch die Support Node „76629.1“ - Using and Verifying ASO encryption and Checksum with JDBC/thin (Doc ID 1377228.1).

Im der Client „sqlnet.ora“ den Paramter „SQLNET.ENCRYPTION_CLIENT=rejected“ setzen und testen:

sqlplus gpi/gpi@oragpi
 
..
ORA-12660: Encryption or crypto-checksumming parameters incompatible
...

Über die View gv$session_connect_info können die Netzwerk Eigenschaften der angemeldeten Sessions überprüft werden:

SELECT    s.inst_id
       ,  s.sid
       ,  s.serial#
       ,  s.status
       ,  s.username
       ,  s.machine
       ,  s.program
       ,  c.osuser
       ,  c.network_service_banner 
       ,  c.CLIENT_CHARSET
       ,  c.CLIENT_OCI_LIBRARY
       ,  c.AUTHENTICATION_TYPE
  FROM gv$session_connect_info c 
     , gv$session s 
 WHERE c.sid = s.sid 
   AND c.serial#=s.serial# 
   AND c.inst_id=s.inst_id
   AND s.username IS NOT NULL
  ORDER BY 1
/

Zum Schluss lässt sich leider nur über einen Trace echt feststellen, ob die Verschlüsselung auch funktioniert.

siehe Übersicht SQL*Net Probleme

Doku:

• https://docs.oracle.com/en/database/oracle/oracle-database/23/dbseg/part_4.html

Support:

• Native Encryption In Oracle Database (Doc ID 76629.1)