Buy commercial curl support. 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 Daniel himself.
Re: HSTS cache cap allows eviction of security entries
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Demi Marie Obenour <demiobenour_at_gmail.com>
Date: Thu, 2 Apr 2026 10:42:23 -0400
On 4/1/26 17:02, Jeffrey Walton via curl-library wrote:
> On Wed, Apr 1, 2026 at 4:55 PM Daniel Stenberg via curl-library
> <curl-library_at_lists.haxx.se> wrote:
>>
>> Hey,
>>
>> Today I implemented a cap in how many HSTS entries libcurl keeps in memory, to
>> prevent it from being a never-ending growth that could eventually cause
>> problems. I set the limit to 1000 entries, quite arbitrarily.
>>
>> The oldest entry gets evicted when more are added.
>>
>> This can however, perhaps, have an effect on security if someone happens to
>> load countless pages with HSTS and the list adds up. Or as one of our AI code
>> analyzers expressed it:
>>
>> The new hsts_append() drops the oldest HSTS entry once the list reaches
>> MAX_HSTS_ENTRIES. Because curl only upgrades HTTP to HTTPS when an HSTS entry
>> is present, an attacker who can coerce a client into visiting many unique
>> HTTPS hosts with HSTS headers (for example via redirect chains under their
>> control) can evict previously stored HSTS policies. Once the target entry is
>> evicted, subsequent HTTP URLs to that host will no longer be upgraded,
>> opening a downgrade window for MITM. This is a security regression compared
>> to the previous unlimited retention.
>>
>> It seems correct, but is this anything we can actually protect against? Having
>> an unlimited cache in memory seems like a bad idea as well...
>
> Instead of a machine wide implementation, perhaps the HSTS cache can
> be per-app. Then the app can select a policy:
>
> 1. Unlimited HSTS records, and risk getting OOM killed
> 2. FIFO queue with a soft limit, like proposed above
>
> Choice (2) leads to policy choices:
>
> (a) silently evict
> (b) return error, and don't fetch
> (c) die with an error
>
> Jeff
I wonder if it would make sense to have a system-wide daemon in charge of transfers.
That daemon could maintain the cache on disk.
Obviously way out of scope for curl, though!
Received on 2026-04-02
Date: Thu, 2 Apr 2026 10:42:23 -0400
On 4/1/26 17:02, Jeffrey Walton via curl-library wrote:
> On Wed, Apr 1, 2026 at 4:55 PM Daniel Stenberg via curl-library
> <curl-library_at_lists.haxx.se> wrote:
>>
>> Hey,
>>
>> Today I implemented a cap in how many HSTS entries libcurl keeps in memory, to
>> prevent it from being a never-ending growth that could eventually cause
>> problems. I set the limit to 1000 entries, quite arbitrarily.
>>
>> The oldest entry gets evicted when more are added.
>>
>> This can however, perhaps, have an effect on security if someone happens to
>> load countless pages with HSTS and the list adds up. Or as one of our AI code
>> analyzers expressed it:
>>
>> The new hsts_append() drops the oldest HSTS entry once the list reaches
>> MAX_HSTS_ENTRIES. Because curl only upgrades HTTP to HTTPS when an HSTS entry
>> is present, an attacker who can coerce a client into visiting many unique
>> HTTPS hosts with HSTS headers (for example via redirect chains under their
>> control) can evict previously stored HSTS policies. Once the target entry is
>> evicted, subsequent HTTP URLs to that host will no longer be upgraded,
>> opening a downgrade window for MITM. This is a security regression compared
>> to the previous unlimited retention.
>>
>> It seems correct, but is this anything we can actually protect against? Having
>> an unlimited cache in memory seems like a bad idea as well...
>
> Instead of a machine wide implementation, perhaps the HSTS cache can
> be per-app. Then the app can select a policy:
>
> 1. Unlimited HSTS records, and risk getting OOM killed
> 2. FIFO queue with a soft limit, like proposed above
>
> Choice (2) leads to policy choices:
>
> (a) silently evict
> (b) return error, and don't fetch
> (c) die with an error
>
> Jeff
I wonder if it would make sense to have a system-wide daemon in charge of transfers.
That daemon could maintain the cache on disk.
Obviously way out of scope for curl, though!
-- Sincerely, Demi Marie Obenour (she/her/hers)
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-keys attachment: OpenPGP public key
- application/pgp-signature attachment: OpenPGP digital signature