Open Bug 1447011 Opened 7 years ago Updated 2 years ago

Permit setting HSTS entries only on the host name or the eTLD+1

Categories

(Core :: Security: PSM, enhancement, P3)

Product:
Core
Component:
Security: PSM
Type:
enhancement

Tracking

()

People

(Reporter: ehsan.akhgari, Unassigned)

References

(Blocks 3 open bugs)

Details

(Keywords: dev-doc-needed, Whiteboard: [fingerprinting][psm-backlog][fp-triaged])

See the following article for the mitigation that Safari deployed against HSTS cookies. https://webkit.org/blog/8146/protecting-against-hsts-abuse/ The first mitigation at least seems to be something that we should implement right now, and perhaps keep #2 in mind in tandem with future privacy features.
There is a trade-off here - this sort of restriction will discourage use and effectiveness of HSTS in large organisations by making incremental implementation no longer possible.
This would have to be restricted to the Host/domain of the top-level window. This would still allow a malicious site to set an HSTS cookie through redirects (restricted by our redirect limit). A legit site won't want the latency but a malicious ad in a frame might still be able to do it with severe limitations (noisily by opening a popup, or redirecting top if they can get the full referrer so they can end up back on the same top page at the end of the redirects -- but then they roll the dice on getting their ad back on the page).
Blocks: 648186
Whiteboard: [fingerprinting]
Daniel, are you referring to `network.http.redirection-limit` (default value of 20)? If so, this could (in a new ticket) possibly be reduced. I have been using a value of 10 for quite a few years with no side affects.
Component: Security → Security: PSM
Whiteboard: [fingerprinting] → [fingerprinting][psm-backlog]
Whiteboard: [fingerprinting][psm-backlog] → [fingerprinting][psm-backlog][fp-triaged]
Keywords: dev-doc-needed
Blocks: 1590107

We have made some progress here with bug 1635828, but WebKit's approach as well as Mike West's proposal at https://github.com/mikewest/strict-navigation-security deserve further consideration. Bug 1672106 would change the options we have here. At that point we could basically decide to only care about "first-party" assertions and disregard everything else as they would be upgraded anyway (except in the case where the first-party is not secure, but in that case the user is at risk anyway). This would reduce the amount of information we have to store.

At that point the final step would be to look at WebKit's solution and bounce tracking (navigation tracking) in general. I'm not sure how much sense it makes to tackle one without the other.

Depends on: 1672106

Was this fixed by bug 1701192?

Flags: needinfo?(dkeeler)

No, we allow any domain that is same-site with the top-level to set it still.

Flags: needinfo?(dkeeler)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.