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.
Handling TCP connection shutdown without TLS close_notify
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Jacob Hoffman-Andrews via curl-library <curl-library_at_cool.haxx.se>
Date: Fri, 12 Mar 2021 20:27:04 -0800
In 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), 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.
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-03-13
Date: Fri, 12 Mar 2021 20:27:04 -0800
In 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), 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.
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-03-13