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
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Ray Satiro via curl-library <curl-library_at_cool.haxx.se>
Date: Sat, 13 Mar 2021 01:10:15 -0500
On 3/12/2021 11:27 PM, Jacob Hoffman-Andrews via curl-library wrote:
> In https://github.com/curl/curl/issues/4624
> <https://github.com/curl/curl/issues/4624> 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
> (https://tools.ietf.org/html/rfc8446#section-6.1
> <https://tools.ietf.org/html/rfc8446#section-6.1>), 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
> `CURLOPT_SSL_*` option? E.g. `CURLOPT_SSL_ALLOW_INSECURE_CLOSE`? It
> 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.
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-03-13
Date: Sat, 13 Mar 2021 01:10:15 -0500
On 3/12/2021 11:27 PM, Jacob Hoffman-Andrews via curl-library wrote:
> In https://github.com/curl/curl/issues/4624
> <https://github.com/curl/curl/issues/4624> 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
> (https://tools.ietf.org/html/rfc8446#section-6.1
> <https://tools.ietf.org/html/rfc8446#section-6.1>), 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
> `CURLOPT_SSL_*` option? E.g. `CURLOPT_SSL_ALLOW_INSECURE_CLOSE`? It
> 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.
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-03-13