Docs Overview
Project
Bug Bounty Bug Report Code of conduct Dependencies Donate FAQ Features Governance History Install Known Bugs Logo TODO Web Site Info
Protocols
alt-svc CA Extract HSTS HTTP cookies HTTP/2 HTTP/3 MQTT SSL certs SSL libs compared URL syntax WebSocket
Releases
Changelog curl CVEs Release Table Version Nums Vulnerabilities
Tool
Comparison Table curl man page HTTP Scripting mk-ca-bundle Tutorial When options were added
Who and Why
Companies Copyright Sponsors Thanks The name
curl / Docs / curl CVEs / TLS 1.3 session ticket proxy host mix-up
Related:
Audits
Bug Bounty
Changelog
curl CVEs
JSON metadata
Original report
Vulnerability Disclosure
Vulnerabilities Table

CVE-2021-22890

TLS 1.3 session ticket proxy host mix-up

Project curl Security Advisory, March 31st 2021 - Permalink

VULNERABILITY

Enabled by default, libcurl supports the use of TLS 1.3 session tickets to resume previous TLS sessions to speed up subsequent TLS handshakes.

When using a HTTPS proxy and TLS 1.3, libcurl can confuse session tickets arriving from the HTTPS proxy but work as if they arrived from the remote server and then wrongly "short-cut" the host handshake. The reason for this confusion is the modified sequence from TLS 1.2 when the session ids would provided only during the TLS handshake, while in TLS 1.3 it happens post hand-shake and the code was not updated to take that changed behavior into account.

When confusing the tickets, a HTTPS proxy can trick libcurl to use the wrong session ticket resume for the host and thereby circumvent the server TLS certificate check and make a MITM attack to be possible to perform unnoticed.

This flaw can allow a malicious HTTPS proxy to MITM the traffic. Such a malicious HTTPS proxy needs to provide a certificate that curl will accept for the MITMed server for an attack to work - unless curl has been told to ignore the server certificate check.

INFO

It can only trigger when TLS 1.3 is used with the HTTPS proxy and not with earlier TLS versions. It cannot trigger with TLS 1.2 or earlier versions.

It might be worth highlighting that an HTTPS proxy is a proxy which libcurl communicates with over TLS specifically, and then speaks HTTPS through, making it two layers of TLS. It is different than the more common HTTP proxy setup, where libcurl just does normal TCP with the proxy.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2021-22890 to this issue.

CWE-290: Authentication Bypass by Spoofing

Severity: Low

AFFECTED VERSIONS

This issue only exists when libcurl is built to use OpenSSL or one of its forks.

Also note that libcurl is used by many applications, and not always advertised as such.

SOLUTION

Make sure the proxy/host distinction is done correctly.

RECOMMENDATIONS

We suggest you take one of the following actions immediately, in order of preference:

A - Upgrade libcurl to version 7.76.0

B - Apply the patch to your local version

C - Use another TLS backend

D - Avoid TLS 1.3 with HTTPS proxies

TIMELINE

This issue was reported to the curl project on March 17, 2021.

This advisory was posted on March 31st 2021.

CREDITS

Thanks a lot!