Logging in to my Citibank account last night, I noticed the lock icon in the bottom-left had a red slash through it. Hovering over it simply said "Signed by Verisign Trust Network", or somesuch. Double clicking and looking through all of the properties showed nothing wrong. Wasn't expired, the names matched, all of that stuff. Web search, bugzilla search, and IRC channels turned up no hints as to what this ominous red slash meant. With all the Citibank fishing scams lately, I was quite unnerved about logging in to my account, but had to anyway after an hour or so of investigating turned up nothing. Whatever this red slash is, mozilla needs to VERY CLEARLY indicate what's going on. Linux Firefox 0.9.1.

Reporter: what theme/skin are you using?

The standard, default, whatever it's called this week. Clean profile.

According to discussion in Bug #251472, "The lock with the slash through is because it's a secure page which has content (images) loaded from an insecure location...". This is bad UI though. It should explain better when you hover.

->Browser, since Mozilla doesn't describe it either. Changed summary to (hopefully) fit more themes and still make sense.

Bugzilla puked while changing component. Trying again.

Well, I must say, a small visual indication rather than a popup warning is a vastly improved experience for mixed-mode https pages. But I think a big red slash is way too ominous for this degraded mode, unless there is a huge potential for information leakage that I'm not informed about, as all cases I've ever seen have just been harmless sites set up poorly. The red-slash is a lot more scary than a page without the lock icon at all. Submitting, credit card info to a company I trust, without encryption, isn't too ridiculously risky, in my opinion. A big red warning graphic (apperantly) indicating that something's already fishy with this site was a lot more worrysome to me. Though with a tooltip and a better icon, this is a huge usability win. Bravo, UI folks, fantastic idea. It's a wonder it wasn't thought of 10 years ago. (Sorry though, no great suggestions offhand for what the visual indication SHOULD be. Perhaps a slightly greyed out lock? Firefox may have some more flexibility for presentation here with the new secure page indicator UI on the trunk.)

Jeremy, the issue of how ominous the icon looks is up to skin designers. I do think it's good to make it look dangerous, because it's possible you're looking at a page with an insecure subframe from a malicious site. Knowing that you're getting some insecure data is good. But I'm not a UI guy. Anyway, after some hunting, I think a tooltip could be added/modified by adding a string to http://lxr.mozilla.org/seamonkey/source/netwerk/resources/locale/en-US/security.properties#51 called something like "SecurityButtonMixedEncryptionTooltipText" but less ridiculous, then moving the code from http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/nsBrowserStatusHandler.js#380 up a few lines into the switch(), to append the mixed-encryption text in the mixed security case. The guys in #developers are busy right now, but if I get a chance to run this by them and they think that's a good solution, I can probably implement the change.

Chris, that sounds like a reasonable approach.

The tooltip is going to get longer, thus this bug depends on either bug 67127 or bug 45375 for best results.

As written, fixing either 67127 or 45275 will make this work.

-> XP Apps: GUI Features

Why not make it something simple like "Warning: mixed content"

I copied the wording from the original "mixed content" warning text. I figured the user might still care who it's signed by, and not know what "mixed content" is, unless they remembered the original annoying dialog they dismissed without reading. Of course, there's a whole other bug with that... https://www.andrew.cmu.edu/~cst/securetest.html contains an iframe signed by verisign, but Moz only tells me it's signed by Thawte. If I didn't trust Verisign, that might be a problem.

Comment on attachment 153847 [details] [diff] [review] Patch v1 Personally I think a better place to fix this would be in nsNSSCallbacks.cpp, because otherwise you're never going to be able to localize this properly.

I traced through the code again after modifying my testcase to use Google instead of non-SSL Verisign, and it only runs through once (when it loads the actual page). At that point, everything is secure, so sslStatus is secure/not broken. When the browser loads the Google iframe, this code doesn't get run, so I can't change the tooltip from there. The JS reads the SSL status from nsIWebProgressListener, not its "getBrowser().securityUI", so unless whatever component actually knows that the state is broken can also set the properties of "getBrowser().securityUI", the change has to live in JS, or something bigger has to be done.

