curl/libcurl vulnerable to TLS truncation attacks

How it was found

Summary:

curl/libcurl doesn't enforce "Closure Alerts" [1][2] for protocols that have no knowledge of the size of the transmitted data. This enables truncation attacks where the attacker in a meddler-in-the-middle position closes the connection prematurely. This results in partial file being downloaded without curl/libcurl being aware of the truncation.

Currently vulnerable protocols are at least:

• gophers://
• ldaps://
• pop3s://
• rtsps://

Remaining TLS protocols are vulnerable if CURLOPT_IGNORE_CONTENT_LENGTH is used:

• https://
• ftps://
• imaps://

Arguably when this option is used the loss of security is desired. If this is intended behaviour, the lessened security should be documented.

Steps To Reproduce:

1. Initiate curl/libcurl download over TLS (for example pop3s://)
2. Perform man in the middle attack and terminate the connection
3. Partial file will be downloaded

The problem can be reproduced for https:// with for example:

1. `socat -v -x openssl-listen:8445,reuseaddr,fork,key=/etc/letsencrypt/live/example.tld/privkey.pem,cert=/etc/letsencrypt/live/example.tld/fullchain.pem,verify=0 stdout
2. curl --output out.txt --ignore-content-length --remove-on-error https://example.tld:8445 && echo OK
3. In socat, enter HTTP/1.1 200 OK <return>
4. In socat, enter Content-Length: 200 <return>
5. In socat, enter hello<return>
6. Send CTRL-C to socat

Note that "OK" is printed and that out.txt file contains hello

Supporting Material/References:

[1] TLS 1.2 "Closure Alerts" - https://www.rfc-editor.org/rfc/rfc5246#section-7.2.1 [2] TLS 1.3 "Closure Alerts" - https://www.rfc-editor.org/rfc/rfc8446#section-6.1

Remediation

To ensure secure communications the Closure Alert should be required in case the content length is not available. An option to allow insecure operation is likely needed to allow communicating with non-compliant (and thus insecure) servers.

Impact

Truncated file transfer