Re: HSTS cache cap allows eviction of security entries

On Wed, Apr 1, 2026 at 4:55 PM Daniel Stenberg via curl-library
<[email protected]> 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
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html