Cockpit still using TLS 1.1

NethServer Version: 7.8.2003
Module: base

Nessus scanning is still reporting a TLS 1.1 fault on 9090 from NS. Confirmed with Nmap:

Nmap scan report for hostname (300.300.300.200)
Host is up (0.00s latency).

PORT STATE SERVICE
9090/tcp open zeus-admin
| ssl-enum-ciphers:
| TLSv1.1:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: client
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 (secp256r1) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384 (rsa 2048) - A
| compressors:
| NULL
| cipher preference: client
|_ least strength: A

Setting for TLS on the TLS “tab” is…
image
Ref: https://docs.nethserver.org/en/v7/tlspolicy.html

1 Like

Update: verified that /etc/httpd/conf.d/ssl.conf is set SSLProtocol all -SSLv2 -SSLv3.

config show tls

please what is the output

tls=configuration
    policy=20200510
1 Like

we cannot restart ourself cockpit, this service restarts on its own when you log out or when nobody is connected, so the service was still not reloaded when you tested.

either wait a time (up to 5 minutes without root connected) or restart cockpit then test with nmap

systemctl restart cockpit

validated on my VM, after the reboot cockpit uses only TLS1.2

I’d suggest adding a restart as with other features in cockpit just to add some positive feedback to the user(s).

The problems that the user will have a closed cockpit session when the service will restart, we need to let the service restart on its own.

1 Like