Open Bug 815321 (MixedContentBlocker) Opened 12 years ago Updated 2 months ago

[meta] Master Bug for Mixed Content Blocker

Categories

(Core :: Security, task, P3)

Product:
Core
Component:
Security
Type:
task

Tracking

()

Tracking Flags:
Tracking Status
relnote-firefox --- 23+

People

(Reporter: tanvi, Unassigned)

References

(Depends on 58 open bugs, Blocks 2 open bugs)

Details

(Keywords: meta) 

This bug serves as a master bug for all things about the Mixed Content Blocker in Firefox.  Implementation, followup bugs, telemetry, new feature requests, etc.  When filing bugs for mixed content, please indicate that it blocks this bug.

Note that no actual code should be landed as part of this master bug.
Alias: MixedContentBlocker
Depends on: 815329
Depends on: 815334
Depends on: 800098
Depends on: 815345
Depends on: 308496
Depends on: 822366
Depends on: 822367
Depends on: 822371
Depends on: 822373
Depends on: 824871
Depends on: 827595
Depends on: 834821
Depends on: 834828
Depends on: 834830
Depends on: 834836
Depends on: 836352
Depends on: 836359
Depends on: 836431
Depends on: 836459
Depends on: 837351
Depends on: 837853
Depends on: 837959
Depends on: 838396
Depends on: 838403
Depends on: 838394
Depends on: 838395
Depends on: 838402
Some status updates:
Bug 837075 crash - awaiting try results and then can push to inbound
Bug 836630 test failure - in inbound
Bug 836951 crash - awaiting try results and then can push to inbound
Bug 838403 - needs test.  in try
Bug 836811 crash - patched, but needs a test before we can close.

