[BUG / possible BUG] TestSSL hangs on while doing STARTTLS Scan without DNS Resolution on XMPP Port not running XMPP

[TTH-Someone-stole-my-name]

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 3.0.8. I could not find any open issue mentioning this, but there is a comment in testssl.sh Line 11286 indicating that this might be at least a potentially known problem:

# This seems a bit dangerous but works. No blockings yet. "if=nonblock" doesn't work on BSDs
     buffer="$(dd bs=512 count=1 <&5 2>/dev/null)"

Problem Description

I am sorry to report that in my situation, a block actually occurred resulting in my testssl.sh scan to hang indefinitely. I encountered the issue during a batch scan based on an greppable nmap file while using the option --nodns min that contained a host with an open TCP Port 5222. Testssl correctly identified this port as a potential XMPP port and attempted a STARTTLS scan. This particular host however has their SSH-Port moved to 5222, meaning that STARTTLS for XMPP never gets a response, resulting in a locked state. There is no timeout to abort the scan, testssl just keeps waiting forever.

I managed to reproduce the behavior with the following command: testssl --nodns min -e -P --starttls xmpp XXX.XXX.XXX.XXX

Expected Behavior

The scan should fail after at most the 2 minutes just like other hanging connections and report that this port is most likely not a STARTTLS enabled port.

Solution

I understand this this is a corner case because I disabled DNS resolution while doing a bulk scan of an entire network, but it is still annoying that the scan I left to run overnight just hung at at some point and never continued. I temporarily solved the issue by just manually adding the option if=nonblock to the dd command as mentioned in the comment.
But since the issue annoyed me, I am willing to dedicate some time to resolve it permanently. Currently, I see two ways of going about that and would like some feedback on what your preferred approach would be?

1. Check if testssl is running on Linux and if yes, add the if=nonblock option. This would only resolve the issue for Linux users. Is there an alternative option one could specify for BSD users to also fix the issue for them?
2. Wrap the entire "dd" command in a timeout (similarly to how connect timeouts work)

[drwetter]

Hi @TTH-Someone-stole-my-name ,

thanks for reporting!

I am afraid that such border cases are not very good handled by this project.

wrt1: maybe unblock works but it would require cbs to be specified. If you like you can test it and report back whether it works. PS: I am hesitant to use checks for a specific OS like with uname. Preferred is checking whether a binary supports an option. The idea is that under any OS you can probably use ~any binary. Lets figure that out here though when we think 1 is the right approach.

2. yup.

There's also an option 3: either use sockread() or put dd in the background like sockread() does.

Would you mind a) sending me (SWCONTACT in testssl.sh) the host IP and b) confirm you're using Linux? And c) confirm that the --nodns option doesn't matter?

Cheers, Dirk