Can I force my sensors to ONLY USE TLSv1.2 when probing my devices?

Do some PRTG SSH sensors first attempt to connect using the LEAST SECURE protocol (like SSLv3), and then go higher??? If so, can this behavior be reversed to start at the MOST SECURE protocol (TLSv1.2) and then stop once connected?

Reason I ask: I've got an ES (ElasticSearch) cluster with only TLSv1.2 allowed, and lower protocols (such as TLSv1.1 to SSLv3) disabled. While PRTG successfully connects using TLSv1.2, for some strange reason my ES logs are filled with thousands of messages stating that PRTG attemped to probe (unsuccessfully) using SSLv3, TLSv1, TLSv1.1.....this wastes disk space and (more importantly) makes it hard to scan my logs when issues arise.

I just don't understand why the probes don't start at the most secure protocol first, and then stop one a successful communication is established.

Version: 18.3.43.2323

Thanks for any suggestions.

Article Comments

Hello,

thank you for the KB-Post. The mechanics behind all TLS-capable sensors is actually that they start with the highest version of TLS that they support and make their way downwards to plain un-encrypted communication.
As you probably can imagine, the wording "the highest version of TLS that they support", not all sensors do support TLS1.2 as of now. Thus it is important to know which exact sensors you have on the device.
Of course if all of the sensors are working, and the device only runs with TLS 1.2, then the sensors cannot really cause the logentries. Then it could be the sensor recommendation (try to check if other sensors could be added to the device) or the system information feature.
The System Information Feature can be disabled for the device in its "Settings" under "Advanced Network Analysis", the sensor recommendation needs to be disabled in the PRTG System Settings "Recommended Sensors Detection".

best regards


Oct, 2018 - Permalink

Well, I've got egg on my face......

Thanks for your prompt response! Solution: I was using an SSL Security Check sensor to check the elasticsearch port to verify that the service was running. I have since deleted the sensor and now my elasticsearch logs are as clean as a whistile. That sensor was (for the most part) redundant anyway because I monitor the health of elasticsearch with an HTTP Advanced sensor, so if the service went down, the HTTP Adv sensor would throw an error.

Thanks for your prompt response!


Oct, 2018 - Permalink