Disable TLS 1.0/1.0 for Port 8000 Agent Receiver

CMK version: Enterprise 2.1.0p13
OS version: Debian 10.13

Error message:
Security Scan says TLSv1.0 and TLSv1.1 is active on Port 8000

How can I disable these outdated protocols?


I have also got a scan report with the outdated TLS versions on port 8000. However, I have then researched a little bit and I have found out that this port is used by the gunicorn daemon:

[root@localhost ~]# lsof -i:8000
python3 3588937 mon    7u  IPv4 12530911      0t0  TCP *:irdmi (LISTEN)
python3 3588941 mon    7u  IPv4 12530911      0t0  TCP *:irdmi (LISTEN)
[root@localhost ~]# ps -ef |grep 3588937
mon   3588937       1  0 11:10 ?        00:00:00 python3 /omd/sites/mon/bin/gunicorn -D -p /omd/sites/mon/tmp/run/agent-receiver.pid --error-logfile /omd/sites/mon/var/log/agent-receiver/error.log --access-logfile /omd/sites/mon/var/log/agent-receiver/access.log --keyfile /omd/sites/mon/etc/ssl/agent_receiver_cert.pem --certfile /omd/sites/mon/etc/ssl/agent_receiver_cert.pem --ssl-version TLSv1_2 --ca-certs /omd/sites/mon/etc/ssl/ca.pem --cert-reqs 1 -b -k agent_receiver.worker.ClientCertWorker agent_receiver.apps:main_app()
mon   3588941 3588937  0 11:10 ?        00:00:12 python3 /omd/sites/mon/bin/gunicorn -D -p /omd/sites/mon/tmp/run/agent-receiver.pid --error-logfile /omd/sites/mon/var/log/agent-receiver/error.log --access-logfile /omd/sites/mon/var/log/agent-receiver/access.log --keyfile /omd/sites/mon/etc/ssl/agent_receiver_cert.pem --certfile /omd/sites/mon/etc/ssl/agent_receiver_cert.pem --ssl-version TLSv1_2 --ca-certs /omd/sites/mon/etc/ssl/ca.pem --cert-reqs 1 -b -k agent_receiver.worker.ClientCertWorker agent_receiver.apps:main_app()
root     3610425 3571345  0 12:26 pts/0    00:00:00 grep --color=auto 3588937

Then I have found the init proces of the agent-receiver:

I added the option "–ssl-version TLSv1_2 ":

case "$1" in

        echo -en "Starting agent-receiver..."
        if kill -0 $PID >/dev/null 2>&1; then
            echo 'Already running.'
            exit 0

        gunicorn -D -p $PIDFILE  \
                --error-logfile $OMD_ROOT/var/log/agent-receiver/error.log \
                --access-logfile $OMD_ROOT/var/log/agent-receiver/access.log \
                --keyfile "$KEY_AND_CERT_FILE" \
                --certfile "$KEY_AND_CERT_FILE" \
                --ssl-version TLSv1_2 \
                --ca-certs "${OMD_ROOT}/etc/ssl/ca.pem" \
                --cert-reqs 1 \
                -b$CONFIG_AGENT_RECEIVER_PORT \
                -k agent_receiver.worker.ClientCertWorker 'agent_receiver.apps:main_app()'

After that I restarted omd and the older TLS versions are not available anymore on the 8000 port.

However, this solution is not OK, since I have changed the checkmk source code. Does anybody know a better solution?

1 Like

@Maximilian I think this would be part of your expertise :)?

we already looked into this. Unfortunately we have not found a satisfiying solution.
The option --ssl-version TLSv1_2 disables all other versions including TLS1.3. That’s why we haven’t set this option.
The actual risk is very small, since the only client is the agent-controler. This brings its own TLS stack which does not support TLS1.1 or lower. So downgrade attacks on this communication is not possible. So security-wise I see no risk here (except automatic compliance scanners :frowning: )

In Checkmk2.2 a newer Python version will be used which does not support TLS1.1 and lower.
On the long run we would like to put the site Apache in front of the agent receiver, unfortunately this is currently not possible.

If you disagree with the risk assessment I’m happy to hear the arguments, if you just want to be compliant, the solution of @stager999 is the one I would recommend.

@Maximilian What about this: How to specify TLSV1_3 with gunicorn · Issue #2579 · benoitc/gunicorn · GitHub

So for example:

gunicorn --certfile cert.pem --key key.pem --ssl-version TLS_SERVER --ciphers AES256-GCM-SHA384:AES128-GCM-SHA256 -b --workers 1 flaskt:app

Would result in:

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      not offered
 TLS 1.1    not offered
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK): final
 NPN/SPDY   not offered
 ALPN/HTTP2 not offered
TLSv1.2 (server order)
 x9d     AES256-GCM-SHA384                 RSA        AESGCM      256      TLS_RSA_WITH_AES_256_GCM_SHA384
 x9c     AES128-GCM-SHA256                 RSA        AESGCM      128      TLS_RSA_WITH_AES_128_GCM_SHA256
TLSv1.3 (server order)
 x1302   TLS_AES_256_GCM_SHA384            ECDH 253   AESGCM      256      TLS_AES_256_GCM_SHA384
 x1303   TLS_CHACHA20_POLY1305_SHA256      ECDH 253   ChaCha20    256      TLS_CHACHA20_POLY1305_SHA256
 x1301   TLS_AES_128_GCM_SHA256            ECDH 253   AESGCM      128      TLS_AES_128_GCM_SHA256

Interesting. the --ssl-version TLS_SERVER does not seem to do anything. But the --ciphers AES256-GCM-SHA384:AES128-GCM-SHA256 seems to something. I guess those ciphers are not available in pre TLS1.2.
BUT my sslyze (Github Link) warns me that now TLS1.2 does not provide Forward Secrecy anymore. That is definitely undesirable. Also the list of ciphers is substantially smaller.

Yes, exactly TLS_SERVER means “auto-negotiation”.
Maybe the other ciphers could be tried:



Yea, and in our environment all our CMK servers will be shutdown if the scanners finds things they don’t like…

@Maximilian I got now also this vulnerability reported:

SSL/TLS: Renegotiation DoS Vulnerability (CVE-2011-1473, CVE-2011-5094)

Maybe that could also be fixed in 2.2


Hey @righter,
sorry for the late reply but I guess better late than never :slight_smile:
Both mentioned CVEs are disputed.

The problem seems, that a client with an existing TLS/TCP connection can cause renegotiations which basically means a new TLS handshake which is computational intensive. A client can also cause this with a new connection. Arguably it is a bit easier to detect new TCP connections than TLS renegotiation requests but apparently you can detect them without TLS interception.

I agree therefore with the disputation and don’t think this is really an issue and should be treated as false-positive.