Invalid cipher detection (SWEET32)

I have a host which is running Microsoft’s default SSTP VPN.
I’m getting vulnerability SSL/TLS: Report Vulnerable Cipher Suites for HTTPS with oid 1.3.6.1.4.1.25623.1.0.108031.

It’s telling me cipher TLS_RSA_WITH_3DES_EDE_CBC_SHA is enabled.`

However, this cipher was disabled by using IIS Crypto and I validated it with a local NMAP scan, which does not return TLS_RSA_WITH_3DES_EDE_CBC_SHA but the following:
Screenshot 2022-02-09 at 14.02.34

Can someone elaborate a bit more on why this happens? Is the NMAP check invalid or the VT?

Hi @PBSH,

I’m bumping this to see if anyone has insight.

1 Like

You can get the full output which ciphers have been enumerated (which is the base for the VT in question) in the result of the following VT in your report (you need to update your filter to show “Log” level results accordingly):

Name: SSL/TLS: Report Supported Cipher Suites
OID: 1.3.6.1.4.1.25623.1.0.802067

As i haven’t seen any false reporting of the supported ciphers in all these years (the enumeration should be quite reliable as it looks for a specific hex string the server is choosing in the SSL/TLS handshake) there are two options left:

  1. The nmap call is done against the 443/tcp port but the result of the mentioned VT is coming from another service (e.g. some third party software on a higher port)
  2. nmap is internally calling some libraries (like e.g. openssl or some LUA internal libs) which doesn’t support TLS_RSA_WITH_3DES_EDE_CBC_SHA anymore

I would cross check with https://github.com/rbsec/sslscan (make sure to build it with make static so that the older openssl library is used).

2 Likes

Thanks, I’ll test it and get back to you.

1 Like