If Firefox is going to be released to the public at large the current solution of slashed lock is totally inacceptable. Non-specialist users will never understand why their bank connection is considered only partially secure. The reasoning behind the slashed lock may be right, but will not sell. What are users expected to do? Tell their bank that the lock is slashed? You know the answer: use IE. Having secure and unsecure data on the page may be correct if the data which has to be secured is secured. Can this be detected? If not, then the connection should be displayed as unsecure, period. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040811 Firefox/0.9.1+ (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040811 Firefox/0.9.1+)

I totally agree with Raanan, I myself had to search why my bank connection was considered insecured. I did understand it only after having found this bug, and I still don't know which elements are insecured, since I found nothing that come from a non-secured website.

When someone tells me where to make the fixes (or I have enough time to hunt around on my own), I'll fix this. I can think of an ugly hack to do it in JS, but it would be r-'ed. Otherwise, it'll sit until someone who has the knowledge and motivation fixes it him/herself.

After re-reading the posts here, a question came to my mind, which i hope someone can provide an answer for: is there a standard defining what a "secure" page should contain and what it should not contain? Unless such a standard exists and can be pointed to when raising the issue with banks and other service providers using this technology it will be difficult to justify "half secure" locks. If the standard exists, then this half-secure lock should be defined there and only then used in applications.

In my opinion, a page is secure (and deserves a solid lock icon), only if all displayed information, including all frames and images and plugin objects, was transfered over an encrypted channel, and for each displayed piece of information, the originating party used a valid (trusted) certificate. That is, secure means, for everything that is displayed - we know it was encrypted during transmission - we know for sure who sent the data, because the sender authorized itself Now what is the definition of a "mixed security lock" or "half secure lock"? Whenever there is at least one piece of displayed information that arrived without encryption or from an untrusted origin, the "half secure lock" should be used. Or, in other words, if only "some" displayed content is secure, a mixed lock should be shown. However, Mozilla has a deficiency that is described in bug 135007. As of today, if you look at a page that contains images, and the images have been transfered without encryption, or has an untrusted origin, we still show a secure lock icon! We should really show a "mixed security" icon in that situation, but that requires bug 135011 and bug 135007 to be fixed. Unfortunately, until today nobody invested resources to fix this deficiency. In my opinion, it was an unfortunate decision made by the original implementors of security in Mozilla, to not care for this situation. In my personal opinion, bug 135007 is much worse than this bug 251123. Unfortunately, at the time of writing comments in bug 135007, it turned out to be complicated to fix the deficiency, since the fix required the image library to get enhanced and communicate the security status to the crypto component. Please see the comments I made to bug 135011 and bug 135007 that I made over two years ago.

