curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: Handling TCP connection shutdown without TLS close_notify

From: Ray Satiro via curl-library <>
Date: Sat, 13 Mar 2021 01:10:15 -0500

On 3/12/2021 11:27 PM, Jacob Hoffman-Andrews via curl-library wrote:
> In
> <> there is some discussion
> about what to do when a TCP connection is closed without the TLS peer
> sending a close_notify alert first. Close_notify is meant to protect
> against truncation attacks
> (
> <>), and as of TLS 1.3
> it's mandatory for the peer to send before closing the connection.
> I'm trying to decide what to do for this situation in the rustls
> backend. It seems like it's still fairly common for some TLS servers
> to exhibit this behavior. I'm leaning towards doing the more-secure
> thing by default, and treating abrupt TCP connection shutdown as an
> error. But it may turn out that someone needs to interoperate with a
> TLS 1.2 server that abruptly terminates connections.
> Is this the sort of thing that would be appropriate as a
> could have values "true", "false", and "default", which would depend
> on the backend: true for OpenSSL, false for rustls.

Truncation attacks can only occur without error when there's no known
termination point. Most of the time you're going to get a content length
or chunked encoding so you can tell the transfer is done. As you've seen
we are allowing a missing close notify for the OpenSSL backend. OpenSSL
3 (currently in alpha) plans to make it an error, so I assume curl will
then error. That is acceptable. Their 1.1.1 LTS build is supported until
like 2023? so if users have that problem they can stay with LTS.

I would make it an error. If it's really a problem we can address it
later in an option, but I would not spend any time on that now.

Received on 2021-03-13