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
