我没有使用任何一个工具,我只是希望找到最快的方法来验证我通过管道传输到curl或wget的列表中的所有主机是否正在侦听443上的HTTPS流量,而不是设置为的其他协议443作为听众。我有一个出口过滤产品,即将放弃对这种边缘情况的支持,并希望让任何受影响的团队意识到这一点。
我并不特别关心主机证书是否有效,因为这是应用程序团队与该供应商讨论或在其代码中以其他方式处理的问题。
将主机视为文件中的 FQDN,
$ cat list.txt
hotmail.com
google.com
cloudflare.com
127.0.0.1
在 Linux 上运行此命令,
cat list.txt | xargs -I{} bash -c "curl -m3 -k https://{}:443/ 1> /dev/null 2>&1 && echo {},yes || echo {},no"
产生输出为,
hotmail.com,yes
google.com,yes
cloudflare.com,yes
127.0.0.1,no
-m3
的 curl
选项设置放弃之前花费的最长时间,并且 -k
忽略证书有效性。当 https
未在硬编码端口 443
上协商时,此命令似乎会可靠地失败。
请注意,根据您编译的curl版本所针对的openssl版本,它可能不支持TLS 1.1及更低版本,并且在主机不支持至少TLS 1.2的情况下将报告连接失败。我怀疑,为了您的测试目的,它与非 HTTPS 一样好。
听说出口过滤产品正在放弃对检测协议的支持并退回到第 3 层结构,这令人遗憾。如果您正在 AWS 或 GCP 上寻找替代方案,我在 Chaser 工作,我们制作的产品远远超出了现代 TLS 级别的测试范围。还检查欺骗标头等。请参阅DiscrimiNAT。