Closed Bug 1070967 Opened 10 years ago Closed 9 years ago

Green padlock despite site including content from non-EV sites.

Categories

(Core Graveyard :: Security: UI, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 652492

People

(Reporter: pricechild, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 Iceweasel/33.0 Build ID: 20140906130221 Steps to reproduce: Open developer tools, activate the network tab and visit https://twitter.com Find one of the javascript files also requested, e.g. from https://abs.twimg.com Actual results: Notice that the location bar's padlock for https://twitter.com is green for EV and contains the organisation e.g. "Twitter, Inc. (US)" The padlock on https://abs.twimg.com is grey as it is not EV Expected results: I would expect to see a grey padlock or perhaps a green warning triangle. This is because just as when https & http content is mixed, the padlock is replaced by a warning triangle, I would expect something similar when EV & non-EV verified responses are received. Because the page is loading content from a variety of sources, statements such as the single "You are connected to" & "which is run by" are a little misleading... included javascript from non-EV sites could potentially rewrite the entire page? Or maybe I'm just confused as to how it all works?
Component: Untriaged → Security: UI
Product: Firefox → Core
Monica, do you know if we have plans to do something in this space or whether this is considered acceptable?
Flags: needinfo?(mmc)
This is working as intended. The EV indicator is shown based only on the certificate of the top-level page, not any included content. This behavior is not standardized but is consistent across all browsers. You are correct that included JS from other sites could potentially rewrite the entire page. However, this is true whether or not the included JS is from an EV site or a non-EV site (the recent jquery vulnerability could have done this if served off an EV site, for example). Mixed content blocking is intended to reduce the impact of MITM attacks (https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/), which is more difficult all-https case. Sid, David, please correct me if I'm wrong. Thanks, Monica
Flags: needinfo?(mmc)
You're right, Monica. It's only about the top level document. So EV contexts can be mixed EV/DV despite having an EV "DOM trust anchor". I thought about implementing a higher integrity level for the whole page, requiring everything to be EV, but it was fairly complicated and at the time the value proposition for pure EV subresourcing wasn't much over just requiring all HTTPS. http://evssl-trust.sidstamm.com/ (yes, I know it's not an https site, I'm cheap)
Blocks: lockicon
OS: Linux → All
Hardware: x86_64 → All
Version: 33 Branch → Trunk
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.