Spike in HSTS preload removals

[Nick Harper]

Over the past two weeks, I've seen a spike in requests for HSTS preload removals. Usually there are around 20-40 removals per week, whereas for the past two weeks there are a total of around 1800 removals pending. From looking at server logs, most of the removals came from a few IP addresses. (Four IP addresses requested more than 100 removals each, making 105, 214, 501, and 1025 requests for removal. There were 3 IP addresses with double-digit numbers of removals, and a long tail of addresses requesting single-digit numbers of removals.)

It seems unlikely to me that 1800 domain owners intentionally decided in the same two weeks to stop preloading their domains. I plan to ignore the removal requests that came from the suspect IP addresses; if that accidentally ignores legitimate requests they can be re-requested.

The current criteria for removing a domain from the HSTS preload list is that the Strict-Transport-Security header is served for an HTTPS request to the root of the domain (and a valid cert is used), and it does not contain the "preload" directive. Based on this spike of removal requests and that so many come from the same IP address, I'm guessing someone(s) on the internet scanned through the preload list for domains that no longer met the requirements and requested their removal, and these domains had actually stopped serving the preload directive at some point prior to last week.

I'd like to propose a change in process to how preload list removals are handled:
When checking the Strict-Transport-Security header, instead of checking for a lack of the "preload" directive, check that it is present, with a value of false (i.e. "preload=false").

The rationale for this change is that this is a much more explicit signal from the server that the domain should no longer be on the preload list, as opposed to looking for the absence of the preload directive.

Does this change sound like a reasonable change? Should the signal for preloading also be changed to "preload=true" so that the directive always has a value?

Cheers,
Nick

[Lucas Garron]

I'd like to recommend against modifying the header semantics informally. We previously discussed it at https://bugs.chromium.org/p/chromium/issues/detail?id=590357#c3

If you do want to change how the directive works, I'd highly recommend writing an RFC for it.

Reasons:

1) Our policy explicitly requires keeping up the requirements.

2) The removal policy guards against removal of sites that accidentally stop sending the entire HSTS header (which is by far the most common "accidental" change).

3) We actually should be removing these domains regularly, we just haven't gotten around to automating it. Someone is essentially doing our work for us.

4) Ignoring the requests from this IP doesn't stop others (or the same actor) from submitting more removal requests from other IPs in the future.

5) Removing stale entries helps reduce the impact of growth (albeit not nearly as much as we might like).

»Lucas

--
You received this message because you are subscribed to the Google Groups "HSTS Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss...@chromium.org.
To post to this group, send email to hsts-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/hsts-discuss/CACdeXiLAypafXyyKJoQzh9sjMGD1LrErEMiTKS5f6N8H237KzQ%40mail.gmail.com.

[Nick Harper]

Had we introduced automation for removing domains no longer meeting requirements around the same time as automating preload list additions and removals, I think reasons #1 and #3 would be perfectly reasonable rationale for removing these 1800 domains from the list. However, since we haven't done anything to remove domains that aren't continually meeting the requirements, we've set the expectation for site operators that they only need to configure the "preload" directive when adding their domain to the list. This boils down to a question of "Is it a good idea to drop all domains from the list (without any notice to the domain owner/operator) that aren't sending the preload directive?"

If everyone thinks the answer to that question is "yes", then there's nothing that needs to be done here. Right now, I think the answer to that question is "no".