Kai Engert is probably correct in the analysis of the security issue (comment #20). However, I am not sure that it is up to Mozilla to set a standard if none exists. In my opinion, if the approach suggested by Kai is to be adopted, it must win acceptance in the security circles. Only then will it be possible to refer to a standard when talking to third parties about the quality of their security, and to develop the corresponding mechanisms to implement it.

In comment 20, Kai explains what the lock icon (and its predecessor, the key icon) has meant since the beginning of the Netscape/mozilla series of browsers. He is not proposing any new standard, but merely explaining the way things have been consistently for the last 10 years.

Well, things have not been consistent with Firefox since the issue was raised here on July 2004. I was not implying that Kai was suggesting a new standard. I was merely saying that it would be much easier for developers as well as users and information providers to have a standard defining what a "fully secure" means and how to consider a "partly secure" icon. There may not be a need for full security in all instances, and it should be clear to a user what the "partrly secure" icon means, not in technical terms but in functional terms. If my bank sends all the sensitive data encrypted over a secure link but sends its logo unencrypted, then this may be OK - if the standard says so - and no slashed lock should be displayed. A user needs to have confidence in the system. Displaying a slashed lock, even with an explanation (some items were not ...) does not help inasmuch as these items are not identified. Once again, a standard will help users, information providers and developers to work in confidence. If Mozilla considers this as an importaqnt feature then it should promote an international (internet?) standard to that effect. That will certainly help in marketing the compliant products.

This affects l10n, it needs blocking- or a string to land within 24 hours.

sounds like we are going to have to try and deal with this post 1.0.

This needs to be fixed in all browsers-->core security

*** Bug 288609 has been marked as a duplicate of this bug. ***

is anyone working on this? was nominated as blocking the branch for 1.8. is this really a blocker? it looks like the sort of thing that could land after the branch. /cb

affects l10n, are we serious about branchpoint being the string freeze?

not going to block our branching.

Looks like my report, bug 263182, may be a duplicate of this

Bug 263182 fixed the dialog behind the lock, but this report is right, the tooltip still implies that the page is signed & secure.

Taking.

Suggestion for tooltips: lock: "Verified by %S and fully encrypted" slash-lock: "Verified by %S but only partially encrypted" or, if you share my suspicion that the names of signing agencies are meaningless less wordy: lock: "Fully encrypted" slash-lock: "Partially encrypted"

(In reply to comment #34) > lock: "Fully encrypted" > slash-lock: "Partially encrypted" Encryption is only part of what SSL gives you. The more important part is the assurance--to the extent you trust the signing agency--that you're talking to the site you think you are. People generally don't understand that and we're not going to educate them in the space of a tooltip, but using only "encrypted" reinforces their mistaken belief. Currently we're using the vague "Signed". May not clarify much, but at least it doesn't mislead. "Secured by" might also work. slash-lock: "Verified by %S but only partially encrypted" "Verified and encrypted" is great (if wordy), but in the slash-lock case it's "partially (verified and encrypted)", it's not just the encryption that's partial. I don't want to lose the %s for the secure case, but we could lose it in the mixed case and say "Contains verified and un-verified content" (or signed and un-signed). Or since we don't like this state and want people to be suspicious of it, drop the positive and go with "Contains unsigned and unencrypted content/elements/whatever".

based on dveditz's comments, I'd suggest: lock: "Verified by %S and encrypted" slashlock: "Contains unverified and unencrypted elements" however, I'm still wondering if we need to use big words like "verified" and "encrypted" in the tooltip, as opposed to something simpler like: lock: "This page is secure (%S)" slashlock: "This page is partially secure" My feeling is that while these strings are less precise, they are more understandable by the common user. I'm not 100% convinced that we even need the %S to be shown in the tooltip, either. I'll defer to dveditz' judgement, however, if he feels that it's important we use certain key words in the tooltip.

I chose simply "Contains unsigned content" for now to fit in with the current "secure" tooltip. I think that if the wording needs revisiting then it's probably best done seperately. Seems like nsSecureBrowserUIImpl is the only one in position to know about overall page security status (since it determines it!), so the check goes there instead of in nsNSSCallbacks, which doesn't know about other loads. Ideally I think nsSecureBrowserUIImpl should construct it's own tooltip, getting the issuerName from mSSLStatus, and not depend on nsNSSCallbacks.

Gavin: that's probably the right thing to do. I've forked simplification discussion to bug 315141.

SSL never signs content, so the "contains unsigned content" tip is not too meaningful, and perhaps misleading (by implying that SSL content is signed). SSL verifies the *source* of the content of an https page, (this is sometimes called the "authenticity" of the content") and (optionally, but typically) provides secrecy (encryption) of the content. One might say that the non-SSL components of a mixed page are unauthenticated and unprotected (unencrypted). One might say that an SSL page is authenticated by %S and protected (or encrypted).

> SSL never signs content However, our current tooltip UI says "Signed by %S" I see two possible strategies: a) Change "mixed tooltip" only. We continue with the current "good tooltip" message, that uses wording "signed by". If we do so, the wording for the "mixed" situation should be similar. Gavin suggested "contains unsigned". IMHO we should make it very clear that something is wrong with the currently displayed page. What about "Error: Only portions are signed by %S" ? b) Change existing wording, too. Follow Nelson's complaint, that "signed by" is inappropriate. Come up with a better wording, that is clearly understandable for end users, and tells the truth. Nelson's suggestion: "Authenticated by %S". But is "authenticated" clear to the average user? I looked at "page info / security". In that dialog we say "Web Site Identify Verified". Why don't we follow that wording and use it in the tooltip, too? Proposal for good tooltip: "Web Site Identity verified by %S." Proposal for mixed tooltip: "Error: Only portions of this Web Site are verified by %S."

Comment on attachment 201824 [details] [diff] [review] patch v2 I'm rejecing this patch for now, because we don't have a wording agreement yet. While the patch is fine for simple wording, we'd have to adjust it, should we decide to use %S in the wording.

I'd suggest that we use this bug to fix the fact that the tooltip doesn't correctly indicate that there's a problem with the page, and then use bug 315141 to discuss revising both messages for clarity & accuracy. One question that I've never had answered clearly: is something wrong when the page contains signed and unsigned content? Is there any legitimate case for that? If not, then I'd suggest "Warning: Contains unsigned content"

> One question that I've never had answered clearly: is something wrong when the > page contains signed and unsigned content? This scenario means, the web site authors failed in their attempt to provide a site, that uses secure protocols to transmit all displayed content. If some of the shown content was not transfered using secure protocols, in my opinion, this is as bad as having no security at all. The user has no idea which portions on screen are "secure" and which are not, so the user should not trust any of them. Rather than "mixed security" we should call it "broken security". > Is there any legitimate case for that? I'm not aware of intended cases. I think, when the browser displays that situation, the web site authors should be informed and fix their site.

FWIW, IE 7 is not going to display non-secure content on secure pages by default. "In addition, users will no longer see the so-called Mixed-Content prompt, which read: This page contains both secure and nonsecure items. Do you want to see the nonsecure items? IE7 renders only the secure content and offers the user the opportunity to unblock the nonsecure content using the Information Bar. This is an important change because very few users (or web developers) fully understand the security risks of rendering HTTP-delivered content within a HTTPS page." From http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx

Yes, I know. But before we can do that, we must fix other bugs first, bug 62178 and bug 135007. Those bugs will have to provide the infrastructure, to allow us to actually block that content...

Regarding comment 44 and IE 7's UI changes, how does moving the user's choice from a modal dialog to an "information bar" increase the security?

Nelson, If I read this correctly, the answer is that IE won't even prompt the user and not display the insecure part of the mixed content - it will only show the secure part of the content, unless the user goes to the info bar and turns on the insecure part explicitly. Since there will be no dialog shown to the user that he can click through, I think security is improved.

IINM, the info/security bar is a thin bar that goes accross the top of the window that displays the page content. It provides a means for the user to "click through" and get the missing parts of the page. The big difference seems to be that the dialog required the user to make a decision and click yes or no, and the new approach makes this choice optional, but no more difficult. If the argument is that, given a choice, the users will always choose to display the missing content, then how is the new behavior more secure than the old, given that both behaviors give the user a way to get the unencrypted content?

I think the argument is that when annoyed by a dialog box that defaults to "yes, show me the insecure content" users will choose to see the insecure content. And be annoyed that the browser asked. This way users will *not* see the content by default. Inertia argues many won't then go turn it on, especially if the way to do so is in a bar that looks like the "annoying popup content" bar. And then if the user does turn on the content they'll have a clue which parts were insecure and will, one hopes, be suspicious of the new stuff that shows up. Sounds good to me, actually, better than saying "something somewhere did not use SSL--have fun guessing." IE probably has to do this to provide some way to see these pages because both Netscape and Opera will show the full content (with a mixed icon, or in our case sometimes without the mixed icon if it's only insecure images).

Can we agree with the suggestion made in comment 42? Which is, - say "Warning: Contains unsigned content". And NOT mentioning the name of the CA) - move other rewording work to a separate bug. In my opinion it seems to be a reasonable suggestion, as we currently indeed say "Signed By %s" in the user interface. Nelson, David, Julien, if you agree with this proposal, I'm willing to grant r= to the patch.

How about: Page contains some unauthenticated content. or WARNING: some content unauthenticated. or WARNING: some content not authenticated. Is anyone willing to consider doing the "secure by default" thing, and displaying/using only the stuff received by https unless/until the user asks it to also display the unauthenticated stuff?

Nelson, Yes, I think it is a good thing to show only the content from authenticated sites by default, and have an option (but not a dialog with a prompt) to show it in the UI, uppon request. If the rendering engine allows, maybe that content should be shown in monochrome and the in RED to show that it is the insecure content ;) Or even better, in big BLINKing red. I just talked to Nelson about it and he approves. Re: the wording, I don't have strong feelings, but I think we should be more accurate. As you pointed out earlier, it isn't the content that is being authenticated, but the site. I would prefer if the UI talked about content from an authenticated site vs content from an unauthenticated site (or replace site with server if you prefer).

