Re: HSTS cache cap allows eviction of security entries

From: Timothe Litt <litt_at_acm.org>
Date: Wed, 1 Apr 2026 17:04:06 -0400

Store the HSTS list on disk (persisting it is good); you can use a
memory cache of both positive [site -> HSTS records]  and negative [site
-> 'has no HSTS']  entries - and limit its size.

Or let a database (e.g. SQLite) manage the list.  You don't have to
invent your own.


Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

On 01-Apr-26 16:55, Daniel Stenberg via curl-library 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...
>
> Thoughts?
>

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Received on 2026-04-01