Question: ERROR: returned an error: sending request: SSL error: ssl_write_all 29527: 1 - ERROR_SYSCALL

[drwetter]

This is not really a bugreport. But I would love to understand what's going on.

I have a host (HTTPS) to scan which frequently returns

E:Tue Sep 15 20:47:32 2020 + ERROR:  returned an error: sending request: SSL error: ssl_write_all 29527: 1 - ERROR_SYSCALL(-1,5) :

E:Tue Sep 15 20:47:32 2020 + ERROR:  returned an error: sending request: SSL error: ssl_write_all 29527: 1 - ERROR_SYSCALL(-1,5) :

E:Tue Sep 15 20:47:32 2020 + ERROR:  returned an error: sending request: SSL error: ssl_write_all 29527: 1 - ERROR_SYSCALL(-1,5) :

E:Tue Sep 15 20:47:33 2020 + ERROR:  returned an error: sending request: SSL error: ssl_write_all 29527: 1 - ERROR_SYSCALL(-1,5) :

E:Tue Sep 15 20:47:33 2020 + ERROR:  returned an error: sending request: SSL error: ssl_write_all 29527: 1 - ERROR_SYSCALL(-1,5) :

E:Tue Sep 15 20:47:33 2020 + ERROR:  returned an error: sending request: SSL error: ssl_write_all 29527: 1 - ERROR_SYSCALL(-1,5)

Look like this error is thrown in LW2.pm.

tcpdump is telling me the server side sends a TCP reset on a ClientHello. This is not every request in the pcap file.

One thing which puzzles me is in debugging mode the JSON object typically tells me there's no cipher:

 D:Tue Sep 15 21:04:16 2020 'Result Hash' = {
        'whisker' => {
                'ssl_cipher' => '(NONE)',
                'uri' => '/dpa.alz',
                'MAGIC' => 31340,
                'error' => "sending request: SSL error: ssl_write_all 29606: 1 - ERROR_SYSCALL(-1,5) : \n"
        }

which is probably not true if the ClientHellos before the TCP resets are to blame. Q1: Why do I see here no ssl_cipher?

The ClientHello before the TCP reset looks on the first glance ok, I haven't done a side by side comparison with another ClientHello for which I get a proper response yet. Both look like a TLS 1.3 handshake.

The TCP resets don't happen every time.

Scan host is Debian 10. Target is Windows Server 2012 or 2012 R2 or Windows Server 2016.

Q2: has anybody else seen that? (no, I don't think here's a middle box or an IPS/IDS the culprit).

Cheers, Dirk

[iasdeoupxe]

Q1: Why do I see here no ssl_cipher?

If the server doesn't send a ServerHello including the negotiated ciphers how should the Result (Result Hash) contain a cipher?

Without a ServerHello no communication / cipher was negotiated so the 'ssl_cipher' => '(NONE)', looks fine to me.

[sullo]

I have been having this problem on one one Mac, but I also have the same issue using curl. On the Mac I've chalked it up to Apple vs OpenSSL versions vs Homebrew.

@drwetter what platform was this?

[drwetter]

probably Debian 10