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?
Hi
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
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
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 0.0.0.0:8000 -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 0.0.0.0:8000 -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:
/opt/omd/sites/mon/etc/init.d/agent-receiver
I added the option "–ssl-version TLSv1_2 ":
case "$1" in
start)
echo -en "Starting agent-receiver..."
if kill -0 $PID >/dev/null 2>&1; then
echo 'Already running.'
exit 0
fi
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 0.0.0.0:$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
Hey,
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 
)
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 0.0.0.0:8000 --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
@stager999
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:
'TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:ECDH+AESGCM:ECDH+CHACHA20:DH+AESGCM:DH+CHACHA20:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+HIGH:DH+HIGH:RSA+AESGCM:RSA+AES:RSA+HIGH:!aNULL:!eNULL:!MD5:!3DES'
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
Thanks
Hey @righter,
sorry for the late reply but I guess better late than never 
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.