Re: "server closed abruptly (missing closed notify)" with WinSSL but not OpenSSL

On 6/15/2019 1:18 PM, Ray Satiro via curl-library wrote:
> On 6/14/2019 7:51 PM, Josh Handley via curl-library wrote:
>> I'm using libcurl 7.65.1/WinSSL to send a GET request to an Apache
>> server endpoint to download some JSON. On one particular server (it is
>> running Apache 2.4.6 on Red Hat Enterprise) I'm getting
>> CURLE_RECV_ERROR. Running with the debug callback I see messages from
>> schannel that the server has closed the connection abruptly (see
>> below). The same request works fine when using curl built with
>> OpenSSL. Even with WinSSL this works with other Apache servers. Other
>> GET endpoints on the server are working correctly although those have
>> smaller responses. Looking at the debug info I can see that the full
>> response is downloaded and decrypted before I get the error. Any ideas
>> on what could be the cause? Any Apache configuration or libcurl
>> changes I could try to remedy this?
> It appears there is no known termination point (content length or
> chunked encoding) in the server reply and so in that case curl will keep
> reading until the server closes the connection. Note the "HTTP 1.0,
> assume close after body". Since it is an SSL connection curl w/schannel
> will look for a close_notify alert from the server (another accepted
> termination point). However in your case the SSL connection appears to
> be closed unclean (ie no close_notify) therefore there's no known
> termination point. I made that an error in schannel to avoid a
> truncation attack (when an attacker can prematurely terminate a
> connection to cause a truncated file which may cause some purpose not
> intended). I think most other SSL backends it is also an error but for
> legacy reasons we don't do the same for OpenSSL and maybe some other.
> Eventually I hope to change this for OpenSSL as well but only for the
> newest version to phase it out but not break anything.
>
> As far as I am concerned this is a server issue, it needs to give any
> termination point discussed.
>
>
Thanks for the explanation. The information was quite helpful. That
totally makes sense since the other endpoints that are working correctly
all have the content-length header.

We were able to resolve the issue on the problematic server by setting
"ssl-accurate-shutdown" in the Apache config.

I was also able to reproduce the issue on my own test server by setting
"ssl-unclean-shutdown" in the Apache config. On that test server, I
modified the PHP script for the endpoint to use chunked transfers and
even with the "ssl-unclean-shutdown" setting libcurl handled the
response with no error.

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2019-06-17