Closed Bug 502008 Opened 15 years ago Closed 15 years ago

Warning about unencrypted content in SSL pages from data: URIs inserted by userContent.css or extensions

Categories

(Firefox :: Security, defect)

3.5 Branch
x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 477118

People

(Reporter: castaban, Unassigned)

References

()

Details

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5

Since 3.5 I started getting this warning:
"You have requested an encrypted page that contains some unencrypted information. Information that you see or enter on this page could easily be read by a third party."
This seem to come up with all SSL pages. Perusing the content of the page does not reveal any un-secure content.
Example: https://addons.mozilla.org/en-US/firefox/
It seems to happen at every SSL site.
Prerequite: The Mixed content warning flag need to be checked at FF setting

Reproducible: Always
I can't reproduce this... do you have any extensions installed?
I have extensions installed, but I tried in Safe mode, I still get the same warning message. Is your FF setting set to give you mixed content message? Windows 2000 maybe?
Curious difference between safe mode and normal mode. In safe mode when I go to SSL page I get the warning. Hit on OK and refresh the page and I don't get any more warnings. In normal mode when I refresh I get a new warning after each refresh. I don't know whether it is irrelevant...
Happening with me too... I'm a web developer, so after upgrading to Firefox 3.5 as soon as it was out, then getting the message "unencrypted items on this page" on our secure site, was a shock!

However IE7 says everything's fine. Refresh the same page in FF3.5 and the message goes away. Downgrading to Firefox 3.0 is an option and the issue doesn't occur in Firefox 3.0, however all those who visit my site in FF3.5 are now going to get a false warning.

This is rubbish, and I am in the process of putting up a warning informing people about the false warning, till this is resolved.
As this now effects at least two people can somebody confirm/work on this?
Version: unspecified → 3.5 Branch
I'd say more than two - tried it on my work PC, same issue, with Firefox 3.5!

As I said, using Firefox 3.0 works fine, and I'm more inclined to use FF3 till you sort this out as it gives me false information that something's wrong, when in fact it isn't.
In order for this to get fixed, you'll need to provide steps to reliably reproduce it. As far as I can tell, no developer has been able to reproduce it yet. I can load the URL from comment 0 without any warnings, and no other comments have provided URLs where the problem can be seen. Until we can reproduce the problem, we have no idea what's happening, and therefore what a fix would entail.

