Add stunnel functionality for plaintext service TLS encapsulation

[UFOSmuggler]

This change lets users of the image define two new envars:

STUNNEL - Start the stunnel service on container start, via supervisord.
true: start the service
false: don't start the service

This requires the next envar to define a file path to a stunnel config file. Supervisord calls the stunnel binary with STUNNEL_CONFIG as an argument.

STUNNEL_CONFIG - File path to a stunnel config file.
It is up to the user to create this to define whatever they want to do.
/custom/files/stunnel/stunnel.conf as an example value

If the file doesn't exist or is malformed, supervisord tries a few times and gives up.

Why would you want this?
Some TLS stuff is difficult in MISP, and MISP can't speak to some services via TLS (ie. redis).

This allows you to create a listener on localhost that transparently proxies to a TLS listener somewhere else. For instance, I could create a stunnel config file that says "listen for plaintext connections on localhost:6379, connect to redis://blah.com:6380 using TLS with this CA certificate, and join the two together". Then I can point MISP's REDIS_HOST to localhost and REDIS_PORT to 6379, and now all redis traffic exiting the network is TLS encapsulated to blah.com:6380 where redis lives.

Alternatively, you could also use this to talk to a remote TLS requiring MySQL, but the one in the previous PR is more appropriate for that specific purpose in my opinion.

Or any other arbitrary service that needs it.

I have successfully used this against a TLS speaking valkey/valkey:7.2 image, and AWS Elasticache speaking valkey:7.2.

[UFOSmuggler]

If you want to test this, here's some files to help. just set REDIS_HOST to localhost so it uses the stunnel exposed port, and put the stunnel file path in $STUNNEL_CONFIG.

stunnel.conf - use TLS but don't bother verifying, you can see how to set the appropriate things:

foreground = yes
pid = /var/run/stunnel.pid
[elasticache]
client = yes
accept = localhost:6379
connect = redis:6380

#cert = /custom/files/stunnel/client-cert.pem
#key = /custom/files/stunnel/client-key.pem
#CAfile = /custom/files/stunnel/ca.pem 
verify = 0

docker-compose.override.yml - make redis container use TLS:

services:
  misp-core:
    volumes:
      - "misp_custom_shit/:/custom/:Z"
  redis:
    command: |
      sh -c '
        if [ "$${ENABLE_REDIS_EMPTY_PASSWORD:-false}" = "true" ]; then
          exec valkey-server --port 0 --tls-port 6380 --tls-cert-file /data/tls/server-cert.pem --tls-key-file /data/tls/server-key.pem --tls-ca-cert-file /data/tls/ca.pem --tls-auth-clients no
        else
          exec valkey-server --port 0 --tls-port 6380 --tls-cert-file /data/tls/server-cert.pem --tls-key-file /data/tls/server-key.pem --tls-ca-cert-file /data/tls/ca.pem --tls-auth-clients no --requirepass "$${REDIS_PASSWORD:-redispassword}"
        fi
      '
    healthcheck:
      test: |
        sh -c '
          if [ "$${ENABLE_REDIS_EMPTY_PASSWORD:-false}" = "true" ]; then
            valkey-cli --tls --cert /data/tls/server-cert.pem --key /data/tls/server-key.pem --cacert /data/tls/ca.pem -p $${REDIS_PORT:-6380} ping | grep -q PONG || exit 1
          else
            valkey-cli --tls --cert /data/tls/server-cert.pem --key /data/tls/server-key.pem --cacert /data/tls/ca.pem -a "$${REDIS_PASSWORD:-redispassword}" -p $${REDIS_PORT:-6380} ping | grep -q PONG || exit 1
          fi
        '

[ostefano]

Can you add a section to the documentation including the examples you mentioned in the PR?

[UFOSmuggler]

Can you add a section to the documentation including the examples you mentioned in the PR?

sure, i can do that. probably tomorrow.

[UFOSmuggler]

Can you add a section to the documentation including the examples you mentioned in the PR?

Completed

[ostefano]

@UFOSmuggler please rebase so I can merge

[ostefano]

Resolved the conflict, so we are ready to go.

The only aspect that I am uncomfortable with are the potential security advisories on stunnel and it dependencies, AND the fact it is installed also in the slim flavour of the image.

That flavour was created to reduce headache when running BlackDuck and other vuln management tool, and installing a new package is potentially a step backwards.

Would it be possible to make the installation conditional, or at least assess the vuln history of stunnel and its dependencies?

[ostefano]

See my comments

[UFOSmuggler]

Resolved the conflict, so we are ready to go.

The only aspect that I am uncomfortable with are the potential security advisories on stunnel and it dependencies, AND the fact it is installed also in the slim flavour of the image.

That flavour was created to reduce headache when running BlackDuck and other vuln management tool, and installing a new package is potentially a step backwards.

Would it be possible to make the installation conditional, or at least assess the vuln history of stunnel and its dependencies?

how would you feel about me adding an "optional apt packages" envar (or maybe a file in /custom/ ?) that users can add a delimited list of packages to, which are then checked for install status and installed if necessary upon container start, which the stunnel stuff triggers to install stunnel if STUNNEL=true?

from what i can see there are no known vulns for the trixie stunnel4 package or stunnel version 5.74, but i'll take a deeper look shortly.

[ostefano]

Resolved the conflict, so we are ready to go.
The only aspect that I am uncomfortable with are the potential security advisories on stunnel and it dependencies, AND the fact it is installed also in the slim flavour of the image.
That flavour was created to reduce headache when running BlackDuck and other vuln management tool, and installing a new package is potentially a step backwards.
Would it be possible to make the installation conditional, or at least assess the vuln history of stunnel and its dependencies?

