RHEL 8 FIPS MODE - Problems for PSK

[Martin Jørgensen]

Hi

We building a new Zabbix 5 environment on top on RHEL 8 with FIPS Mode enabled.
Only problem is PSK

We get these in the logs

failed to accept an incoming connection: from [B]xx-xx-xx-xx[/B]: unspecified certificate verification error: TLS handshake set result code to 1: file crypto/evp/evp_enc.c line 226: error:0607B0C8:digital envelope routines:EVP_CipherInit_ex:disabled for FIPS file ssl/tls13_enc.c line 400: error:14202006:SSL routines:derive_secret_key_and_iv:EVP lib

The problems is from (All with PSK enabled)
RHEL8Agent -> RHEL8Server
RHEL8Proxy -> RHEL8Server

But if we set

sudo fips-mode-setup --disable
sudo reboot

Server and agent/proxy can talk fine with the server with PSK,

But funny enough, this works
RHEL8Agent -> RHEL7Server (Out current Zabbix 4.4 env, server part is not running fips mode)

I used these docs for help

https://www.zabbix.com/documentation/current/manual/encryption#switching_from_aes128_to_aes256

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening#switching-the-system-to-fips-mode_using-the-system-wide-cryptographic-policies

Anyone using Zabbix 5 in an enterprise environment with hardened server infrastructure?

[tim.mooney]

The same error message in a much different scenario: https://access.redhat.com/solutions/176633

This is just speculation on my part, but it's almost like Red Hat's FIPS mode setup disables the necessary stuff (MD5, et. al.) but doesn't actually add configuration defaults so that OpenSSL (and probably other encryption backends) uses other algorithms for e.g. cipher negotiation, etc.

On the first document that you linked, there are examples of using zabbix_sender with '-vv' to identify which cipher suites the client would use. You might try some debugging with that, to see if you can identify what's being attempted on both ends of the connection. If you are comfortable reading and interpreting network packet dumps, you might be able to get the same info using something like wireshark.

What "TLS*" options have you set in the zabbix_server.conf and zabbix_agent.conf for each end of the connection?

[Martin Jørgensen]

Hi Tim

I haven't tried the zabbix_sender stuff, but i can say that agent and server bin is compiled with OpenSSL 1.1.1c FIPS

Zabbix server i compiled with

zabbix_server -V
Compiled with OpenSSL 1.1.1c FIPS 28 May 2019
Running with OpenSSL 1.1.1c FIPS 28 May 2019

Zabbix agent2 and zabbix agent is compiled with

zabbix_agent2 -V
Compiled with OpenSSL 1.1.1c FIPS 28 May 2019
Running with OpenSSL 1.1.1c FIPS 28 May 2019

Zabbix server config have a section with
####### For advanced users - TLS ciphersuite selection criteria #######

I tried diffident settings with no luck, not really sure what to set, did this on both client and server end.

I will try the zabbix_sender part

[Martin Jørgensen]

HI

I resolved this by setting this on config on server/proxy/agent

TLSCipherPSK13=TLS_AES_128_GCM_SHA256

[tuxmartin]

`TLSCipherPSK13` works only with Zabbix agent 1/classic. Zabbix agent 2 does not support the config parameter `TLSCipherPSK13`.

[[email protected]]

We had the same issue. To fix, my coworker saw that our Palo Alto was detecting the zabbix traffic as a different application type. I believe he made some configuration changes to the detection of the zabbix traffic in palo alto config for the connection to be successful.