HSTS cache cap allows eviction of security entries

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.html