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,
$ cat list.txt
hotmail.com
google.com
cloudflare.com
127.0.0.1
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,
hotmail.com,yes
google.com,yes
cloudflare.com,yes
127.0.0.1,no
The -m3 option to curl sets the maximum time spent before it would give up, and -k ignores certificate validity. This command seems to reliably fail when https is not negotiated on the hardcoded port 443.
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.