I'm not married to either tool, I'm just hoping to find the fastest way to verify that all hosts in a list I pipe to either curl or wget are listening for HTTPS traffic on 443 rather than some other protocol that's set to 443 as a listener. I've got an egress filtering product that's about to drop support for that edge-case and would like to make any impacted teams aware.
I'm not particularly concerned if the host certificate is valid, as that's a problem for the app teams to talk with that vendor about or otherwise handle in their code.
Consider hosts as FQDNs in a file as,
Running this command on Linux,
cat list.txt | xargs -I{} bash -c "curl -m3 -k https://{}:443/ 1> /dev/null 2>&1 && echo {},yes || echo {},no"Produces the output as,
The
-m3option tocurlsets the maximum time spent before it would give up, and-kignores certificate validity. This command seems to reliably fail whenhttpsis not negotiated on the hardcoded port443.Note that depending on the openssl version your edition of curl was compiled against, it may not have support for TLS 1.1 and lower and will report a failed connection in cases where the host did not support at least TLS 1.2. Which, I suspect, for the purposes of your test, is as good as non-HTTPS.
It's sad to hear that an egress filtering product is dropping support for detecting the protocol and falling back on layer 3 constructs. In case you are looking for an alternative on AWS or GCP, I work for Chaser and we make one that goes well beyond just testing for modern TLS levels. Checks for spoofed headers, etc. as well. See DiscrimiNAT.