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: Jeffrey Walton via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 1 Apr 2026 17:02:24 -0400
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
Date: Wed, 1 Apr 2026 17:02:24 -0400
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
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2026-04-01