Page MenuHomePhabricator

Preload HSTS for select hostnames within
Closed, DeclinedPublic


At this point we're probably going to go ahead and pre-load a few inidividual hostnames in that are more-critical while the longer process plays out for the rest of it. We can't touch donate due to ongoing issues to resolve there. My short-list to get the most-important ones locked down would be just these:

meta - This gets hit a ton during browser access to other wikis, for things like banner campaigns, gadgets, etc
login - To protect CentralAutoLogin -related hits here
commons - Because it's a major wiki and again indirectly referenced a lot
payments - Doesn't even have an HTTP listener on port 80 and fairly critical

The first three all have .m. variants in DNS, although login.m doesn't seem to get real traffic in practice? Could just remove that one instead of pointlessly preloading it if so.

We'll need to address the bad www subdomains in meta and commons first as well ( T102826 )

Event Timeline

BBlack claimed this task.
BBlack raised the priority of this task from to Medium.
BBlack updated the task description. (Show Details)
BBlack added projects: HTTPS, Traffic, acl*sre-team.
BBlack added subscribers: Tbayer, MZMcBride, fgiunchedi and 8 others.

I've watched one mobile cache for hours now, and the only single request to was a GET / from bingbot. Makes me wonder where they got the hostname from a little, but I think it's safe to say nothing's really using that hostname. Should probably confirm whether there were future plans there and then kill it, making the explicit set of hostnames for the preload list:

Or in terms of varnish regex for the header: ^((meta|commons)(\.m)?)|login|payments)\$

Removed the subdomain blocker - it's not complete as a whole yet, but the parts that blocked this task are.

With the impending removal of *.donate, we'll actually finally be able to HSTS itself at the DNS level.

With the impending removal of *.donate, we'll actually finally be able to HSTS itself at the DNS level.

Wait a minute. There are still some subdomains of that don't even support HTTPS.

Right: "at the DNS level" means it's fixed in terms of not having bad DNS names with no matching certs. We still have services that don't support HTTPS, or don't redirect...

Yeah, I'm in the process of enumerating those....