"OpenSSL SSL_read: SSL_ERROR_SYSCALL" with OpenSSL ≥ 3.2 + old servers

[mkauf]

I did this

When using a server that does not shut down the SSL connection properly (no "close notify"), depending on the OpenSSL version, curl reports an error when closing the connection. The problem has started to appear with OpenSSL 3.2.0 and is also present with OpenSSL 3.5.0.

I'm not sure whether this is a bug in curl or in OpenSSL. With git bisect I have found this OpenSSL commit: openssl/openssl@e2d5742

How to reproduce

The server is an openssl s_server 1.1.1 (or 1.0.2, same result). It does not send a "close notify" when closing the connection.

Create a certificate:

openssl genrsa -out server.key.pem 2048
openssl req -new -x509 -key server.key.pem -out server.crt.pem -days 365

Start openssl s_server:

openssl s_server -cert server.crt.pem -key server.key.pem -accept 8443 -www

With OpenSSL 3.0.16 + curl master (or curl 8.13.0, same result):

</BODY></HTML>

* shutting down connection #0

With OpenSSL 3.5.0 + curl master (or curl 8.13.0, same result):

curl -k -v https://localhost:8443/
...
</BODY></HTML>

* OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 0
* closing connection #0
curl: (56) OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 0

So no error is reported with OpenSSL 3.0 but an error is reported with OpenSSL 3.5.

Notes about the flag SSL_OP_IGNORE_UNEXPECTED_EOF

I have tried to set the OpenSSL flag SSL_OP_IGNORE_UNEXPECTED_EOF but the result is the same:

diff --git a/lib/vtls/openssl.c b/lib/vtls/openssl.c
index ffdae2399..f21f6140c 100644
--- a/lib/vtls/openssl.c
+++ b/lib/vtls/openssl.c
@@ -4109,6 +4109,7 @@ CURLcode Curl_ossl_ctx_init(struct ossl_ctx *octx,
     return CURLE_SSL_CONNECT_ERROR;
   }
 
+  ctx_options |= SSL_OP_IGNORE_UNEXPECTED_EOF;
   SSL_CTX_set_options(octx->ssl_ctx, ctx_options);
 
 #ifdef SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER

For openssl s_client, the flag -ignore_unexpected_eof works:

openssl s_client -crlf -ignore_unexpected_eof -connect localhost:8443
GET / HTTP/1.0
...
closed

It's strange that the flag works for openssl s_client but does not work for curl.

I expected the following

curl should not report an error with OpenSSL 3.5.0 + old servers, or there should be a way to ignore the error, e.g. with the OpenSSL flag SSL_OP_IGNORE_UNEXPECTED_EOF

curl/libcurl version

curl 8.14.0-DEV (x86_64-pc-linux-gnu) libcurl/8.14.0-DEV OpenSSL/3.2.4 zlib/1.3.1.zlib-ng nghttp2/1.64.0
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM SSL threadsafe TLS-SRP UnixSockets

operating system

Fedora Linux 42

[jay]

When using a server that does not shut down the SSL connection properly (no "close notify"), depending on the OpenSSL version, curl reports an error when closing the connection. The problem has started to appear with OpenSSL 3.2.0 and is also present with OpenSSL 3.5.0.

Generally if libcurl can successfully read all the content from a transfer then that transfer should not return an error even if there's a problem with the connection like bad server close. However, if there's no known termination point for the transfer (like no known content length, no chunked ending, no data stream end, etc) then libcurl just keeps reading. It may or may not need a close notify, which effectively becomes the termination point. It depends on the backend. We had (or have) compatibility stuff especially for OpenSSL but then when OpenSSL made plans to increase the strictness in OpenSSL 3 we (or maybe just I) decided to leave it alone. There's a thread on this but I can't find it so my recollection may be a little off.

there should be a way to ignore the error, e.g. with the OpenSSL flag SSL_OP_IGNORE_UNEXPECTED_EOF

I think that flag should work and can't think of why it doesn't. Maybe libcurl is now more strict about connection closures, apart from SSL backend.

