Ad Widget

Collapse

2.4.3 to 2.4.6 upgrade breaks https check

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • jamesNJ
    Senior Member
    • Jun 2015
    • 103

    #1

    2.4.3 to 2.4.6 upgrade breaks https check

    Hello,
    Zabbix server is centOS 7, recently upgraded from 2.4.3 to 2.4.6

    I have an odd issue that cropped up last night ... it looks like my upgrade of zabbix server broke an https test, and I am scratching my head to find out why.

    I have an item like this:
    net.tcp.service[https,192.168.100.100,443]

    This device [IP address] happens to be an HP MSL tape library with a network web interface. I'm probing the availability of the https web interfaces as inaccessibility of this is usually an indicator that the hardware has stopped working. The device has a vendor supplied self-signed certificate.

    Prior to upgrade, this test was working fine. Right after upgrade, the test fails. I was running this as "Zabbix agent" check (using zabbix server address) and changed it to simple check, same result.

    I tested the device with openssl s_client, and it gets back a connection and certificate. I am also able to get to the login page using curl --insecure, etc.

    I haven't tested against another existing 2.4.3 agent ... I'll try that next. I could also try using a web scenario, but thought that it was overkill to do such for a simple up/down service test that I need.

    Is this something expected or perhaps broke between 2.4.3 and 2.4.6?
  • jamesNJ
    Senior Member
    • Jun 2015
    • 103

    #2
    I think I have confirmed that there is some difference the upgrade introduced.

    This device is primarily SNMP, but I had in place a host interface of 127.0.0.1 (zabbix server) to run some very simple tests or network connectivity.

    When I use net.tcp.service[https,192.168.100.100,443] as either a simple check or using the local zabbix agent, I get a failure raised.

    If I change host IP to another machine running the 2.4.3 agent, the condition clears up.

    I can also note that the zabbix server upgrade was pulled in as part of a more general centOS 7 server upgrade. My release now reads as:

    CentOS Linux release 7.1.1503 (Core)

    and if it makes any difference, due to a gnutls related crash when I first installed zabbix I have a downgraded gnutls install with the following, and yum set to ignore updates (see below).

    The only other thing I can think of is to perhaps find another centOS 7 machine here and run the server upgrade while retaining the 2.4.3 agent and see if it makes any difference, and perhaps fool with gnutls to see if previous crashes were fixed or anything there is causing this.

    Can anyone suggest where else I should look to troubleshot this?

    Here is gnutls if it makes any difference:
    yum.conf includes - exclude=gnutls gnutls-dane gnutls-utils
    current install
    gnutls.x86_64 3.1.18-8.el7 @LocalRepo
    gnutls-dane.x86_64 3.1.18-8.el7 @LocalRepo
    gnutls-utils.x86_64 3.1.18-8.el7 @LocalRepo

    Comment

    • jamesNJ
      Senior Member
      • Jun 2015
      • 103

      #3
      I tried to create a web scenario to see if I got any better results.

      As indicated earlier I used a Zabbix agent v2.4.3 to probe the connection and it succeeded. I used the same agent interface for the web scenario but I receive an error on the scenario. The error relates to:

      SSL connect error: SSL received a weak ephemeral Diffie-Hellman key in Server Key Exchange handshake message.

      I am not sure I can improve any security settings for this tape library device.

      Comment

      • jamesNJ
        Senior Member
        • Jun 2015
        • 103

        #4
        I finally had a chance to debug this.

        It looks like the upgrade of SSL libraries (libssl and libssl3) put some new default limitations on the key exchange. This change affects anything that uses one or both of those 2 libraries.

        In my case I can't force the device manufacturer to update their security ... and for this device where would seem to be little need to do so anyway.

        Downgrading the library would affect security for the whole system. I opted to use stunnel to connect to this devices, and alter LD_LIBRARY_PATH for it to use the older library which works.

        Possibly there is some environment variable that will help with this ... I haven't found it yet.

        Comment

        Working...