how would you feel about me adding an "optional apt packages" envar (or maybe a file in /custom/ ?) that users can add a delimited list of packages to, which are then checked for install status and installed if necessary upon container start, which the stunnel stuff triggers to install stunnel if STUNNEL=true?

Optional apt packages env var can be abused really easily.
I would rather use the STUNNEL env var as a check.

from what i can see there are no known vulns for the trixie stunnel4 package or stunnel version 5.74, but i'll take a deeper look shortly.

I would rather prefer to assess the list of dependencies, their vuln history, and make an informed call.

[UFOSmuggler]

stunnel4 on Trixie assessment

stunnel 5.74 on x86_64-pc-linux-gnu platform

CVEs and known vulnerabilities

The stunnel project maintains this list of vulns, all of which are patched in version 5.74. The most recent CVE was found in 2021.

Debian's security tracker reflects much of the same information, though presumably from the point in time it became a Debian package.

From what I am able to tell there are no known unpatched vulnerabilities.

The release notes for this project include a security urgency value as well, the last HIGH urgency release being 5.74 itself.

Dependencies

Debian Trixie package

root@7f4eb23c52a3:/var/www/MISP# apt-cache depends stunnel4
stunnel4
  PreDepends: adduser
  Depends: netbase
  Depends: openssl
  Depends: init-system-helpers
 |Depends: systemd
 |Depends: <systemd-standalone-sysusers>
  Depends: <systemd-sysusers>
    systemd
  Depends: <perl:any>
    perl
  Depends: libc6
  Depends: libssl3t64
  Depends: libsystemd0
  Depends: libwrap0
  Suggests: <logcheck-database>

Of these, the following are not dependencies of other already installed packages in the misp-core image and so are installed exclusively by the stunnel4 package (determined by apt-cache rdepends --installed blah):

libwrap0

This package is described as:

Wietse Venema's network logger, also known as TCPD or LOG_TCP.

These programs log the client host name of incoming telnet, ftp, rsh, rlogin, finger etc. requests.

This package depends only on libc6, and is also a dependency of well-known packages like openssh-server.

The purpose of this package's inclusion in stunnel is to facilitate client access by IP/hostname controlled by /etc/hosts.allow and /etc/hosts.deny. libwrap0 is old and is essentially unmaintained upstream, but is maintained with Debian patches.

No known vulnerabilities since 2007, which was introduced by a Debian patch. The nature of the CVE is a condition which could cause client access controls to fail open if a service does not provide specific information.

There are no known unpatched vulnerabilities that I can find.

I would classify this as low risk. It is an optional feature and should a user want to implement this kind of control, they have many other options should they choose not to use this, though I see no reason not to use this.

Stunnel code and binary

Internal

This project does not ship large third party library source code and instead uses external dependencies. The copyright file suggests the code the primarily authored by Michael Trojnara and additions by contributors, and is covered under GPL with an exception to OpenSSL (which is linked externally anyway, not bundled). It does not list any embedded third party modules.

Everything else seems to be standard base toolchain and system libraries, such as:

davidz@ocp:~/stuff/stunnel/stunnel-5.74$ grep -oP 'include <[^>]+>' config.log|sort -u
include <ac_nonexistent.h>
include <inttypes.h>
include <libutil.h>
include <limits.h>
include <mimalloc.h>
include <netdb.h>
include <stddef.h>
include <stdint.h>
include <stdio.h>
include <stdlib.h>
include <string.h>
include <strings.h>
include <stropts.h>
include <sys/filio.h>
include <sys/stat.h>
include <sys/types.h>
include <sys/un.h>
include <tcpd.h>
include <unistd.h>
include <util.h>

Inspecting configure.ac shows basically the same.

External

root@7f4eb23c52a3:/var/www/MISP# objdump -p /usr/bin/stunnel|grep -i needed
  NEEDED               libssl.so.3
  NEEDED               libcrypto.so.3
  NEEDED               libsystemd.so.0
  NEEDED               libwrap.so.0
  NEEDED               libc.so.6
  
root@7f4eb23c52a3:/var/www/MISP# ldd /usr/bin/stunnel
	linux-vdso.so.1 (0x0000795d39f6f000)
	libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x0000795d39e0f000)
	libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x0000795d397d7000)
	libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x0000795d396c2000)
	libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x0000795d396b6000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000795d394c1000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x0000795d3949f000)
	libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x0000795d393d5000)
	libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x0000795d393c9000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x0000795d392d9000)
	/lib64/ld-linux-x86-64.so.2 (0x0000795d39f71000)
	
root@7f4eb23c52a3:/var/www/MISP# ldd -u /usr/bin/stunnel
root@7f4eb23c52a3:/var/www/MISP# 

Nothing here warrants attention beyond what has already been discussed.

[UFOSmuggler]

additionally, d024b20 changes the install method to depend upon the STUNNEL envar in case you missed it directly above my last wall of text.

[ostefano]

LGTM.

Let's include stunnel at build time when the flavour is full.
Installing packages at run time should be avoided.

[UFOSmuggler]

oh i thought you were asking me to make the installation of stunnel4 conditional on the value of the STUNNEL envar earlier in the conversation, must have misunderstood.

all good, reverted and change made.

[ostefano]

oh i thought you were asking me to make the installation of stunnel4 conditional on the value of the STUNNEL envar earlier in the conversation, must have misunderstood.

all good, reverted and change made.

I meant it as an additional variable read at build-time