Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
curl 7.67.0 w/OpenSSL: Missing TLS shutdown from server may cause error #4624
If an SSL transfer is made from curl 7.67.0 w/ OpenSSL and the server terminates the connection without giving an acceptable protocol termination point (eg in HTTP would be Content Length or chunked) and without the TLS termination point (close_notify alert), then curl error 56 may occur and the associated error message may contain text such as Success or No error.
Other SSL backends such as Schannel (Windows OS native SSL) have stricter behavior where we require a termination point, but I don't believe it was @bagder's intention to do this yet for OpenSSL (presumably because of the wide user base and compatibility).
I did this
I am able to reproduce in Windows using curl-7_67_0 but the error message is different, likely due to OS differences:
(In other words socket error is 0.)
SSL_read fails and then SSL_get_error() returns SSL_ERROR_SYSCALL because the server closed the connection without a proper shutdown (ie != SSL_ERROR_ZERO_RETURN). Prior to 0ab38f5 SSL_ERROR_SYSCALL on its own wasn't an error during SSL_read.
SYSCALL is not directly linked to a socket error, therefore the socket error may be 0. That may happen --as it does in this case-- when a server does not have a known termination point and no close_notify is sent, instead the connection is closed.
I expected the following
Debatable. IMHO technically it is correct to pass on the error, but if we were going to make this change I expected it to be rolled out slowly to only dev builds at first and let it marinate. This may be a breaking change for some users. And I don't like that the error text if the socket error is 0 may be "no error" or "success", that's sure to confuse.
Suggested remedy is disable this behavior for release builds, see #4623.
curl 7.67.0 (i386-pc-win32) libcurl/7.67.0 OpenSSL/1.0.2t nghttp2/1.40.0
curl 7.67.0 (i386-pc-win32) libcurl/7.67.0 wolfSSL/4.2.0 nghttp2/1.40.0
curl 7.67.0 (i386-pc-win32) libcurl/7.67.0 Schannel WinIDN
Windows 7 Enterprise
- Disable the extra sensitivity except in debug builds (--enable-debug). - Improve SYSCALL error message logic in ossl_send and ossl_recv so that "No error" / "Success" socket error text isn't shown on SYSCALL error. Prior to this change 0ab38f5 (precedes 7.67.0) increased the sensitivity of OpenSSL's SSL_ERROR_SYSCALL error so that abrupt server closures were also considered errors. For example, a server that does not send a known protocol termination point (eg HTTP content length or chunked encoding) _and_ does not send a TLS termination point (close_notify alert) would cause an error if it closed the connection. To be clear that behavior made it into release build 7.67.0 unintentionally. So far there is just one user report due to it. Ultimately the idea is a good one, and other SSL backends may already behave similarly (such as Windows native OS SSL Schannel). However much more of our user base is using OpenSSL and there is a mass of legacy users in that space, so I think that behavior should be partially reverted and then rolled out slowly. This commit changes the behavior so that the increased sensitivity is disabled in all curl builds except curl debug builds (DEBUGBUILD). If after a period of time there are no major issues then it can be enabled in dev and release builds with the newest OpenSSL (1.1.1+). Bug: curl#4409 (comment) Reported-by: Bjoern Franke Fixes curl#4624 Closes curl#4623
As is said in the other issue request:
I think it's an error related to WinSockets that the socket is closed while curl / OpenSSH tries to use the socket again. For me the problem only seems to be appearing on POST or custom requests like PUT, DELETE and only if there are two or more requests are send right after the other is finished and got data. If i insert a sleep with at least 0.5 seconds between the return and the second request it works.
If i set the CURLOPT_FRESH_CONNECT option it works for me too. Thats why i think it has something todo with reused sockets which are closed to early.
This is the error I receive when making a GET request using Basic Auth headers to api.bitbucket.org from my site.
The site is hosted on Bluehost. Similar error if I try the same GET request from another site on same host.
These requests were working fine a few days ago.
When reading from their gitweb, cURL exits with exit code 56 and this error message: $ curl -o /tmp/a1 "https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=tags" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 206k 0 206k 0 0 346k 0 --:--:-- --:--:-- --:--:-- 346k curl: (56) OpenSSL SSL_read: No error There is actually no error, but apparently the server is configured incorrectly, hitting this bug: curl/curl#4624 Let's just work around this by ignoring the exit code 56 (and leisurely update cURL to take the fix indicated in the ticket). Signed-off-by: Johannes Schindelin <firstname.lastname@example.org>