506008 - "Warning: Contains unauthenticated content" appears even though page is fully secure

Status: RESOLVED DUPLICATE of bug 947079

(Core :: Security: PSM, defect)

Description

[Dave]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1 (.NET CLR 3.5.30729)

Since the release of Firefox 3.5, some secure pages are detected as containing unauthenticated content, even though Page Info states all media is secure. Refreshing the page makes the message disappear.

Reproducible: Always

Steps to Reproduce:
We use Apache to redirect users automatically to pages that require the connection to be secure. When the user is redirected from a non-secure to secure page, this is when the error appears. However, click a link on the page which links to a secure page, i.e. not using redirects, and it loads first time no problem. This suggests Firefox is reading the last request (which was in-secure), thinking this is still the case. Refreshing the page of course means the last connection wasn't a redirect - technically a direct link (refresh) and it sees this as secure. Just my opinion of what it's doing.

Please use http://www.readesresidential.com/ as an example. Clicking Sign In which uses a redirect, causes Firefox to display the error. Whereas link directly to another secure page, such as https://www.readesresidential.com/register/ and it works no problem.

Once you have refreshed the page and Firefox says the page is secure, sometimes the issue doesn't reoccur when clicking on to a non-secure page and then back on to the secure page (via the redirect), but sometimes it does.



This issue has the potential to make people think the page they're looking at is not secure. I cannot replicate this issue in any other browser, the issue was first noticed with FF 3.5. Upgrading to FF 3.5.1 hasn't resolved the problem.

Let me know if you need any further details.

Comment 1

[Matthias Versen [:Matti]]

Do you mean bug 477118 ? 
I have no issue if I don't login and get no mixed content warning.

Comment 2

[Dave]

Oops, didn't see that one. I posted this a few weeks back but that bug got closed because it was a separate issue to this one, but they told me to recreate it if it was still a problem.

I couldn't replicate it on the sign in/register pages, bad example, try this one instead... http://www.readesresidential.com/pitmans-lane-hawarden-flintshire-ch5-3ee-p1028/ then click "arrange viewing" on the left. For me the page redirects to secure, but the warning icon appears at the bottom.

Comment 3

[Matthias Versen [:Matti]]

I can confirm this issue with SM trunk and FF3.5

Comment 4

[Dave]

Nice one. Also if there are any UK devs or testers on here who are on Be Unlimited broadband, try logging in to the forums and you'll notice every forum page, has the same issue as mine. Even a refresh doesn't resolve the issue on the Be forums. Their software is phpBB, so not sure if it happens with other phpBB communities that operate under a secure connection.

Comment 5

[Honza Bambas (:mayhemer)]

There is apparently a problem. Going to take a look at this.

Comment 6

[Honza Bambas (:mayhemer)]

Regression from bug 135007.

Apparently we are taking into account image loads that are loaded for button face in onmouseover events. The bug is that it should be target to the current document and not the page newly loading (after you click the "arrange viewing" button).

This won't be an easy fix at the first sight.

Dave, thanks for this report and the test environment.

Comment 7

[Dave]

No worries mate.

Comment 8

[Honza Bambas (:mayhemer)]

In reality:
- we do request for http://www.readesresidential.com/pitmans-lane-hawarden-flintshire-ch5-3ee-p1028/arrange-viewing/
- we get redirect 301 to https://www.readesresidential.com/pitmans-lane-hawarden-flintshire-ch5-3ee-p1028/arrange-viewing/; at that moment security UI gets onStateChange and we reset all subrequest security counters and set security state to SECURE (4) in this callback
- then, when user moves mouse over buttons, onmouseover reloads background of a button and we get onStateChange with http:// image reference that counts as INSECURE subrequest (the original page still processes events)
- then we get onLocationChange callback after server returned 200 and security UI changes the state from 0 to 2 (there are already those INSECURE subrequests encountered)

I'm not sure of the onLocationChange callback implementation and the true meaning but a simple fix for this bug would be to reset the subrequest counters (in case of a top level document).

I have to check this solution is correct. Btw, onLocationChange callback implementation probably already suffers from other missing checks and code.

Comment 9

[Dave]

Just thought I'd provide you with a new URL since we've upgraded our site and moved to EV SSL certificates.