These are the bugs I am tackling now:
* Potential caching issue - https://bugzilla.mozilla.org/show_bug.cgi?id=837959
* Telemetry - https://bugzilla.mozilla.org/show_bug.cgi?id=781018
* Turn pref on by default - https://bugzilla.mozilla.org/show_bug.cgi?id=834836
* Add blocked info to Webconsole and error console - https://bugzilla.mozilla.org/show_bug.cgi?id=836431 and https://bugzilla.mozilla.org/show_bug.cgi?id=837351
(In reply to Tanvi Vyas [:tanvi] from comment #1)
> These are the bugs I am tackling now:
> * Potential caching issue -
> https://bugzilla.mozilla.org/show_bug.cgi?id=837959
> * Telemetry - https://bugzilla.mozilla.org/show_bug.cgi?id=781018
> * Turn pref on by default -
> https://bugzilla.mozilla.org/show_bug.cgi?id=834836
> * Add blocked info to Webconsole and error console -
> https://bugzilla.mozilla.org/show_bug.cgi?id=836431 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=837351

And:
* Site Identity Message Updates - https://bugzilla.mozilla.org/show_bug.cgi?id=838402
Depends on: 403590
Depends on: 839235
Depends on: 839238
Depends on: 840388
Depends on: 840395
Depends on: 840641
Depends on: 841850
Depends on: 841850
Depends on: 842198
Depends on: 843540
Depends on: 838359
Depends on: 842146
Depends on: 800293
Depends on: 842191
Depends on: 860712
Depends on: 862201
QA Contact: virgil.dicu
Depends on: 873349
This has been noted in the Aurora 23 release notes:

http://www.mozilla.org/en-US/firefox/23.0a2/auroranotes/

If you would like to make any changes or have questions/concerns please contact me directly.
Depends on: 874591
Depends on: 803626
Depends on: 803620
Depends on: 860581
Depends on: 865352
Depends on: 878890
Depends on: 879642
Depends on: 882467
Depends on: 883235
QA Contact: virgil.dicu → mihai.morar
Depends on: 886663
Depends on: 875456
Depends on: 888195
Depends on: 891378
Depends on: 893533
Depends on: 896211
Depends on: 899145
Is there some standard where trusted content can use active content over HTTP by providing some cryptographically acceptable hash together with the URI?

e.g.

<html>
<!-- secure from https://trusted.com -->
<head>
<script type="text/javascript" src="http://untrusted3rdparty.com/libs/jquery1.3.min.js" digest="SHA1:12345678901234ABCDEF">
</script>
</head>
<body> blah blah </body>
</html>

Wouldn't this cover the security need while still avoiding the server overhead of serving over HTTPS?

Disclaimer: I'm not a security expert.
There is no such standard. You may however propose one in the WHATWG mailing list [1], or at the W3C. 

[1] http://www.whatwg.org/mailing-list
Depends on: 902156
Depends on: 902181
(In reply to Avi Halachmi (:avih) from comment #4)
> Is there some standard where trusted content can use active content over
> HTTP by providing some cryptographically acceptable hash together with the
> URI?
> 
> e.g.
> 
> <html>
> <!-- secure from https://trusted.com -->
> <head>
> <script type="text/javascript"
> src="http://untrusted3rdparty.com/libs/jquery1.3.min.js"
> digest="SHA1:12345678901234ABCDEF">
> </script>
> </head>
> <body> blah blah </body>
> </html>
> 
> Wouldn't this cover the security need while still avoiding the server
> overhead of serving over HTTPS?
> 
> Disclaimer: I'm not a security expert.

Thanks Avi for your comments!  This would indeed help alleviate the issues with mixed content.  The digest would be served over HTTPS and the browser woudl only accept the HTTP content if it matched the digest.  Assuming we use a secure collision resistant hashing algorithm, we could allow mixed content loads that include this kind of integrity check.

This idea has been proposed in the past.  Most recently, it was discussed in the W3C Webappsec Working Group.  I can't recall if it has made it into the official charter or not, but here is a short description of it in a draft charter: http://lists.w3.org/Archives/Public/public-webappsec/2012Nov/att-0094/Web_Application_Security_Working_Group.htm (Look under Sub-Resource Integrity).

Also, looks like Gerv posted about this idea years ago: http://www.gerv.net/security/link-fingerprints/
Depends on: 902350
Depends on: 902583
Depends on: 902586
Depends on: 899099
Depends on: 903211
Depends on: 903692
Depends on: 906190
Depends on: 906219
Keywords: meta
Depends on: 906447
I think this one also depends on: 
Bug 841352 - Using InstallTrigger bypasses nsIContentPolicy
Depends on: 841352
Depends on: 909562
Depends on: 910976
Depends on: 906069
Blocks: 903966
Depends on: 912817
Blocks: 909920
Depends on: 914410
Depends on: 913710
Depends on: 914724
No longer depends on: 906447
Depends on: 914860
Depends on: 915951
I'm raising a general concern which I'm unable to evaluate its meaningfulness and which this bug is is just an example of:

Considering that this bug has been on beta for few weeks and on aurora before that, wouldn't we expect less bugs to be discovered once it hits release? My gut feeling is that at least some of the newer bugs should have been caught before it hit release.

Am I expecting too much of the beta release? Am I over-evaluating the importance of the bugs here which were discovered late? Also, I can see that bugs were discovered during beta as well, so maybe the fact that bugs kept popping up while this feature was on aurora and beta should have raised some flags that this is maybe not ready for prime time yet?

If some of these concerns are valid, how can we prevent it from happening again? Is it worth a spin off to another bug?
Depends on: 925680
Depends on: 926781
Depends on: 935393
Depends on: 945636
Depends on: 955864
Depends on: 952390
No longer depends on: 955864
Depends on: 1036840
Depends on: 1039867
Depends on: 1084504
Depends on: 1122236
Depends on: 1122237
Depends on: 1133712
Depends on: 1139297
Depends on: 1140529
Depends on: 947676
seriously? CVE-2007-1970 is not fixed yet?
Depends on: 527733
Depends on: 1146677
Depends on: 865480
Depends on: 1150602
Depends on: CVE-2015-4483
Depends on: 1179947
Depends on: 1182551
Depends on: 918237
Depends on: 1190623
Depends on: 1193718
Blocks: 1194475
Blocks: 1207746
Depends on: 1224399
Depends on: 1227623
Depends on: 1231062
Depends on: 1235652
(In reply to Avi Halachmi (:avih) from comment #8)
> I'm raising a general concern which I'm unable to evaluate its
> meaningfulness and which this bug is is just an example of:
> 
> Considering that this bug has been on beta for few weeks and on aurora
> before that, wouldn't we expect less bugs to be discovered once it hits
> release? My gut feeling is that at least some of the newer bugs should have
> been caught before it hit release.
> 
> Am I expecting too much of the beta release? Am I over-evaluating the
> importance of the bugs here which were discovered late? Also, I can see that
> bugs were discovered during beta as well, so maybe the fact that bugs kept
> popping up while this feature was on aurora and beta should have raised some
> flags that this is maybe not ready for prime time yet?
> 
> If some of these concerns are valid, how can we prevent it from happening
> again? Is it worth a spin off to another bug?

Avi, this bug is a meta-bug. As such, it doesn't evolve from trunk to aurora to beta to release. It is just a central place which will show you all mixed-content bugs already found, and which ones have been fixed (on Trunk). Some of them have a security flag set, and of these, "ordinary" non-security-cleared people like me can only know that they exist, not what they are about.

Due to the nature of this particular meta-bug, I expect new blockers to be added to it every time, and that would mean that only the blockers will one by one get FIXED but not the meta-bug itself. Indeed, IMHO it falls within the scope of the saying: "The only kind of bug-free software is obsolete software." This doesn't mean that solving mixed-content-blocker bugs is useless but only that perfection can only be attained asymptotically.
Depends on: 1201767
See Also: → 1244116
Depends on: 1244116
See Also: 1244116 →
Depends on: 1246345
Depends on: 1257744
Depends on: 1258549
Depends on: 967716
No longer blocks: 903966
Depends on: 903966
Blocks: 1305676
No longer blocks: 1305676
Depends on: 1305676
Depends on: 1319757
Depends on: 1421415
Depends on: 1420680
Could you add?:
"Mixed content exception (left of address bar) not available in certain cases"
https://bugzilla.mozilla.org/show_bug.cgi?id=1461445
Depends on: 1519034
Summary: Master Bug for Mixed Content Blocker → [meta] Master Bug for Mixed Content Blocker
No longer blocks: 1520381
Depends on: 1520381
Depends on: 1601408
Priority: -- → P3
Product: Firefox → Core
Type: defect → task
Depends on: 1656462
Depends on: 1668530
Depends on: 1696973
Depends on: 1706871
No longer blocks: 1519406
Depends on: 1519406
Depends on: 1735105
Severity: normal → S3
Depends on: 1811787
Depends on: 1844646
You need to log in before you can comment on or make changes to this bug.