I support an ancient industrial HTTP-only web application that users access via http://app.suborg.example.com/. I recently discovered that a different site https://example.com/ has set HSTS too aggressively, by adding includeSubDomains
Now if a user visits example.com, they will immediately be unable to access app.suborg.example.com, since the browser redirects to HTTPS. This results in a ERR_EMPTY_RESPONSE page, because the server doesn't listen for https. We can manually navigate to about://net-internals/#hsts and delete the entry every time, but it's not ideal.
So far, I've tried:
- Contacting the top-level site administrators: not going well
- Typing
thisisunsafe: only works on certificate error pages, which I don't actually see - Chrome Policy HttpAllowlist: Specifically excludes HSTS upgrades, so no effect
- Chrome Policy HSTSPolicyBypassList: Only allows single-label hostnames, so no effect
- Adjusting the server to allow connections via a single-label name
http://app/: it has hardcoded hostnames internally... it will respond, but usually 404 due to missing resources.
Does modern Chromium/Chrome/Edge have any options outside of deleting HSTS entries manually? There's not many users and I support them directly, so even a fiddly solution would be fine.
HttpAllowlist does not apply to HSTS upgrades. HSTSPolicyBypassList does not prevent HSTS upgrades for servers that have "dynamically" requested HSTS upgrades using a Strict-Transport-Security response header. I think that's why they don't take effect.
I found a useful blog and you can check the Local Diagnostics paragraph. For that
example.comdomain, ifFORCE_HTTPSshow indynamic_upgrade_mode, the suggested fix "Clear Browsing Data > Cached images and files: All time" works.