Here's the same patch as v2, with "Warning: Contains unauthenticated content" instead of "Contains unsigned content." per Nelson and Mike's suggestions. I think it's probably best to get this landed and then worry about perfecting the wording (for both cases) in bug 315141.

Comment on attachment 202857 [details] [diff] [review] patch v3 (checked in) r=me in that yes, we need a new tooltip, and this one is as informative as the tooltip for properly secured content. Not sure if bug 315141 should block this one or not, but I should at least register the fact that I don't see the text of these tooltips as final. Thanks, Gavin.

I'm fine with the wording suggested in the previous patch. I suggest, if we indeed introduce the wording "authenticated", we should at the very least be consistent. I'm attaching this additional patch that IMHO should be used together with patch v3. It changes our corrent hovering text "Signed by" to "Authenticated by".

Comment on attachment 202857 [details] [diff] [review] patch v3 (checked in) r=kengert assuming this patch is used in combination with the other one

Comment on attachment 202995 [details] [diff] [review] patch v3 addition - to achieve wording consistency (checked in) sr=dveditz

Comment on attachment 202995 [details] [diff] [review] patch v3 addition - to achieve wording consistency (checked in) >Index: security/manager/locales/en-US/chrome/pipnss/pipnss.properties pipnss.jar appears to have been removed from Firefox (and in 1.0 contained only a contents.rdf). Is this part of the change expected to do anything?