[icing]

Agree with @jay here. And I believe in the case of https:, we do not fail the transfer if the response has http/1.1 termination.

Can you produce a trace with -vvvv of such an error? That would be helpful. Thanks.

[mkauf]

@icing

Can you produce a trace with -vvvv of such an error? That would be helpful. Thanks.

Trace with OpenSSL 3.0.x (no error): curl-vvvv-openssl-3.0.txt

Trace with OpenSSL 3.5.x (error): curl-vvvv-openssl-3.5.txt

I have used normal builds of curl. I have noticed that the results are different with debug builds. Example for OpenSSL 3.0.x:

curl: (56) OpenSSL SSL_read: Connection closed abruptly, errno 0 (Fatal because this is a curl debug build)

[icing]

@mkauf thanks for the logs. Th errored log shows that the server response is HTTP/1.0 without any content-length. This means the response is terminated by closing the connection. To detect a failure to not send the full response, we require that the TLS layer is closed down correctly. This is the intent of the TLS close notify.

A server that does not do that is not in line with the TLS specification. Had it sent a Content-Length: response header, curl would have trusted that and ignore the incorrect TLS close.

[mkauf]

@icing OK, but why are the results different with OpenSSL 3.0 and OpenSSL 3.5? Why does the flag SSL_OP_IGNORE_UNEXPECTED_EOF not have any effect?

Do you think that everything is fine, or is there an OpenSSL bug?

[mkauf]

The flag SSL_OP_IGNORE_UNEXPECTED_EOF has no effect because curl's function ossl_bio_cf_ctrl() returns wrong information to OpenSSL:

  case BIO_CTRL_EOF:
    /* EOF has been reached on input? */
    return !cf->next || !cf->next->connected;

This checks whether the socket is connected but does not check for EOF.

[mkauf]

Dummy "bugfix" for testing:

diff --git a/lib/vtls/openssl.c b/lib/vtls/openssl.c
index ffdae2399..3ae6062a4 100644
--- a/lib/vtls/openssl.c
+++ b/lib/vtls/openssl.c
@@ -699,8 +699,7 @@ static long ossl_bio_cf_ctrl(BIO *bio, int cmd, long num, void *ptr)
     break;
 #ifdef BIO_CTRL_EOF
   case BIO_CTRL_EOF:
-    /* EOF has been reached on input? */
-    return !cf->next || !cf->next->connected;
+    return 1;
 #endif
   default:
     ret = 0;

With this, the error message is the same with OpenSSL 3.0 + 3.5:

curl: (56) OpenSSL SSL_read: OpenSSL/3.0.17: error:0A000126:SSL routines::unexpected eof while reading, errno 0

[mkauf]

@jay

There's a thread on this but I can't find it

I have found #4624 and commit 78cef06.

@icing

we require that the TLS layer is closed down correctly.

We require it only in debug builds (see commit 78cef06), but this broke somehow with OpenSSL 3.2. Maybe it's time to require it in all builds?

[icing]

@mkauf can you check of #17526 works correctly in your setup? Thanks.

As to the switch in non-debug behaviour, I am for it in principle, but uncertain what breakage we might induce with it.

[mkauf]

@icing The PR #17526 works correctly :-) After applying it, the behavior with OpenSSL 3.0 and 3.5 is the same:

curl: (56) OpenSSL SSL_read: OpenSSL/3.0.17: error:0A000126:SSL routines::unexpected eof while reading, errno 0

For users of OpenSSL 3.0, the PR introduces a behavior change. I think that we have multiple options:

• decide that curl should not ignore the unexpected EOF. Remove the special "debug build" behavior because that does not work anymore. [Update: The special "debug build" behavior still does work with OpenSSL 1.1.1]
• decide that curl should ignore the unexpected EOF and set the flag SSL_OP_IGNORE_UNEXPECTED_EOF
• add a flag to CURLOPT_SSL_OPTIONS to control the behavior, maybe also for the command line tool

I would choose the first option because that seems to be best practice. But others may disagree, see #4624