Closed Bug 800098 Opened 12 years ago Closed 10 years ago

Do not allow the user to unblock active mixed content on HSTS sites

Categories

(Firefox :: Security, defect)

Product:
Firefox
Component:
Security
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: briansmith, Unassigned)

References

(Blocks 1 open bug)

Details

+++ This bug was initially created as a clone of Bug #782654 +++ I am not sure this is a good idea yet, because there's some debate about whether we should add new meanings to HSTS. We should come to an agreement with other web browser makers, one way or the other. See: http://code.google.com/p/chromium/issues/detail?id=131916
No longer blocks: 782654
Per http://code.google.com/p/chromium/issues/detail?id=131916, if an STS site includes mixed active content it will be blocked without a way for the user to override the block. For example, consider a page https://foo.com/: HTTP/1.1 200 OK Strict-Transport-Security: max-age=123 <!DOCTYPE html> <script src=http://foo.com/foo.js> <script src=http://bar.com/bar.js> http://bar.com/bar.js will be blocked because it is mixed active content. There will be no UI to override that block on Chrome. Moreover, http://foo.com/foo.js will also be blocked even though STS would have auto-upgraded it to https://foo.com/foo.js on Chrome. Conclusion - STS sites really shouldn't have any http:// embeds if they want to work properly on Chrome, regardless of whether or not the browser will auto-upgrade them to https.
I don't see any relation between HSTS and mixed content blocking. If anything this would just give sites more reason not to bother with HSTS.
in fact, what is the justification for not upgrading the http://foo.com request? That's supposed to be what HSTS /means/ if it means anything. As for blocking other content, if that's what the site author wants they could use CSP, which happens to be supported in the browsers I know of that support HSTS.
I'm sorry, I misread this entirely and was responding to the imaginary bug in my head. Blocking <script src=http://samedomain.com/foo.js> rather than upgrading to https per HSTS is not what we want to do. Both HSTS and mixed content blocking seek to enhance security of the same condition, and both /do/ result in a secure state. HSTS is both an official spec AND is less likely to result in broken content. In fact that shouldn't be limited to "samedomain": if applying HSTS rules fixes the links we shouldn't block them. I realize that is a separate issue and technically difficult due to the order in which MCB and HSTS are applied, but until that's working correctly removing the ability to override MCB means we can break pages that are theoretically perfectly secure And as long as <iframes> are part of MCB and not a 3rd category of mixed content we should not take away the ability to override the blocking. 3rd-party framed content is not dangerous to the integrity of the site's code or content the way included scripts or plugins are. It's potentially insecure/spoofy to the human looking at the page but that's not quite the same thing as what HSTS on a site means.
Resolving INVALID because comment 4.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
This is being brought up again in: https://bugzilla.mozilla.org/show_bug.cgi?id=1133712 http://blogs.msdn.com/b/ie/archive/2015/02/16/http-strict-transport-security-comes-to-internet-explorer.aspx https://groups.google.com/forum/#!topic/mozilla.dev.security/rR3SBOFvUqM Looks like there are two topics in this bug: On an HSTS page, blocking HSTS subresources from the samedomain or other HSTS domains as mixed active content (even though they would have gotten upgraded by HSTS) and not offering the user a way (the shield) to override the block. On an HSTS page, blocking http subresources from non-same-domain as mixed active content and not offering the user a way (the shield) to override the block. Dan, are you interested in revising your thoughts on how we should handle these cases? Reopening the bug.
Status: RESOLVED → REOPENED
Flags: needinfo?(dveditz)
Resolution: INVALID → ---
Also, it looks like Chrome's behavior documented in comment 1 has changed. The option for user override exists for same domain and cross domain subresources.
Thanks to Anne for some helpful test cases before. > On an HSTS page, blocking HSTS subresources from the samedomain or other > HSTS domains as mixed active content (even though they would have gotten > upgraded by HSTS) and not offering the user a way (the shield) to override > the block. > Example at https://dump.testsuite.org/mixed-content/soscript.html (and for mixed display content - https://dump.testsuite.org/mixed-content/soimage.html) > On an HSTS page, blocking http subresources from non-same-domain as mixed > active content and not offering the user a way (the shield) to override the > block. > Example at https://dump.testsuite.org/mixed-content/script.html (and for mixed display content - https://dump.testsuite.org/mixed-content/image.html)
I really worry that this bug and bug 1133712 will give developers one more reason NOT to use HSTS. If it makes some 3rd party image content on a blog go away (bug 1133712) then people will even more want an override button -- but then that runs insecure scripts in addition to loading the images that was all they wanted to see. So then we'll want to take away the override button (this bug) which will just make pages broken. We can blame the authors, but they can't always control the 3rd party content they link to. If chrome has reverted their behavior I'd take that as a vote in favor of wontfixing this bug. We should not do both this bug and bug 1133712. We could take away the override if we leave the passive content unmolested. Would be instructive to find out from the chrome team why they reverted. Our current behavior seems to match current Chrome behavior. I wouldn't want to change that without some cross-browser discussions in a standards body, not just guessing at what we think other people might do.
Flags: needinfo?(dveditz)
(In reply to Daniel Veditz [:dveditz] from comment #10) > If chrome has reverted their behavior I'd take that as a vote in favor of > wontfixing this bug. > > ... > Would be instructive to > find out from the chrome team why they reverted. Our current behavior seems > to match current Chrome behavior. I wouldn't want to change that without > some cross-browser discussions in a standards body, not just guessing at > what we think other people might do. Chrome reverted in this bug after they started blocking mixed content frames by default: https://code.google.com/p/chromium/issues/detail?id=285376
Dan, you have convinced me. I'm going to mark this bug won't fix again. If an HSTS website wants to ensure that there is no mixed content on their page, they can do so with a CSP directive (block-all-mixed-content, https://w3c.github.io/webappsec/specs/mixedcontent/#strict-checking). Well, they can't yet but will be at some point in the future when we implement that directive. Thanks!
Status: REOPENED → RESOLVED
Closed: 11 years ago → 10 years ago
Resolution: --- → WONTFIX
I don't think it matters as much if browsers differ in what overrides they offer to users. As long as the default behavior is consistent we can differ on how we interpret the priority of constituencies.
Does that statement mean you don't think that overrides are a footgun for users?
I said nothing of the kind, but if you want to trade hyperbolic accusations does your question imply that you think all overrides are unsafe, even trivial ones like the default homepage? Does your question mean you think overriding the mixed content blocker is such a footgun we shouldn't allow it at all? That's plausible. Currently it looks like about half a percent of page loads have mixed active content (still millions of page views though), but I couldn't see if we had telemetry on overrides. Maybe we don't need it at all and that would be great. In the meantime I think we've buried the footgun reasonably well. All I'm saying is HSTS pages shouldn't be treated differently. There's nowhere in the HSTS spec that says "and I'm opting into all sorts of new content rules to be determined in the future." If the site author cared there are things they could do as a backstop to catch accidental mixed content, CSP for instance. If they don't care then by treating HSTS differently we are only going to discourage people from using HSTS.
I'm sorry, that was needlessly inflammatory. I filed bug 1140990 to investigate removal of overrides. I guess you're right that we should not make HSTS any harder than it already is.
You need to log in before you can comment on or make changes to this bug.