HTTP agent: dh key too small

[NovaSatori]

Doing simple HTTP agent probe on HTTPS, got error

Cannot perform request: error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small

Currently using Zabbix 6.2.6 on Ubuntu 20.04. It was working before on Zabbix 6.0 and Ubuntu 18.04.

The only solution I found is to modify openssl config with

MinProtocol = TLSv1.2
CipherString = DEFAULT:@SECLEVEL=1

It didn't help and I'm not sure Zabbix uses this file ever.
Please help.

[tim.mooney]

This isn't really a Zabbix issue, it's an SSL/TLS issue.

I can't tell from your message which side of the connection is at fault: whether it's the server that doesn't like the client's Diffie Hellman key size or whether it's the client that doesn't like the server's Diffie Hellman key size, but one side of the connection or another is using an older, small key size.

You can do some general web searches for things like "diffie hellman key size", but one of the first pages I turned up seems to have some decent recommendations: https://weakdh.org/sysadmin.html

In particular, if you're using Apache httpd as your web server, it lists the procedure that can be used to pre-compute a larger key size "Diffie Hellman group", save it in a file, and then there's a mod_ssl configuration parameter that you set along with your other encryption parameters, to point mod_ssl to that file.

If the problem is that the client is using a DH config that is too small, then you'll have to figure out how to make the client use a larger key size. That's going to depend upon what client you're using.

If your front-end is reachable from the Internet, you may also want to point the Qualys SSL Labs "checker" tool at it. It will give you many recommendations for how you can improve the TLS config on your server. https://www.ssllabs.com/ssltest/

Just be advised that the Qualys checker generally suggests the very latest algorithm and cipher settings and you may need to ignore some of its suggestions if you need to support older devices, etc.

[NovaSatori]

The server is box enterprise application on Apache Tomcat, it's probably uses the small key size but configs are unavailable to edit.
By client you mean Zabbix, what are the options to modify?

[tim.mooney]

Ah, thanks for clarifying. I initially misunderstood the "direction" of the communication. I thought you were using some web client software to connect to the Zabbix web interface and were seeing that error between that connection, but the error you're seeing is with Zabbix (possibly via a web scenario) connecting to your Tomcat install and getting the error. Now I understand.

Zabbix uses libcurl when it initiates a web connection to some other system. Based on the error message you're showing, the libcurl on your system is definitely linked against OpenSSL.

Also, since you've indicated that this worked for an older version of Zabbix on an older version of Ubuntu, it seems pretty likely that the issue is that the newer Ubuntu where you're running Zabbix has stronger security defaults in OpenSSL or libcurl. That's really common. The relentless march of deprecated security-related algorithms and ciphers seems to be one of the big changes every time one upgrades a distro version.

Looking at the Zabbix documentation for web scenarios, here: https://www.zabbix.com/documentation...web_monitoring , it's clear that some of the stuff you can set in the Zabbix web scenario gets passed to libcurl via various CURLOPTS_* settings, but I don't see any way via the web interface to pass settings related to ciphers or TLS versions. You've actually pointed out what I would consider to be a deficiency in the Zabbix web scenarios. They should really expose a way to set scenario-specific ciphers.

I think what you probably should do is run some kind of TLS scan tool against your Apache Tomcat appliance, to figure out what TLS levels and protocols it supports. If you're comfortable compiling software, the 'sslcan' command-line tool can tell you a lot about what protocols and ciphers a system supports. There are various forks of the original tool, one of the more active ones is available here: https://github.com/rbsec/sslscan . You may be able to find that as a pre-compiled package for Ubuntu -- I'm not sure.

Once you know what the Apache Tomcat system actually supports, then the next step is to figure out how to get those options passed to libcurl. I think that setting them in the openssl.cnf should work, but finding out what protocol version and what ciphers are supported is the first step.

[NovaSatori]

Tim, thank you for detailed answer, it helps to understand process underneath.
I scanned server with sslscan docker image, got

Supported Server Cipher(s):
Preferred TLSv1.2 128 bits DHE-RSA-AES128-SHA DHE 1024 bits
Accepted TLSv1.2 256 bits AES256-SHA
Accepted TLSv1.2 128 bits AES128-SHA zz0.7aqw7h6sibnzz

Ok, keys shorter than 2048 bits are blocked in default configurations of newer OpenSSL. I'm setting security level 1 and it's working because I can do both curl and openssl s_client connect without errors.
Conclusion is that Zabbix server doesn't use openssl config to connect to sites. Any other ideas?

And I'm using HTTP agent check https://www.zabbix.com/documentation...itemtypes/http

Upg: after few restarts of Zabbix server service it got working. Appreciate your help!

[tim.mooney]

Excellent, glad you got it working. I hadn't suggested a zabbix-server restart yet because I wasn't certain you had the right ciphers specified yet, but I figured a restart would eventually be required.

I've actually not used @SECLEVEL before. What we've typically done at my site is specified the cipher list, but left out any that would be too weak.

In your case, the first cipher the Apache tomcat server is offering is 'DHE-RSA-AES128-SHA', and that's the one that OpenSSL on your Ubuntu Zabbix server doesn't like (the "DHE" part is a giveaway that it uses Diffie Hellman). You could have then specified your client's cipher list to just include other ciphers but not that "DHE..." one.

I think your solution using SECLEVEL is a good one, though, as it kind of "automatically" sets the parameters you want. One problem with explicitly listing all the ciphers you want to support is that it's easy to forget to update it when updating to a new software version that might include newer, more secure options. Your solution doesn't have that problem.