[BUG / possible BUG] Huge delay on WSL (Arch and also NixOS)

[lapo-luchini]

• I am running version e0af44a7be4c02da86c0f6e93ad9008841fc02b7 from the git repo
• I am running testssl.sh -v | grep from

Before you open an issue please consult the FAQ and check whether this is a known problem by searching the issues

• couldn't find anything

Command line to reproduce (or docker command)

testssl.sh google.com

and in other console:

% ps auxf | grep -A20 testssl
lapo       76824  1.0  0.0  16048 12160 pts/5    S+   14:02   0:00  |           \_ bash /home/lapo/bin/testssl.sh google.com
lapo       76934  0.0  0.0  14796  9472 pts/5    S+   14:02   0:00  |               \_ /usr/sbin/openssl s_client -tls1
lapo       76935  0.0  0.0   6812  2432 pts/5    S+   14:02   0:00  |               \_ grep -aiq unknown option

(but it also happens with testssl.sh -v really!)

Expected behavior

An immediate response to testssl.sh -v and even when reporting remote websites, the header should appear pretty soon. (then the complete report can take the time it takes)

Your system (please complete the following information):

• OS: Arch Linux (under Windows 11 WSL), but same on NixOS 25.11 (Xantusia) (WSL)
• Platform: Linux 6.6.87.2-microsoft-standard-WSL2 x86_64
• OpenSSL + bash: unknown (takes a looong time also to do testssl.sh -b

Additional context

I am willing to debug the issue… I already tried DEBUG=5, or bash -vx (it stops after redirecting stderr to 42), or strace but I failed to undestand th eproblem.

[drwetter]

Hi @lapo-luchini ,

as the doc says you can run ./testssl.sh --debug NUMBER TARGET then you see approximately where it's hanging. Sluggish upon -b / -v is rather strange.

You can also prepend SETX=true bash -x ./testssl.sh COMMAND but there's more output. Maybe a start for that is SETX=true bash -x ./testssl.sh -v.

Can you run time ./testssl.sh -v and report back how long it takes?

[lapo-luchini]

Just a bit more than 20 minutes:

% time ./testssl.sh -v | ts %H:%M:%S
14:18:28
14:38:45
14:38:45 #####################################################################
14:38:45   testssl.sh version 3.3dev from https://testssl.sh/dev/
14:38:45   (e0af44a 2026-06-10 14:11:14)
14:38:45
14:38:45   This program is free software. Distribution and modification under
14:38:45   GPLv2 permitted. USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!
14:38:45
14:38:45   Please file bugs @ https://testssl.sh/bugs/
14:38:45 #####################################################################
14:38:45
14:38:45   Using OpenSSL 3.6.2 (Apr 20 2026)  [~96 ciphers]
14:38:45   on cyberone-wsl:/usr/sbin/openssl
14:38:45   built: Mon Apr 20 16:11:24 2026, platform: linux-x86_64
14:38:45   Using bash 5.3.12
14:38:45
./testssl.sh -v  0.15s user 0.18s system 0% cpu 20:16.92 total

[lapo-luchini]

Since it stops on the command openssl s_client -tls1 I checked the man openssls_client which states:

     -connect host:port
         This specifies the host and optional port to connect to. It is possible to select the host and
         port using the optional target positional argument instead.  If neither this nor the target po‐
         sitional argument are specified then an attempt is made to connect to the local host on port
         4433.  If the host string is an IPv6 address, it must be enclosed in "[" and "]".

I guess I have a local firewall that stops that connection which thus receives no TCP "port closed" answer (TCP RST) and rather wait for a very very long timeout.

[lapo-luchini]

Basically it is a 2 minutes timeout on each call to test for parameters:

% SETX=true bash -x ./testssl.sh -v 2>&1 | ts %H:%M:%S
[...]
14:41:03 |21309>        find_openssl_binary(): OSSL_CIPHERS_S=-s
14:41:03 |21311>        find_openssl_binary(): /usr/sbin/openssl s_client -ssl2
14:41:03 |21311>        find_openssl_binary(): grep -aiq 'unknown option'
14:41:03 |21312>        find_openssl_binary(): /usr/sbin/openssl s_client -ssl3
14:41:03 |21312>        find_openssl_binary(): grep -aiq 'unknown option'
14:41:03 |21313>        find_openssl_binary(): /usr/sbin/openssl s_client -tls1
14:41:03 |21313>        find_openssl_binary(): grep -aiq 'unknown option'
14:43:17 |21313>        find_openssl_binary(): HAS_TLS1=true
14:43:17 |21314>        find_openssl_binary(): /usr/sbin/openssl s_client -tls1_1
14:43:17 |21314>        find_openssl_binary(): grep -aiq 'unknown option'
14:45:32 |21314>        find_openssl_binary(): HAS_TLS11=true
14:45:32 |21315>        find_openssl_binary(): /usr/sbin/openssl s_client -tls1_2
14:45:32 |21315>        find_openssl_binary(): grep -aiq 'unknown option'
14:47:47 |21315>        find_openssl_binary(): HAS_TLS12=true
14:47:47 |21316>        find_openssl_binary(): /usr/sbin/openssl s_client -tls1_3
14:47:47 |21316>        find_openssl_binary(): grep -aiq 'unknown option'
14:50:02 |21316>        find_openssl_binary(): HAS_TLS13=true
14:50:02 |21317>        find_openssl_binary(): /usr/sbin/openssl s_client -no_ssl2
14:50:02 |21317>        find_openssl_binary(): grep -aiq 'unknown option'
[...]

[drwetter]

The lines do a check openssl capabilities. They use a variable NXDNS for a connect which defaults to "invalid.", under WSL the checks should use 127.0.0.1:0 instead.

Can you run NXDNS=127.0.0.1:0 ./testssl.sh -v and let me know whether it's faster?

[lapo-luchini]

Uhmmm… changes nothing, but I'm not sure that's used, as judging from the logs looks like I'm stopping at line 21313, while NXDNS isn't used until shortly later, at line 21327.

PS: please know that I'm using WSL2 in "bridged" mode (in order to have IPv6 connectivity), which might be different that usual WSL2 networking is behaving.

[drwetter]

Sorry, my bad. Screen too small.

Any clues why /usr/sbin/openssl s_client -tls1_2 takes an eternity (maybe use strace to find out what is going on?)

[lapo-luchini]

It seems to be trying to connect to [::1]:443, immediately failing, and then to 127.0.0.1:4433, hanging there.

% strace openssl s_client -tls1
[...]
close(3)                                = 0
socket(AF_INET6, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET6, sin6_port=htons(4433), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_scope_id=0}, 28) = 0
getsockname(3, {sa_family=AF_INET6, sin6_port=htons(43727), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_scope_id=0}, [28]) = 0
connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(4433), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
getsockname(3, {sa_family=AF_INET6, sin6_port=htons(47109), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::ffff:127.0.0.1", &sin6_addr), sin6_scope_id=0}, [28]) = 0
close(3)                                = 0
socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = 3
ioctl(3, FIONBIO, [0])                  = 0
setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
connect(3, {sa_family=AF_INET6, sin6_port=htons(4433), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_scope_id=0}, 28) = -1 ECONNREFUSED (Connection refused)
close(3)                                = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
ioctl(3, FIONBIO, [0])                  = 0
setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(4433), sin_addr=inet_addr("127.0.0.1")}, 16

[lapo-luchini]

It seems like it times out on any unavailable port, while it's quite fast on an existing and open port:

% time openssl s_client -tls1 -connect 127.0.0.1:22
Connecting to 127.0.0.1
CONNECTED(00000003)
[...]
openssl s_client -tls1 -connect 127.0.0.1:22  0.01s user 0.00s system 14% cpu 0.072 total
% time openssl s_client -tls1 -connect 127.0.0.1:4433
openssl s_client -tls1 -connect 127.0.0.1:4433  0.01s user 0.00s system 0% cpu 2:14.70 total

[lapo-luchini]

What if we changed the test to check the output of the help?

% openssl s_client -help 2>&1 | fgrep " -tls1 "
 -tls1                      Just use TLSv1

I could create a PR for that, if you think that would be fine.

[drwetter]

What if we changed the test to check the output of the help?

IIRC we had that before and for a reason I can't remember right now we changed that.

two possibilities:

• reconsidering that for every platform / find out why we changed that
• find a WSL specific solution.

For the latter: Can you look into your environment whether there is a hint we can use to identify WSL?

We have in find_openssl_binary() a detection which I am not sure it still works:

    elif [[ -e "/mnt/c/Windows/System32/bash.exe" ]] && test_openssl_suffix "$(dirname "$(type -p openssl)")"; then
          # 2. otherwise, only if on Bash on Windows, use system binaries only.
          SYSTEM2="WSL"
          # Workaround for delayed responses of Windows DNS when using "invalid.", see #1738, #1812.
          [[ $NXDNS == invalid. ]] && NXDNS=127.0.0.1:0

We could use a similar statement then like openssl s_client -tls1 -connect 127.0.0.1:0.

[lapo-luchini]

In my own devops scripts I often have to detect WSL… I had various variations, broken in time; te latest and most stable seems to be this one:

if grep -qi microsoft /proc/version; then

Unfortunately 127.0.0.1:0 still times out. :(

I'm looking myself for a way to do that reliably on WSL (and maybe create a PR out of it), but I didn't find anything (except parsing -help) really working, except assuming 127.0.0.1:22 is open because of sshd, but I dislike that…