441831 - Identity information for site with mixed content says connection is not encrypted

Status: VERIFIED WONTFIX

(Firefox :: Address Bar, defect)

Description

[Gunnar Wolf]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008062112 Iceweasel/3.0 (Debian-3.0~rc2-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008062112 Iceweasel/3.0 (Debian-3.0~rc2-2)

Opening the above mentioned URL gets me through the "are you sure you trust those scammers?" dance - All fine, all fine. However, even if the page is retrieved via HTTPS, it says the connection is not encrypted - Please look at http://gwolf.org/node/1838 for a screenshot if needed.
This does not happen with every self-signed SSL page - in fact, so far, I have not been able to reproduce it in any other site (not that I tried too hard, I tried with two others)
I am not using an official Firefox build, I saw this on Debian's Iceweasel. I will try to reproduce it with an official Firefox as soon as possible.

Reproducible: Always

Steps to Reproduce:
1. Open https://penta.debconf.org
2. Accept self-signed certificate, grant exception
3. Look at the address bar. It's still white!


Expected Results:  
It should show the security information, warning that it is a self-signed certificate, but that the connection is secure

Comment 1

[Matthias Versen [:Matti]]

The address bar in Firefox3 will not turn yellow, at least not in official builds.
Firefox3 displays that the page is only partially encrypted and that is correct.
(For example the .css file is loaded from http:)
Seamonkey (which still displays the yellow address bar) is displaying it white which is also correct because the page is only partially encrypted.

marking invalid, please reopen if you disagree 

Comment 2

[Gunnar Wolf]

Umh... No, of course, I know the current builds no longer show the whole address bar in yellow - but even if the page has some insecure elements, the user should not be led into believing _all_ of the data went in clear - The connection is clearly crypted, even if some elements are not. So... This should at least be explained to the user in the new security information window (what's its name again?)
Thanks,

Comment 3

[Matthias Versen [:Matti]]

The whole page is clearly not encrypted and it's not secure if only a part of the page is encrypted. You can not say which part of the page is encrypted, it could be 1px invisible frame at the top that comes from https and everything else on that page could be unencrypted. You have to show it insecure even if some elements are encrypted.
Firefox shows at closed lock with an red exclamation mark at the bottom right.
If you click on this lock you get the Page info window and it shows under Technical Details:
"Connection Partially Encryped".

This is the best solution and i can not see a bug here -> invalid

Comment 4

[Gunnar Wolf]

I won't play ping-pong with bug reports - Last re-opening.
I'm not suggesting to tell the user the connection is «completely trustable and encrypted», but to say -as I recall some browsers did in the past- that «some elements in this page were received over a secure channel - But some were not». I think it is much closer to reality, and much more acceptable to the general public.

Comment 5

[Johnathan Nightingale [:johnath]]

Gunnar - I appreciate you reporting this, and making the case for your opinion, but I disagree that your suggested approach is closer to reality, or more acceptable to the general public.

The general public, as a rule, doesn't understand thing 1 about encryption, to say nothing of mixed-content partially-encrypted composite web pages.  You recognize that, I'm sure, and what we are both trying to do is figure out what is best to communicate to them, vis a vis the integrity of the content delivered, and the confidentiality afforded to the user.  In a page with mixed content, there is effectively zero integrity of page content, and also no confidentiality of information.

There is zero integrity of page content, because the http retrieval of stylesheets allows me to replace the content nearly arbitrarily.  At the least creative end of the spectrum I can use CSS to hide all the legitimate page content, and pull in graphics which represent alternate content, but I feel that if I were creative I could do all kinds of more exciting things.  In any event, the integrity of the content rendered for the user in mixed-mode is nil.

There is nearly zero confidentiality of information, since the same CSS injection would let even the very uncreative do things like this: http://jeremiahgrossman.blogspot.com/2006/08/i-know-where-youve-been.html

Notice in both of these cases, I'm deliberately talking about CSS-only attacks - I hope it's clear that in the case where a page is pulling script insecurely, things are magnificently worse.

Suggesting that we call this page "sort of secure" or "parts are secure, parts aren't" assumes that giving users that information will allow them to reason more effectively about the integrity of the site than the current message.  I don't believe that to be true.  I think that a general user, seeing that message, would not suspect the scenarios I outline above to be possible.  The idea that "some of the content is secure" is not going to equip people with a mental model that says "of course, the unsecured javascript has made the page 100% different, and the the parts that were delivered securely are no longer part of the page."  I will make that as a flat assertion.  It is substantially preferable to me to have users treat that page as entirely insecure, because there is no meaningful difference between this page and an entirely insecure one, as regards the expectations they should have when interacting with it.

I understand that you don't want to play ping pong with this bug, and neither do I, but the change you suggest is not one that I think we should take for the reasons outlined above.  As such, I'm going to mark this bug WONTFIX.  I really do appreciate your attention to the issue, but please do not re-open this bug unless you intend to suggest that I have misunderstood things in a profound way, and that mixed content is somehow immune to the tampering I describe.  As long as it is possible to alter a mixed-content page in basically arbitrary ways, I will not support a primary UI that tries to treat one as "more secure" than the other.

Comment 6

[Matthias Versen [:Matti]]

The summary is something about a self signed certificate but the self signed certificate doesn't matter in this case.

If you go to a page with mixed content, can you tell me which part of the page is loaded over https and which is loaded over an unsecure http connection ?
In this case it's only a css coming over http but it could be near the whole page if you use a framed page or if you use a external JS File. There is no difference in security between a page loaded over http or a mixed content page because nobody can know which part a mixed page is secure and which is not without looking at the source.
Does your grandmother understand HTML, JS, CSS and can look at the page source to identify the secure parts of such a page ?

BTW: Firefox tells you that a part of the page is encrypted, just look at the yellow closed lock icon at the status bar with the red "!".