drwetter / testssl.sh

Testing TLS/SSL encryption anywhere on any port
https://testssl.sh
GNU General Public License v2.0
7.93k stars 1.02k forks source link

Feature request: Output JSON to stdout? #1290

Closed virtadpt closed 5 years ago

virtadpt commented 5 years ago

Please make sure that you provide enough information so that we understand what your issue is about.

  1. uname -a Linux windbringer 5.0.11-arch1-1-ARCH #1 SMP PREEMPT Thu May 2 19:48:15 UTC 2019 x86_64 GNU/Linux

  2. testssl version from the banner: testssl.sh -b 2>/dev/null | head -4 | tail - testssl.sh 3.0rc5 from https://testssl.sh/dev/

  3. git log | head -1 (if running from git repo) commit eef63b1726b9f44ff63a6dc19c6e2ea16e78b644

  4. openssl version used by testssl.sh: testssl.sh -b 2>/dev/null | awk -F':' '/openssl/ { print $2}' ./bin/openssl.Linux.x86_64

As a user of testssl.sh who wants to use the Dockerfile in an automated fashion (with Huginn, so that I can monitor the SSL states of my boxen), I would like to be able to tell testssl.sh to emit JSON to stdout with an additional command line switch (ideally, like this: --jsonfile -) instead of regular text. Running testssl.sh with --jsonfile - results in the data being written to a file in the CWD called -.

The exact command I'm typing: ./testssl.sh --quiet --color 0 --jsonfile - myhost.example.com

drwetter commented 5 years ago

First of all, I am /the/ doctor ;-)

Secondly: Why don't you use mounts, see e.g #1272 ? That's the docker way of doing it, unless you want to fiddle with log drivers, which could be another possibility but is not necessarily a scope of this project.

This is not a solution but instead of jsonfile - you can also use --jsonfile /dev/stdout but then you get garbage as the regular screen output will be displayed, too. The catch is that atm I do not see a simple way of removing the screen output from /dev/stdout. In a container this ./testssl.sh --jsonfile /dev/stderr <TARGET> >/dev/null didn't work (see #822)

Why do you use in the first place a container for this?

virtadpt commented 5 years ago

The definitive article, you might say? :)

I thought about using a mount, but then I'd have to build a separate toolchain to send the .json file someplace where it's accessible over HTTPS, and that seems kind of brittle when I just want to jump the JSON to stdout so that the watchdog will do that for me. I'm trying to use it in the same way as a REST endpoint (HTTP request goes in, JSON goes out).

What about a different output channel, like stderr? I think I could capture that. I just tried this, and it seemed to do what I wanted:

./testssl.sh --quiet --color 0 --jsonfile /dev/stderr test.example.com 1>/dev/null

Why do I us a container? OpenFaaS. I'm basically using it to build pseudo-agents for Huginn that are a bit more specialized than your usual serverless function. The reasoning behind it is, an agent hits testssl.sh-in-a-container every day or so, captures the JSON output, and any changes trigger a message to me to look into my system configuration.

drwetter commented 5 years ago

I just tried this, and it seemed to do what I wanted: [..]

Ok, sounds good.

army1349 commented 5 years ago

Please, consider reopening. It is real pain in the ass for scripting and Zabbix integration would be so much nicer.

drwetter commented 5 years ago

Would you mind providing more input for your use case?

With the workaround from @virtadapt I thought everyone is kind of fine with it.

It'll probably not easy but I like to understand what would be useful.

army1349 commented 5 years ago

You are right, it is kind of ugly, but I can get json to stdout like this: testssl.sh --quiet --color 0 --jsonfile /dev/stderr example.com 2>&1 >/dev/null Then I can work with it comfortably, thanks.

drwetter commented 5 years ago

Anybody of you who want to add the workaround to the documentation in ~/doc ?

army1349 commented 4 years ago

So, after all, this does not work either. Error messages from OpenSSL are mixed with JSON, when connections is not successful. Named pipes are also not convenient, because JSON output has multiple EOF occurrences, so I am back to temp files...

drwetter commented 4 years ago

You could use any other file handledescriptor

testssl.sh --quiet --ssl-native --connect-timeout=1 --color 0 -p --jsonfile /dev/fd/4 testssl.sh:42 4>&1 2>/dev/null >/dev/null
[
         {
              "id"           : "scanProblem",
              "ip"           : "testssl.sh/81.169.166.184",
              "port"         : "42",
              "severity"     : "FATAL",
              "finding"      : "Can't connect to '81.169.166.184:33'\nMake sure a firewall is not between you and your scanning target!"
          }
,         {
              "id"           : "scanTime",
              "ip"           : "testssl.sh/81.169.166.184",
              "port"         : "42",
              "severity"     : "WARN",
              "finding"      : "Scan interrupted"
          }
]

Fifos also work fine for me:

# create a fifo
prompt% mkfifo /tmp/myfifo; tail -f /tmp/myfifo
# now in other window
prompt % testssl.sh --quiet --ssl-native --color 0 -p --jsonfile /tmp/myfifo example.com
prompt % testssl.sh --quiet --ssl-native --connect-timeout=1 --color 0 -p --jsonfile /tmp/myfifo testssl.sh:42  2>/dev/null >/dev/null
army1349 commented 4 years ago

Thanks, it works well with other handles. I tried FIFOs, it looks OK when using tail -f, but when you try cat, you will see the problem.

drwetter commented 4 years ago

Also with cat and a fifo both work like a charm for me:

prompt % testssl.sh --quiet --ssl-native --color 0 -p --jsonfile /tmp/myfifo example.com
prompt % testssl.sh --quiet --ssl-native --connect-timeout=1 --color 0 -p --jsonfile /tmp/myfifo testssl.sh:42  2>/dev/null >/dev/null
prompt% 

Other window: while true; do cat < /tmp/myfifo; done

army1349 commented 4 years ago

Yes, you can do that, but this will hang forever, same as tail -f. If JSON output was one text stream followed by EOF, everything would work nicely with just one cat.