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.
HSTS cache cap allows eviction of security entries
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 1 Apr 2026 22:55:07 +0200 (CEST)
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?
Date: Wed, 1 Apr 2026 22:55:07 +0200 (CEST)
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?
-- / daniel.haxx.se || https://rock-solid.curl.dev -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2026-04-01