False Positive with TLS versions of OID: 1.3.6.1.4.1.25623.1.0.105780

Vulnerability Tests
1

I am scanning a host with the TLS/SSL checks enabled.
The plugin [OID: 1.3.6.1.4.1.25623.1.0.105780] reports TLS 1.0 and TLS 1.1 enabled and marks that as “Police Violation” as intended.
Doing a verification with sslscan, only TLS 1.2 & 1.3 are enabled.
Doing a verification with https://www.ssllabs.com/ssltest/analyze.html the finding is not there.

2

Edit: This was about a different VT, please see later comment.

From my experiences the VT in question is not false positive prone in any way and the reporting is always correct.

Most of the reports where some one thought that the reporting is wrong was originating from environmental reasons:

  1. The “other” test (like e.g. sslscan) didn’t supported older SSL/TLS versions anymore
  2. The system in question was still supporting such older SSL/TLS versions when accessing it via the IP while the “cross check” with another tool was done via the hostname
  3. The “other” test was done against e.g. port 443/tcp but the valid report was about a completely different port like e.g. 8443/tcp (e.g. the ssllabs test is AFAICT only testing port 443/tcp)
  4. The system in question is exposing such outdated / deprecated protocols when accessing / querying it via the IP while “other” tests are usually only checking the hostname (via SNI) and thus could miss a report of these
1 Like
3

Hi cfi!

Thanks for the answer.
All checks/tests were performed with the exact same hostname and explicitly configured port (443). The timeframe were the tests were performed was closer than 1 hour.
The make the possibility of mistakes in the validation check, I do 2 checks (sslscan & qualys).
ATM I have to consider that the plugin script is doinf something wrong.

4

Edit: This was about a different VT, please see later comment.

As already mentioned the VT in question is not known to be false positive prone and actually reports what has been found on the target host in question correctly.

Thus i would look on target / other test side first/instead. An additional item (SNI) to the previously list has been added a few minutes ago which could play a role / make a difference as well.

5

OK,

I will try the forensic mode by performing the test with full network work traffic monitoring. Maybe that brings us forward.

1 Like
6

Ahoi!

Next indicator:
use curl --tlsv1.0 --tls-max 1.0 [URL]:
~ % curl -vv --tlsv1.0 --tls-max 1.0 [URL]

  • Host [URL]:443 was resolved.

  • IPv6: (none)

  • IPv4: 172...***

  • Trying 172...***:443…

  • Connected to [URL] (172...***) port 443

  • ALPN: curl offers h2,http/1.1

  • (304) (OUT), TLS handshake, Client hello (1):

  • CAfile: /etc/ssl/cert.pem

  • CApath: none

  • LibreSSL/3.3.6: error:1404B42E:SSL routines:ST_CONNECT:tlsv1 alert protocol version

  • Closing connection

curl: (35) LibreSSL/3.3.6: error:1404B42E:SSL routines:ST_CONNECT:tlsv1 alert protocol version

Maybe the scanning script is wrong?

7

Oh, my bad. I just noticed that i had mixed up the OIDs:

I was actually talking about SSL/TLS: Version Detection (OID: 1.3.6.1.4.1.25623.1.0.105782) which is the VT not known to be false positive prone.

But this topic is actuallly about a different set of “Policy” VTs:

  • SSL/TLS: Policy Check (OID: 1.3.6.1.4.1.25623.1.0.105778)
  • SSL/TLS: Policy Check OK (OID: 1.3.6.1.4.1.25623.1.0.105781)
  • SSL/TLS: Policy Check Violations (OID: 1.3.6.1.4.1.25623.1.0.105780)

Unfortunately the devs worked on this Policy topics are not reading / posting in this forums so you probably would need to figure out / research this on your own.

1 Like
8

Anyway, thanks for taking care and answering

1 Like