Stunnel Security for Oracle

To configure stunnel, the root user must create a keypair for TLS. This keypair can be "signed" by a Certificate Authority (CA) if desired—this is conventionally useful for Web site encryption (HTTPS) since the lack of a recognized CA signature will trigger browser security warnings. Oracle clients can verify server keys only when signed by a recognized CA, which is addressed in the final section of this article. To obtained signed keys, follow the instructions on the stunnel Web site. Otherwise, for more informal use, a self-signed key can be generated with the following commands:


cd /etc/pki/tls/certs
make stunnel.pem

The process of key generation will ask a number of questions:


Generating a 2048 bit RSA private key
....................................................................+++
.................................+++
writing new private key to '/tmp/openssl.hXP3gW'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name
or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:IL
Locality Name (eg, city) [Default City]:Chicago
Organization Name (eg, company) [Default Company Ltd]:ACME Corporation
Organizational Unit Name (eg, section) []:Widget Division
Common Name (eg, your name or your server's hostname) []:darkstar
Email Address []:linus@posix.org

The key produced above will be set for expiration in 365 days from the day it was created. If you would like to generate a key with a longer life, you can call OpenSSL directly:


openssl req -new -x509 -days 3650 -nodes \
        -out stunnel.pem -keyout stunnel.pem

The key will look something like this:


# cat /etc/pki/tls/certs/stunnel.pem
-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQC23m+w0BLxI2zB
/p8/TiuFcEurTLbLCQwcO/FE+vNcJpddckuF6/VgpBAJk+d9i7NZNqrjMH711H18
3AYhewZTCbRUMQE3ndaYEIxSt4Qhbm8XbfUfx6Fmg4CnWh/XzE7B8Z7XbHpwRQ4d
kQOzICzb1nt96QKdWoAob73+hv7qdi3UjJ3/20z3Cx5LWfWoa32Y50//tvBjBtcQ
H7QpiE2tfLWHTQ5tztkqVY/MZJWVgoT5LnqQlZeZB/C4izSYNo9EGAnw4ThaFJ/y
NdvmyK6sYaO3Dq4eFO78O+zzqyfhPCtcfb8lMuRTZa8uiv7ziVf0A3eGSwKYonUf
iL7su0kJAgMBAAECggEASyeDk5EQF9ZNPjUc0XGY5VBPaOkwPqVLOtdPwt+34Glj
z93HOBTPVZZXmPgWLTyaytFyzcgChZl8sTHjuyLKaJoWaHtzWp4dsYUrhlsxjGPM
eD6SfSsYI/9rglvBtnia7Y4Vj8dfUoCu2mvcr2NLzFWLjyWSE4U8ImI6HT7xyP1y
5Ab8JYX5C0qODTjjPldovz8Fm9XE7yKVg5XQ9aA8axq1uWY7ruzxXli/+h7TJLPe
v/yCCeKLqL+gSkORjhg8ZsK/9p6InMN6uFUeSvb0Y9eLnLnJ6tCUGh4m+cgXulrD
UleXxeFzxnS3ydCNHVDngXyaJ1U+bLGVeHOLRcZHAQKBgQDY5jU+rU8VPXrbPJae
fZ8swf3Pi00QUKN4P5Zyy5cs18KMgDRHRaUdYmVCpTISR7Wi0XHEI7iHDpKlL//k
zCT0LW+fk+4A7bP5yUhLLtd175RUpR3ieBuXbAZRqDaPMDJ1xpZj+hDiShPv+OGR
k7ETnBDm/zk1T+F2Lu6qebLbcQKBgQDX1b6I7eRDkyFZITZX1v+S6PkoTMQMeCGX
cSwVvuDuiszgbf7IImWvvFxd7h+WJZEVv4jV645LOsvkY6XyFXdW7iNJGkKgThg6
YNE3X5f1oGvo5E3+HNXS3vGs76YVKTraDd0SKIRT98m2jiXCVCw+KWlR5GR+xp2A
8exCoTYLGQKBgQDJdcmu1brGt7wNNlGQFI5sPCNLSs/hf4TWg/lx1rgr5pvFdK8a
JA4hJOt444eGgySqfm91Bti2WUrMM7EzCoqoYitzxSsjoaWxNMv5SSDHYigcFuGT
IIxAMQ4NenhytwmnazT016gnBzdNhZW+abfnxuXMKPMyGWgJJb54iWEfgQKBgQDV
N3xgfNHwx5o8GIk8wVH86VWqMBvETbCxkMWCPeyq+kdmtoLpZsGZl7SPvjtJ8paf
K3WcDnWlb9IYLzCyM+6O2/XTs7N59WwNz7MexrqxlebETTWXARlilYed1aj2YqKW
4vcvhwMiiDimtUor7Uc/qV033y4/5ymVRmilceiXkQKBgEbFhAKXP9qZMdfLevWp
VXAZCc5mQ2hxQOSQRAL5VvTUXm6ZwVXVf/U42JH3YXiVXbwDbEjjxS/8MtSbQU9z
LoVQ/+bvc3xQ08u8kxdQiWzTzwRxHJM/znxpoD9astItq4uWU58hCoUNItHEKGJt
60bczdu3rZLZIB1n2zSM6soF
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIID/TCCAuWgAwIBAgIJALT/9skCvdR5MA0GCSqGSIb3DQEBCwUAMIGUMQswCQYD
VQQGEwJVUzELMAkGA1UECAwCSUwxEDAOBgNVBAcMB0NoaWNhZ28xGTAXBgNVBAoM
EEFDTUUgQ29ycG9yYXRpb24xGDAWBgNVBAsMD1dpZGdldCBEaXZpc2lvbjERMA8G
A1UEAwwIZGFya3N0YXIxHjAcBgkqhkiG9w0BCQEWD2xpbnVzQHBvc2l4Lm9yZzAe
Fw0xNTEwMzAwMzI2NTJaFw0yNTEwMjcwMzI2NTJaMIGUMQswCQYDVQQGEwJVUzEL
MAkGA1UECAwCSUwxEDAOBgNVBAcMB0NoaWNhZ28xGTAXBgNVBAoMEEFDTUUgQ29y
cG9yYXRpb24xGDAWBgNVBAsMD1dpZGdldCBEaXZpc2lvbjERMA8GA1UEAwwIZGFy
a3N0YXIxHjAcBgkqhkiG9w0BCQEWD2xpbnVzQHBvc2l4Lm9yZzCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBALbeb7DQEvEjbMH+nz9OK4VwS6tMtssJDBw7
8UT681wml11yS4Xr9WCkEAmT532Ls1k2quMwfvXUfXzcBiF7BlMJtFQxATed1pgQ
jFK3hCFubxdt9R/HoWaDgKdaH9fMTsHxntdsenBFDh2RA7MgLNvWe33pAp1agChv
vf6G/up2LdSMnf/bTPcLHktZ9ahrfZjnT/+28GMG1xAftCmITa18tYdNDm3O2SpV
j8xklZWChPkuepCVl5kH8LiLNJg2j0QYCfDhOFoUn/I12+bIrqxho7cOrh4U7vw7
7POrJ+E8K1x9vyUy5FNlry6K/vOJV/QDd4ZLApiidR+Ivuy7SQkCAwEAAaNQME4w
HQYDVR0OBBYEFEgCdENJ+1y0STMyQtuz3uqDON3NMB8GA1UdIwQYMBaAFEgCdENJ
+1y0STMyQtuz3uqDON3NMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEB
AITW7cBNdWBcgagsinGKfyESBlJ7JvxvsMzYVhI8myC8ht/3nFMyTHmBgtmxdNbW
mCCzDdeSigQf/iEzH02k/EK7L7I3DATGBW6w9WiYBdqrZJl98CIxoY9j+GV0AeL1
INMSb5G4R2ygnekXVNTJsICeVHTRujBJsD4psZB5dhSI888rA2MrdQ8jAFGDk7Z4
VYckA2gQ+70yXXxpFSD4n2ecq3ebNtej07zR2wAtAkt/JtuGiUjbl1m4ZFTPoTwr
xDYMcezEgopMzYMihv6CQ0CEU+qL+92CYtEDsd1hzn74SlBK9HMKjMLrbBZPhbE4
/JMRW5oa/+TFZIRcacTxgAw=
-----END CERTIFICATE-----

The PRIVATE KEY section above is the most sensitive portion of the file; ensure that it is not seen or copied by anyone that you do not trust, and any recordings on backup media should be encrypted. The BEGIN CERTIFICATE section is presented to TLS clients (that is, sqlplus) when they connect to stunnel.

It is likely wise to compute custom primes for the Diffie-Hellman key exchange algorithm, following guidance from the stunnel manual page:


openssl dhparam 2048 >> stunnel.pem

The previous command will add another section to your stunnel.pem file for high-security Diffie-Hellman primes:


-----BEGIN DH PARAMETERS-----
MIIBCAKCAQEAoHi5jzY5ZVwGCFFm1EhVsePXxNwCSs/eQbaC3rc+iXENL8xk21uq
6eSwYIQWUeDN/h6wBBDe6dpFoNDJQeqKCmUa8aojGHnkcqsJBdVUKVF5/7rWb1Yi
TzvbeZt8UvYnNUErJEpgBMiKPDYipE2BZ6k61WwkK6WV6svGAHpIc3o/9kU+72uf
dPFaNIygAb2HLaJYvXq9OYGvrMsmyZTh3fnpg2RiZSVJf+i4BfyeLiYkwnSZozAS
2rQ4hf2E5WY6jiAcNZBLKvqR8lUuIaXd9+VkiCSV0c2pXzb2ElxOk8sheAHliwip
SaKC694z9l63eNKQW2J4WI97wkil0qa4MwIBAg==
-----END DH PARAMETERS-----

The Oracle TNS Listener conventionally runs at port 1521. In this exercise, let's run Oracle TLS services at port 1522, which has the current service name:


# grep 1522 /etc/services
ricardo-lm   1522/tcp      # Ricardo North America License
                           # Manager
ricardo-lm   1522/udp      # Ricardo North America License
                           # Manager

Place the following file to control stunnel for the "ricardo" service (alter the IP address 1.2.3.4 to the location of your TNS Listener):


# cat /etc/stunnel/ricardo.conf
sslVersion      =       TLSv1.2
        options =       NO_SSLv3
        options =       NO_SSLv2
        options =       SINGLE_DH_USE
        options =       SINGLE_ECDH_USE
        options =       CIPHER_SERVER_PREFERENCE
        cert    =       /etc/pki/tls/certs/stunnel.pem
        FIPS    =       no
        debug   =       6
        syslog  =       yes
        chroot  =       /var/empty
        setuid  =       nobody
        setgid  =       nobody
        connect =       1.2.3.4:1521

; best-practice ciphers:
; https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
ciphers=ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:
↪DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:
↪!aNULL:!MD5:!DSS

Note above that you are configuring TLS for best-practice encryption with the highest quality protocols and ciphers. The Oracle clients appear compatible with these settings. Note that Michal Trojnara, the author of stunnel, does "not recommend using DH ciphersuites in the hardened set. ECDH ciphersuites are much more secure and much faster - RFC 7525 should be considered outdated after the recent attacks on DH." On the other hand, there have been recent questions of software patents on Elliptic Curve, although Sun/Oracle contributed the ECC implementation in OpenSSL and used great care to avoid patented methods. Red Hat/Fedora went further in enabling only the Suite B subset of NIST ECC curves for protection from Certicom (whether this is a sufficient courtroom defense against CryptoPeak is another matter). Beyond that, in my previous coverage of the Stribika SSH Guide [see "Cipher Security: How to Harden TLS and SSH" by Charles Fisher, September 2015], I wrote that the author is "...advising against the use of NIST elliptic curves because they are notoriously hard to implement correctly. So much so, that I wonder if it's intentional. Any simple implementation will seem to work but leak secrets through side channels. Disabling them doesn't seem to cause a problem; clients either have Curve25519 too, or they have good enough DH support." Trojnara has responded that the question of "side-channel attacks on ECDHE is pure nonsense, since by definition (the last 'E' stands for 'ephemeral'), there is no persistent secret here an attacker might retrieve with [any available] side-channel attacks." In any case, Hynek Schlawack's Web site on the subject has not endorsed one over the other so far, while his silence on the growing questions behind Diffie-Hellman key exchange is somewhat unsettling. Your legal environment and encryption stance will decide your cipher string.

Use the following systemd unit files to configure stunnel for inetd-style operation (if you aren't using an OS based on systemd, see my previous articles for a discussion of [x]inetd):


# cat /etc/systemd/system/ricardo.socket
[Unit]
Description=oracle stunnel
[Socket]
ListenStream=1522
Accept=yes
[Install]
WantedBy=sockets.target


# cat /etc/systemd/system/ricardo@.service
[Unit]
Description=oracle stunnel service
[Service]
ExecStart=-/usr/bin/stunnel /etc/stunnel/ricardo.conf
StandardInput=socket

Assuming that the above unit files are in place, connections on 1522 can be enabled both at boot and for the present environment with these commands:


systemctl start ricardo.socket

systemctl enable ricardo.socket

The enable command will place systemd's startup link:


Created symlink from
/etc/systemd/system/sockets.target.wants/ricardo.socket to
/etc/systemd/system/ricardo.socket.

______________________

Charles Fisher has an electrical engineering degree from the University of Iowa and works as a systems and database administrator for a Fortune 500 mining and manufacturing corporation.