Comment on attachment 202857 [details] [diff] [review] patch v3 (checked in) sr=dveditz

(In reply to comment #58) > >Index: security/manager/locales/en-US/chrome/pipnss/pipnss.properties > > pipnss.jar appears to have been removed from Firefox (and in 1.0 contained only > a contents.rdf). Is this part of the change expected to do anything? Yes, pipnss.properties is now packaged in ab-CD.jar (see http://lxr.mozilla.org/seamonkey/source/security/manager/locales/jar.mn#11)

In fact, it looks to me like the other entity (from pippki.properties) isn't used anywhere. It dates back to when the file was originally added, so it could probably just be removed.

Comment on attachment 202857 [details] [diff] [review] patch v3 (checked in) mozilla/security/manager/locales/en-US/chrome/pipnss/security.properties; new revision: 1.2; previous revision: 1.1 mozilla/security/manager/boot/src/nsSecureBrowserUIImpl.cpp; new revision: 1.52; previous revision: 1.51

Comment on attachment 202995 [details] [diff] [review] patch v3 addition - to achieve wording consistency (checked in) mozilla/security/manager/locales/en-US/chrome/pipnss/pipnss.properties new revision: 1.2; previous revision: 1.1 mozilla/security/manager/locales/en-US/chrome/pippki/pippki.properties new revision: 1.4; previous revision: 1.3

Both patches checked in, marking fixed. Thanks all!

Both patches landed on the 1.8 branch. mozilla/security/manager/boot/src/nsSecureBrowserUIImpl.cpp; 1.48.2.3; mozilla/security/manager/locales/en-US/chrome/pipnss/pipnss.properties; 1.1.8.1; mozilla/security/manager/locales/en-US/chrome/pipnss/security.properties; 1.1.8.1; mozilla/security/manager/locales/en-US/chrome/pippki/pippki.properties; 1.2.6.2;