[BUG] Invalid JSON due to scanResult infos

[secinto]

Before you open an issue please check which version you are running and whether it is the latest in stable / dev branch

I am running version (git log | head -1 if running from the git repo. Otherwise testssl.sh -v | grep from)

bb34248

Before you open an issue please whether this is a known problem by searching the issues

Is related to / couldn't find anything

#2138

Command line / docker command to reproduce

Which was your command line? In addition the target of your scan would be helpful. If you don't want to disclose it publicly: grep SWCONTACT testssl.sh.

testssl.sh -oJ /checkfix/projects/xxxx.eu/work/ --assume-http --warnings off -6 https://share.xxxx.eu:443

Expected behavior

A clear and concise description of what you would expect to happen.

That it generates a valid JSON (containing the warnings and infos but in a correct manner). Instead the output looks like

          "version"     : "3.2rc3 ",
          "openssl"     : "OpenSSL 1.0.2-bad from Sep  1 14:03:44 2022",
          "startTime"   : "1730828381",
          "scanResult"  : [
                            {
                                "id"           : "optimal_proto",
                                "severity"     : "INFO",
                                "finding"      : "share.xxxx.eu:443 appears to support TLS 1.3 ONLY, switching from /checkfix/tools/testssl.sh/bin/openssl.Linux.x86_64 to /usr/bin/openssl automagically"
                           }          "clientProblem2" : [
                            {
                                "id"           : "engine_problem",
                                "severity"     : "WARN",
                                "finding"      : "No engine or GOST support via engine with your /usr/bin/openssl"
                           }
          ],
          {
                    "targetHost"      : "share.xxxx.eu",
                    "ip"              : "89.XXX.XXX.XXX",
                    "port"            : "443",
                    "rDNS"            : "web2.xxxx.eu.",
                    "service"         : "HTTP",

Your system (please complete the following information):

• OS: Ubuntu 22.04.5 LTS
• Platform: Linux 5.15.0-125-generic x86_64
• OpenSSL + bash: OpenSSL 1.0.2-bad [~179 ciphers], bash 5.1.16

Additional context

Add any other context about the problem goes here.

[drwetter]

Thanks for filing the issue.

However it worked for me with the latest and greatest:

1. Can you try again please with the latest and greatest?

2. not sure where clientProblem2 all of a sudden comes from. I guess you copied it 1:1 but I rather would expected clientProblem1 first.

3. also: where is the problem with the JSON format in your case?

[dcooper16]

I was able to reproduce the problem (see below). My guess is that @secinto omitted the first part of the JSON file. I problem is that there isn't a comma before ClientProblem2.

I don't have time to trace through this in detail at the moment to figure out exactly what is happening. But, my guess is that there was an assumption that fileout_insert_warning() would only be called before fileout_banner() is called. This was the case until a call to find_openssl_binary() (which calls initialize_engine()) was added in the case that testssl.sh automagically switches from the provided OpenSSL to $OPENSSL2.

I think there are three potential solutions to this problem:

1. Change initialize_engine() to not call fileout() or fileout_insert_warning(). Is it still necessary for the JSON/CSV file to include a warning that $OPENSSL does not have engine or GOST support?
2. Change fileout_insert_warning() to not add a "clientProblem" wrapper if $TLS13_ONLY is true.
3. Try to add a global that indicates whether fileout_banner() has been called, and then use this in fileout_insert_warning() to decide whether or not to add a "clientProblem" wrapper.

I haven't tried any of these, but I think they would work. The second one is based on the idea that fileout_insert_warning() will only be called after fileout_banner() if find_openssl_binary() is being called a second time, which can only happen with a TLS 1.3 only server (and $TLS13_ONLY will always be false the first time find_openssl_binary() is called).

The third potential solution is more general, but would only be needed if in the future there was another function that could be called both before and after fileout_banner() that sometimes wrote things to JSON/CSV and that might be called a second time when $TLS13_ONLY is false.

I could try (1) or (2) and create a PR if it works. Do you have a preference?

{
          "clientProblem1" : [
                            {
                                "id"           : "engine_problem",
                                "severity"     : "WARN",
                                "finding"      : "No engine or GOST support via engine with your bin/openssl.Linux.x86_64"
                           }
          ],
          "Invocation"  : "testssl.sh -oJ test.json --assume-http --warnings off 127.0.0.1:8443",
          "at"          : "bin/openssl.Linux.x86_64",
          "version"     : "3.2rc3 ",
          "openssl"     : "OpenSSL 1.0.2-bad from Sep  1 14:03:44 2022",
          "startTime"   : "1732123501",
          "scanResult"  : [
                            {
                                "id"           : "optimal_proto",
                                "severity"     : "INFO",
                                "finding"      : "127.0.0.1:8443 appears to support TLS 1.3 ONLY, switching from bin/openssl.Linux.x86_64 to /usr/bin/openssl automagically"
                           }          "clientProblem2" : [
                            {
                                "id"           : "engine_problem",
                                "severity"     : "WARN",
                                "finding"      : "No engine or GOST support via engine with your /usr/bin/openssl"
                           }
          ],