https://secure.readespassport.com/pitmans-lane-hawarden-flintshire-ch5-3ee-p1028/arrange-viewing/

Comment 10

[Honza Bambas (:mayhemer)]

(In reply to comment #9)
> Just thought I'd provide you with a new URL since we've upgraded our site and
> moved to EV SSL certificates.

Thanks, now I have an automated test for this, there is no need to keep any testing code now.

Comment 11

[Honza Bambas (:mayhemer)]

Attachment: v1

First version of the fix including the test. We must reset sub-request counters in onLocationChange callback that indicates start of load of the new URI (after we got finally 200 from the server as a response to the redirect URI).

Jeff: please review the changes to httpd.js and head_utils.js

Kaie: please review the rest, including the tests

Comment 12

[Jeff Walden [:Waldo]]

Why isn't is sufficient to simply hand-roll the delay as demonstrated in the "Advanced dynamic response creation" section of this document:

https://developer.mozilla.org/En/HTTP_server_for_unit_tests

I don't see a particular reason why this code needs to be in-server rather than defined by the SJS pages themselves.

Comment 13

[Honza Bambas (:mayhemer)]

Attachment: v1.1

(In reply to comment #12)
> I don't see a particular reason why this code needs to be in-server rather than
> defined by the SJS pages themselves.

Oh, I didn't know this is possible. Test fixed.

Comment 14

[Honza Bambas (:mayhemer)]

Comment on attachment 393733 [details] [diff] [review]
v1.1

This patch is wrong. It breaks fix (full) for bug 329869, I have to investigate further.

Comment 15

[Jeff Walden [:Waldo]]

(In reply to comment #13)
> Oh, I didn't know this is possible. Test fixed.

Do note that you need to keep a reference to the timer until it fires; just a local variable like that could, conceivably, not be such a reference because a GC could end up not keeping the reference.  That's why the example I had on that page stored the timer in a global variable, although it seems I didn't make that clear in the docs (thought I had at one time, seems not).

Comment 16

[Dave]

Just wondered if you know when this bug will be fixed? Thanks.

Comment 18

[Paul]

Hello all. Similar to bug 552789 reported in March 2010. 

https://bugzilla.mozilla.org/show_bug.cgi?id=552789

Comment 20

[aploshko]

IMPORTANT QUESTION THAT NEEDS TO BE ANSWERED:

If this is happening with a page like Gmail, is your password being sent over an unencrypted connection or is it secure?

Thanks.

Comment 21

[aploshko]

It does happen on Gmail: sign into a gmail account, then sign out: you are taken to the sign-in page again but it is displayed as insecure.

Comment 22

[Matt Boothman]

Has anyone got a resolution date for this? It's really old and should have been fixed by now! Every other browser seems to handle this type of thing correctly but FireFox and it's seriously affecting our business.

http://www.prestigecarservicing.com/

Click on Book Now

Takes you to our secure booking page

https://www.prestigecarservicing.com/contactus.html

Connection partially encrypted

Refresh page

Connection Encrypted.

Can someone get back to those of us who have been very patient and are probably now getting seriously annoyed, with either a workaround or an estimated date for when we can expect a fix please?

Comment 23

[Honza Bambas (:mayhemer)]

Releasing for now but still on my radar.

Comment 24

[alex_mayorga]

Ended up here from bug 723580.

I still can reproduce what's described in comment #0 on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:13.0) Gecko/20120224 Firefox/13.0a1 ID:20120224031039.

Changing version and platform accordingly FWIW

Comment 25

[J.A. Slurink]

FWIW: I'm able to consistently reproducing this bug using Firefox 18.0.2 on Mac OSX Mountain Lion, Software  OS X 10.8.2 (12C60)

If someone needs steps how to reproduce, please contact me.


Best,
J.A. Slurink

Comment 26

[Tanvi Vyas[:tanvi]]

Hi Dave,

I see that the webpage and signin has been moved from www.readesresidential.com/ to www.reades.co.uk.  The sign in and register pages are now over HTTP, and trying HTTPS gives me a cert error.  Did you move login off of HTTPS because of this bug?

It should be fixed in Firefox 39 (bug 947079).