(Note that it's possible that the problem is not with Firefox, but with third-party software or a proxy or something else like that.)
Here is some more (I have the issue with all SSL pages):
https://swww.scotiaitrade.com/
https://fx2.xe.com/fxlogin/Pages/Login.aspx
https://bugzilla.mozilla.org/show_bug.cgi?id=502008
(Ironic isn't it)
I do not have Proxy, I tried it with Safe mode and it was working FF 3.Stopped working immediately after I installed 3.5. I do not think it is a 3.party software. COuld be Windows 2000 though. Dave what are you running?
I run the page with the extension Tamper Data extension (which shows all the requests made by the page) and it does not show any insecure content. Is there any way to tell which content is causing the problem?
I certainly don't get any warnings for any of those URLs here (yes, mixed content warning pref is set), which makes me wonder if your data is being tampered with, either by system-local things, or by something somewhere on your network.

Did you say it DID happen to you in Firefox 3.5 safe mode?  Your comment is a bit unclear about whether you tried safe mode in 3.0.x or 3.5.
I think everyone is missing the point here.

Firefox 3.0 - Unaffected
Internet Explorer 6 - Unaffected
Internet Explorer 7 - Unaffected
Internet Explorer 8 - Unaffected
Safari - Unaffected
Google Chrome - Unaffected

These tests were run a few minutes ago - Firefox 3.5 is the only browser with this issue. So I really cannot see how this can be caused by anything other than the fact it's a bug in Firefox 3.5 itself.

I've done more tests, this time with Firebug enabled...

The page itself loads as HTTP according to Firebug, even though HTTPS appears in the address bar. However Firebug also says every other item on the page is loading as HTTPS - the page itself is loading as HTTP.

Refreshing the same page or even reloading it via the address bar loads the same page, but in HTTPS mode. This is the only fix I have found so far, but first time round is enough to scare anyone away from using your site in my opinion.

The web page itself loads every CSS/JS/image file via the base path, i.e. /images/. I don't use http/https to load any content. Google Analytics on the other hand does use http/https, but as noticed in Firebug, the GA code recognises it's running in HTTPS mode and therefore connects to the secure GA server.

There's no other way to say it other than this is a bug with Firefox. As I've said no other browser has this issue, but Firefox 3.5.

If you want me to try anything, let me know.
Just to add, the only thing I'm noticing when the page loads with this warning is the certificate is marked as "unverified", and refreshing the same page causes Firefox to show which root authority has verified the certificate.

So it seems FF 3.5 is not recognising some certificates, but refreshing the page and then it recognises it?!
johnath: did we take a PSM/NSS change for OCSP in 3.5?
(In reply to comment #10)
> I think everyone is missing the point here.

Mostly, the people here are trying to narrow the gap between their own test environments - which don't show the problem - and yours.  Addons are a perfect example of something that could alter that landscape, and while it's helpful to know that other browsers are unaffected, it's also worth noting that more than once, we've been the only browser to spot a legitimately compromised network.

The diagnostic help is therefore very much appreciated, but the angry and entitled attitude is almost certain to make the people currently motivated to help you less likely to do so. We build this browser because we want the web to be a more awesome place - and we rely on helpful people like you reporting problems when you find them because often they really are in our software and we fix those.  But we are also a relatively small group of people building a browser for 300 million people so I want to make sure, without seeming to belittle your frustration and without seeming ungrateful for your help, that you don't piss off every single person who's trying to help.

> There's no other way to say it other than this is a bug with Firefox. As I've
> said no other browser has this issue, but Firefox 3.5.

Yes, you've said that repeatedly. Now let's figure out what's going on, instead of just talking about what a piece of rubbish it is, mm?

(In reply to comment #11)
> Just to add, the only thing I'm noticing when the page loads with this warning
> is the certificate is marked as "unverified", and refreshing the same page
> causes Firefox to show which root authority has verified the certificate.
> 
> So it seems FF 3.5 is not recognising some certificates, but refreshing the
> page and then it recognises it?!

Yeah - that is consistent with the mixed content warning, though it's not about the root being recognized.  When a page is not https top to bottom, we treat the contents as "unverified" since arbitrary tampering could have occurred via the http components of the page.

What happens when you try to load a single resource, instead of a complex page, e.g. 

https://www.mozilla.org/images/subsite_mozilla-org.gif ?

(In reply to comment #12)
> johnath: did we take a PSM/NSS change for OCSP in 3.5?

3.5 is on a different NSS tag than 3.0 - so there are potentially exciting amounts of change in that code - do you have a theory that implicates OCSP here?
Sorry my bad, didn't mean to come across that way! :(

Tried the single image, and it loads fine, and is verified. The main difference between your site and mine though is my certificate is 256-bit. When I need to force users to use a secure connection, I use a 301 redirect to redirect them into the secure page.

Let us know if you want me to try anything more.
(In reply to comment #14)
> Sorry my bad, didn't mean to come across that way! :(

No sweat - text is a crappy medium for frustrated strangers to converse about problems.

> Tried the single image, and it loads fine, and is verified. The main difference
> between your site and mine though is my certificate is 256-bit. When I need to
> force users to use a secure connection, I use a 301 redirect to redirect them
> into the secure page.

Hmm - so I wonder if your problem is different than Allen's, then, because he is seeing the problem on bugzilla as well, in comment 8.  (Or are you saying that you see the problem on bugzilla as well, just not on the single-resource load?)

It might be helpful to step right outside of firefox, and get wireshark or something equivalent to log the packet traffic between your machine and the site that's showing problems, so that we know for sure whether the loads are http or https. If Firefox is confused, it's plausible that it would, in turn, confuse Firebug. Is that doable?
No worries, I'll have to try this at something tomorrow. But I'll let you know the results. Bugzilla appears to go straight into HTTPS mode, the blue mozilla.org appears instantly. Not noticed this issue on any other sites, but to be fair I've not been paying much attention. I'll do some tests on other sites and let you know the outcome tomorrow.

Thanks for your time.
I did try this with 3.5 Safe mode, I do get the same warnings. Does not help, so I am assuming this takes the add-ons out of the picture. So far I have not come across any SSL site which does not have these warnings. I am completely perplexed...
Did you try to connect through different methods and different ISPs to the Internet? Does this happen only at a specific computer, or do you see this behavior on different ones?
I don't have an option doing so. So far I tried only on that one (work computer). If I try to turn off the warning I get the broken SSL lock at the bottom
Allen, can you please do the following:

1)  Start your browser as described at
    http://www.mozilla.org/projects/netlib/http/http-debugging.html, but using
    NSPR_LOG_MODULES="nsSecureBrowserUI" and whatever the right location and
    executable name is for Firefox on your system.
2)  Load a single page that shows the problem (the simpler the page, the better).
3)  Quit the browser.
4)  Attach the resulting log to this bug.
I do not get the warning at https://www.mozilla.org/images/subsite_mozilla-org.gif
(Single resource). However I get it at https://www.mozilla.org/
I will post the logs
I had a little bit of problem creating the log. Instructions from #20 did not work exactly. I set NSPR_LOG_MODULES=nsSecureBrowserUI:5, then it worked.
Log also contains entries from my msnFox home page, but SSL page I went to is :
https://bugzilla.mozilla.org/show_bug.cgi?id=502008
I think this is the relevant bit of that log, although I'm not an expert at reading it, for sure:

0[72b140]: SecureUI:5b1a740: OnStateChange
0[72b140]: SecureUI:5b1a740: 4c42c14 6ba48e0 OnStateChange 10010 data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAB8AAAAmCAYAAAA820BcAAABI0lEQVR42u2VixWDIAxFw0x0JpxJZjIz0SCICGhVQrWfHI%2FKL%2FclARVQNuOfAhpaybkhc4NCNBXwh98WvjW3LbylkEPwgpAqEafh9r12T9iFJm3vhUdZOCUgg%2FnQtxe1gKeOdzmohAOspPpd8CDgUvhhB0zwUwIug3Oc89R2C%2Fg6%2BC4BHL%2Fbe8Ir17dfXGufCzdDH8qD8QBmPZk9Oi0Y4JIuuTIDC00ERGSCS0XONPHVNhxHrJXKAx8I7qAumqWAMhj44XM6ZVoCBN8fdbWAj3dNJVAqAutMEGqC61p4r4xUfQR2EdrIwFUXfEckgDKkgQuuQipl2Pno9MxFXqSeFT7XWkLxfE9HbJzBGbmteemYFz80U3mY4C8nrSSiq4XX2u%2FCn%2BmxBzbdKr8fAAAAAElFTkSuQmCC
0[72b140]: SecureUI: GetSecurityState: - no nsITransportSecurityInfo for 0
0[72b140]: SecureUI:5b1a740: OnStateChange: subreq INSECURE
0[72b140]: SecureUI:5b1a740: UpdateSecurityState:  old-new  4 - 2
0[72b140]: SecureUI:5b1a740: UpdateSecurityState: calling OnSecurityChange
I'm unsure where those data: URIs are coming from, but they're clearly causing this issue.
Seems like it, does it not?
I have some icons defined for my bookmarks folders using a userchrome.css, so I thought they were coming from that. But I deleted the file and I still get them
That image is an icon of an envelope with a hand-pointer: does that look familiar to you at all? (Copy the data URI into your location bar to see it.)
OK I found where the images are coming from, but it did not fix the problem. I had a userContent.css (I will also attach it), which changes the cursor depending what the link is pointing to. Images appear there. So I deleted the file, I am still getting the warning. Looks like in a different place this time. I am attaching the second log.
It's still failing on a data URI:
0[72b140]: SecureUI:598e920: OnStateChange
0[72b140]: SecureUI:598e920: 4c05414 ed9dc40 OnStateChange 10010 data:image/png,%89PNG%0D%0A%1A%0A%00%00%00%0DIHDR%00%00%00%10%00%00%00%10%08%06%00%00%00%1F%F3%FFa%00%00%00%19tEXtSoftware%00Adobe%20ImageReadyq%C9e%3C%00%00%02dIDATx%DA%8C%93_HSq%14%C7%7F%F7o%DB%EE%EE%EEnr%CB2%EF%D46I%D3U*%AE%07%99k%06%11%D5%0C%A1%C0%87%81%90P%BD%AA%3D%F8%5C%3D%06B%D4%5B%09%BDDa%0F%83%40%82%20%82%12%86%20%0C%CC%D1%2C%04%C9%09%B7%D8fk%7F%EE%EE%EE%BD%9D_(m%EB%0A%1D%F8%F0%FBs%CF%F7%DC%F3%3B%BF%F3%23%22%91%08%B22%8A%A20%22A%10%A7%60y%14%E0%80%02%906M3%A1%EBz%16%404%DA%DF%DA%1DN%E1%DC%E0H%A4%EBL%DF%80%B7E%12%9AUU%CD%C4%E3%F1%CFo_%BF%EA%C8%EFd%DE%81%CF%06%E5%F3%F9%10D%AC%03L%E4%5C%EEKc7f%82%C7%3BO%F4%C8%87%5C%12E%124%CB0%BC%A7%AD%CD%D3%DC%D1%CB'%13%CB%A4Z.n%908%8DF%AA%D5j%DF%608%D2%CD%8BM%1E%91%3B%C0%90%04%22%F6%D2%C2s%F9%D8%11%EF%D0%85%AB%BD%D8%8F%AET*V%E9%B7v%F6%F4%CBx%92%CE%16%D5t%16%A9%8D%0E%DD%FE%81%F6%85%F9%87%AD%B4%A6iV%01%04%9B%DD~P7%FE%1C%07u%B5%B8%5C%0D%DF%CD%ADL%89%01%AD%B0_%06ECS%F3%88b%05%10%F3V%0E%84%5E%C9%83%B6HBe%91%05%DF%92%2BK%DB%14IRZ%D50%1A%C5%86a%12%AB%2BK%5B%D8%8F%14E%11%09%82%80x%9EGN%A7%13q%1C%87X%96%5D%8F%BD%98%DFd%F5_ZE7%EB%FB%03nc'%F3%5Dy%F2x.Y(%14%96%C9%C6%E8p%8D%1E%86aFo%DF%BCu%7Fr%FCJ%FCM%ECe%CA%D4JE%3BK%D9%90%AE%96%16c%0B%C9k%A3%17%3F%AE%7DZ%5D%2C%97%CB%3F%88p8%0C)%19%7Bt%3B%1C%DC%D8%D4%D4%9D%BB%D1%E8%F8%BDl6%FB%1Cb%9E%04%BC%00.%E4O%E0%0B%F0%DE%E1p(n%B7%FBo'%C2%9F%CFJ%D2%E1%C8%F4%F4%ECl4z%FD%01%88%9F%C1%F6%3A%B0fUD%E8%01%A4(%0AB%A1P%08%05%83%C1%CB%13%13%93s%89%C4W%D3%EF%3F%FD%88%A6%E9~%FC%16%E0%1D%20%92%24%FF%A1%CEdYF%81%40%60%26%95R%CC%E1%E1%91%A7%20%3E%8F%85%FFk%D8%D3%26I%D2%10%1C!%94%CB%E5%B6!%B5%0F%B0%A7%E3%2Cw%D1jF%ADf%8D%7Dt%1C%00%D7%A1%09%DF%10.E%0D%C6.z%C3X%C7o%01%06%00%B1%B2%24%CE%AE%EE%7C%99%00%00%00%00IEND%AEB%60%82
0[72b140]: SecureUI: GetSecurityState: - no nsITransportSecurityInfo for 0
0[72b140]: SecureUI:598e920: OnStateChange: subreq INSECURE
0[72b140]: SecureUI:598e920: UpdateSecurityState:  old-new  4 - 2
0[72b140]: SecureUI:598e920: UpdateSecurityState: calling OnSecurityChange
0[72b140]: SecureUI:598e920: OnStateChange: progress: for toplevel


Seems like a bug that a data: URI would cause it to be insecure, but I guess I don't know the specifics here. That particular URI is a picture of a magnifying glass.
The origin of data URIs matches whatever link/script created them; so if userContent.css or some extension created those URIs they indeed wouldn't match: I'm not sure whether that's something we could/should fix... should userContent.css be treated as a system-principal or something special exception to the rules here?
My understanding is, data resides on users computer, why would it cause a legit SSL page to be mixed content?
Also userContent.css or any other extension which creates this type data URIs should not cause warning and cause it to be mixed content SSL page. Quite a bit people  use them
That last data image has been created by an extension/plugin. I deleted the files and started in Safe mode I did not get any warning. So that is the workaround, the question is how and when can this be fixed?
Summary: Warning about unencrypted content in SSL pages when none exists → Warning about unencrypted content in SSL pages from data: URIs inserted by userContent.css or extensions
If this is Dave's problem as well, then this bug is a duplicate of bug 477118, which has a patch waiting for review.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Warning about unencrypted content in SSL pages from data: URIs inserted by userContent.css or extensions → Warning about unencrypted content in SSL pages when none exists
(sorry ted - collided your summary change - fixing)
Summary: Warning about unencrypted content in SSL pages when none exists → Warning about unencrypted content in SSL pages from data: URIs inserted by userContent.css or extensions
Well since Allen is the original reporter, duping.

Dave: if you find that your problem is due to some other root cause, please file a new bug, since that will make it easier to track. Logs like those Allen attached will definitely help pinpoint the problem.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
I don't remember whether my previous version was 3.xxx or 3.1.xxx. If it was 3.1.xxx, I can confirm that the bug did not exist at 3.1 (that bug above says it was there for 3.1). Except that this sounds like exactly the same problem I am having...
Resolution: DUPLICATE → FIXED
Resolution: FIXED → DUPLICATE
I can confirm this bug as well. I have this also since the first version of FF 3.5 and all consecutive versions up to 3.5.7. I also have it now with FF 3.6. Never had it with FF 3.0.

I have the same symptoms as described here and also the same workaround: press F5 to reload the page mostly helps a lot. I just tried also with a new clean profile without addons, but doesn't make a difference.
I forgot to mention that I don't always have it. Mostly about a third of the time (of SSL-page browsing). There are sites who sometimes do this, sites who never do this and sites who always do this.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: