Greenbone is not detecting the problem

I have Greenbone Community Edition setup in my Oracle Linux 9.2.
Currently running Greenbone Security Assistant v22.5.3, and OpenVAS Scanner version 22.7.3
I have configured my Scan Configs with only 1 item from SSL / TLS family.

  • SSL/TLS: Deprecated TLSv1.0 and TLSv1.1 Protocol Detection

However, my scan result reported 0 issue, but in fact I purposely make these issues for my initial test.
I have confirm the issues are valid using testssl tool.

Here is my VirtualHost config purposely enabled all SSL Protocols, and SSL Cipher Suite.

  SSLProtocol               +ALL

and here is the report from testssl to confirmed weak protocols such as TLSv1.0, TLSv1.1 is supported, and weak cipher suite:

 Testing protocols via sockets except NPN+ALPN

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      offered (deprecated)
 TLS 1.1    offered (deprecated)
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK): final
 NPN/SPDY   not offered
 ALPN/HTTP2 h2, http/1.1 (offered)

Could please enlighten me where am I doing it wrongly ?

How did you create the custom scan configuration? If you create a scan configuration with only one single VT (the * SSL/TLS: Deprecated TLSv1.0 and TLSv1.1 Protocol Detection in your case) it will not work because I believe there are some base-level VTs that need to be included for a vulnerability scan to work properly.

You should create your config by cloning the Base scan config (Basic configuration template with a minimum set of NVTs required for a scan) and then adding your desired VTs on top of those.

Check if that is causing the issue. :thinking:

Just precaution that may be I messed up,
so I reinstalled the entire GVM with the below version:

  • Eclipse Paho MQTT v1.3.12
  • gvm-libs v22.7.0
  • gvmd v22.6.1
  • pg-gvm v22.6.1
  • GSA v22.6.0
  • gsad v22.5.2
  • openvas-scanner v22.7.3
  • ospd-openvas v22.5.4
  • notus-scanner v22.5.0

It is still the same that TLS 1.0 and TLS 1.1 not being detected.
vulnerarbility in the cipher suite also not detected.
I cloned from Base scan config

and added TLS 1.0

and weak and vulnerable cipher as below.

This is my TCP port list,

This is my Target,

This is my task using the scan config and target I created above.

This is the Greenbone reports,
which testssl command able to detect those TLS vulnerability and I also able to see from my web server access log that greenbone does test, but greenbone not reported as issue.

Access Log:

testssl report:
testssl.txt (18.3 KB)

greenbone report:
report-a9a93a57-a332-4413-8866-8518368dfb22.pdf (208.3 KB)

not sure if anythings misconfigured or missing to make it work correctly.
Appreciate if could enlighten me.

I found the reason and root cause,

Because the web server (Apache HTTPD) is named-based virtual host.
When Greenbone scan the vulnerabilities, that domain has the problem, but not the IP.
because when access with IP, it will fall into another virtual host.
Hence Greenbone not reporting it as a problem because the IP was good.

I will raise this as a bug.

Just a precaution that some may some consider it unethical to scan IT infrastructure that you do not own or have explicit authorization to scan. I see that your reports are scanning the host.

No worries, that is my domain. :wink:

Oh, right, I guess I was seeing it wrong… I was thinking it was actually :blush:

Hello @jin861224,
Did you enable the “expand_vhosts” option in the scan config?

yup, expand_vhost is 1.

After some scans and adding more VTs to the scan config, I found that TLS1.0 and TLS1.1 are enabled with renegotiation support.

The script is SSL/TLS: Safe/Secure Renegotiation Support Status OID:

Checks and reports if a remote SSL/TLS service supports
  safe/secure renegotiation.
Detection Result

Protocol Version | Safe/Secure Renegotiation Support Status
SSLv3            | Unknown, Reason: Scanner failed to negotiate an SSL/TLS connection (Either the scanner or the remote host is probably not supporting / accepting this SSL/TLS protocol version).
TLSv1.0          | Enabled, Note: While the remote service announces the support of safe/secure renegotiation it still might not support / accept renegotiation at all.
TLSv1.1          | Enabled, Note: While the remote service announces the support of safe/secure renegotiation it still might not support / accept renegotiation at all.
TLSv1.2          | Enabled, Note: While the remote service announces the support of safe/secure renegotiation it still might not support / accept renegotiation at all.
TLSv1.3          | Disabled (The TLSv1.3 protocol generally doesn't support renegotiation so this is always reported as 'Disabled')

@jjnicola Sorry, I dont understand.


and welcome to this community forums.

This is currently the expected behavior:

The SSL/TLS cipher and version determination is purely done via NASL based scripts and the code part is using the IP and not the hostname(s) of the target to query this information (technical: No SNI extension with the host name is sent).

There is an internal task to improve / extend this functionality to use / sent the SNI extension in SSL/TLS requests. But as this is a hugely invasive task which can have various negative side-effects not really testable there is no timeline available for this.