curl 7.67.0 w/OpenSSL: Missing TLS shutdown from server may cause error #4624
Comments
|
Hm, that change was inadvertent on my behalf back then, as it was only intended to improve the error messages for the syscall case, not actually change behavior... |
|
Interesting. I think I'm seeing the same error when sending a GET request to api.bitbucket.org with Basic Auth headers. Though the site is hosted on Bluehost, so maybe that's it. cURL version | 7.67.0 OpenSSL/1.0.2t |
|
Getting same error "CURL Error: 56" on Linux server using curl 7.67.0.. |
- 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
|
This is a very specific case of error 56 where the error message will say there is "No error" or "Success". For reference please include your curl -V and the URL if it is public. |
|
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 issue is for a very specific error, "No error" / "Success" is shown in the error message. As I mentioned in the other thread SYSCALL errors are almost invariably due to server or network issues. |
|
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. |
|
Fix landed but leaving open for now to minimize dupes. |
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 <johannes.schindelin@gmx.de>
|
Closing now as this is now fixed in a shipped release. |
|
@bagder in which release is this fix included? 7.68.0? |
|
yes, 7.68.0 |
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).
It has only been reported once so far, so we can assume it affects very few users.Update: Fixed in 78cef06, the extra sensitivity is now disabled except in debug builds. If you are using 7.67.0 you may either cherry-pick that commit from the repo or apply it as a patch.
I did this
@bjo81 reports error
curl: (56) OpenSSL SSL_read: Successat the end of transfer of https://www.presseportal.deI 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/libcurl version
curl 7.67.0 (i386-pc-win32) libcurl/7.67.0 OpenSSL/1.0.2t nghttp2/1.40.0
curl: (56) OpenSSL SSL_read: No error
curl 7.67.0 (i386-pc-win32) libcurl/7.67.0 wolfSSL/4.2.0 nghttp2/1.40.0
(exit code 0)
curl 7.67.0 (i386-pc-win32) libcurl/7.67.0 Schannel WinIDN
curl: (56) Failure when receiving data from the peer
operating system
Windows 7 Enterprise
The text was updated successfully, but these errors were encountered: