47496 - Lock icon showing secure on mixed content site.

Status: VERIFIED FIXED

(Core Graveyard :: Security: UI, defect, P3)

Description

[John Unruh]

1.) Visit the above URL or https://junruh.mcom.com/mix.html.
What is expected: A mixed lock icon, since the content is a mix of secure and 
insecure.
What I see: A locked icon.
Commerical Linux and Win32 builds 80304.

Comment 1

[John G. Myers]

This was caused by the "fix" for 47010.

Comment 2

[John G. Myers]

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

Comment 3

[John G. Myers]

Any fix for this bug is likely to run up against bug 48515.
This bug would be fixed by bug 31982.

Comment 4

[Michael La Guardia]

I would suggest that users should be able to trust what the lock icon is saying,
and if the icon is to err, it should be on the side of showing the page as less
-- not more -- secure than it really is.  As such, I'm marking this nsbeta3+ and
setting the priority to 2.  Please feel free to disagree.

Comment 5

[Jim Roskind]

I thought this was the classic case of a site showing poor security, and we're
trying to warn off a user.  Note that the *example* seems to talk about two
frames, one of which *submits* via HTTPS, and the other does not *submit* via
SSL (i.e., it uses HTTP).
I'm used to seeing mixed content when the page was sourced incorrectly (part was
sourced via httpS, and part via http (typically some gifs etc.)).  Is the
example wrong, or is this that classic case?

IMO, we should go to P3 for the classic case.  It is just beyond our capability
to warn about all the bad things that folks with certs can do on their site.
The lock icon simply shows that they had a cert in use for some of the data links.

Comment 6

[selmer (gone)]

This can easily be fixed on the secure server, moving to PDTP3.

Comment 7

[Andreas Franke (gone)]

Maybe I don't get it, but wouldn't this be perfect food for the "evil" press?

"You think you can trust Netscape? You believe in what their browser tells you?
You're naive! You want an example? .... " and a decent reference to this bug...

And the best: "And, guess what, they know it for ages, and yet they don't do
anything about it. What does that tell you about them?" and so on...

Suggestions welcome where to post this to get the widest attention... ;-)

Seriously, if I knew that bugs like this are being futured, I'd think twice
before using Netscape 6 for home banking. Please reconsider. Nominating for RTM.
See the comments from Michael La Guardia in this bug for the reasons.

Comment 8

[Jim Roskind]

I think you're not getting it Andreas.  This is not about security.
Do you complain about the "security" at a bank that you enter, when you note 
that you can steal their pens from their deposit tables?  The critical point in 
security is to be secure where and when it matters.  Surely you would agree that 
the security of pens makes no difference when judging the security of a bank.

When visiting a site, the security that is applied to advertisements has nothing 
to do with the security of the site.  I could care less if the GIF showing an 
advertisement was supplied via HTTPS, or via HTTP.  The security of the site is 
unchanged.  Note that if the gif is supplied via HTTP, then it can be cached, 
and performance can be improved.  Alas, this bug tries to make such performance 
optimizations illegal.

Now if it was the case that the same level of security was used at a bank to 
protect your money, as to protect their pens, then there would be a problem.  
Similarly, if the web site chose to supply your personal and confidential data 
via HTTP, that would be a problem.  Note that even with this lock icon fetish, 
clicking on a link can take you to a page where a stupid site can leak your 
info via HTTP.  This change does not stop or reveal stupid sites.  It does not 
tell you when you are visiting a stupid site.  It can even tell you that you're 
visiting an unsafe  (mixed content??) site, when NOTHING is unsafe.

IMO, when a site goes to the trouble of supporting SSL, and uses it in critical 
places when form values should be concealed, then I am happy. I expect to see a 
locked icon when ever I'm about to submit data, when I'm reading confidential 
data. Beyond that, the site can do tons of stuff, and you're fooling yourself if 
you think that this bug is going to give you helpful info about the competency 
of the site.  It only  blocks competent optimization.

If the press wants to claim that otherwise, then that is their problem.  IMO, 
the worst the Press could do is complain about the lack of security on a site 
that used mixtures of SSL and non-SSL.  The press can (today) complain about 
security weaknesses in some sites (they send confirmations with CC numbers via 
email!?!?!).  I don't think we take an liability for any of this.

If I were designing the warnings in Nav 1.x-4.x, I would have established the 
performance that Netscape 6 currently demonstrates.  Regressing to copy mistakes  
of the past is not helpful IMO.

Oh well... that's how I see it.

Comment 9

[Javier Delgadillo]

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

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

If all the https web site designers had the same 
level of intelligence and integrity as Jim Roskind,
I'd agree that the browser shouldn't try to set/enforce
and minimal standard of behavior for marking pages with
a locked lock.  In that case, I'd argue the locked lock
could be achieved with a simple html tag <LOCK>.

But vast numbers of https site designers are clueless.
They do the minimum they have to do to get their pages
to work with IE and Communicator and make the lock 
appear locked.  If they can make the lock appear locked
by (say) putting up a tiny https page with a frameset
that loads a single http frame that contains all the 
sensitive data (with none of it being sent securely), 
you can bet your bottom dollar some of them will do it.  

The lock behavior in C4.x gave me confidence that the site
wasn't sending any of my data insecurely.  The new lock
behavior won't.

Comment 11

[Bob Lord]

I think there are two issues here.

(1) Images:
A large number of sites have asked for the ability to have an HTTPS web page 
reference HTTP images.  They want to do this for several reasons, performance 
being at the top of the list.  A good example of this is a bank that wants to 
show me my account information via a private channel.  The images that that come 
along almost never need to be encrypted.  Large, conservative, security 
conscious companies have asked us for this ability.  The threat seems incredibly 
low, mistakes seem almost always harmless, and the payoff seems pretty high.  

(2) Frame sets
This matter is a little more tricky. As mentioned above, it's possible for the 
top level HTTPS window to contain only a frameset that loads HTTP content.  
Here, it's possible for a site designer make a simple typo (i.e. "http://" vs 
"https://") that would lead to disaster (where in #1 it usually just leads to 
better performace).  

Just as likely is the case where the web team has not done a good job of sizing 
their server needs for SSL.  As they go production, they realize that there is 
some non-trivial amount of overhead for SSL, and look for *any* way to reduce 
load.  If they can "spoof" a fully encrypted site until the new servers show up, 
they will.  Of course, when the new servers show up, they'll forget to undo this 
hack.

I expect that web malls might be able to open a top-level frame that's "secure" 
and then show web pages from their customer stores.  Then they'd only have to 
buy one SSL server certificate.

Note also that I buy almost everything via the web these days.  That means I buy 
from sites that are pretty small and don't have the same level of understanding 
of security as a bank.  They don't know how to make the right tradeoffs with my 
credit card information, and if possible we should make sure the user is 
informed when they are being dumb with my personal information (to the extent 
that we can -- we can't audit their database security, etc.).

Question: is it possible/simple to allow HTTP images from an HTTPS page (and 
display a "locked" icon), but prevent HTTP frames inside an HTTPS frameset?

Comment 12

[lchiang]

per PDT: P3-P5 priority bugs changed from nsbeta3+ to nsbeta3-.  This bug is
already nominated for rtm.

Comment 13

[Andreas Franke (gone)]

To clarify: For me this is mainly a question of credibility and trust. The lock
icon is a central symbol in netscape's security framework. Users like me are
used to trust it. If you change the semantics of the lock icon without telling
the user, nobody will discover the difference immediately. But if you are then
informed by some FUD article that your trusted icon is not as trustworthy as you
thought it to be, netscape's credibility will suffer. If you are then informed
that this is by design, netscape's credibility will suffer even more, because
you get the impression that netscape is deliberately fooling you.

If this bug is not completely fixed the way it was originally intended (i.e. if
the conditions for showing the "locked" icon are any different then in 4.x),
then the user should be informed about that. I can see two possible ways to do
this: 
- a) choose a different icon, e.g. an exclamation mark or a smiley, instead of
the "locked" symbol, and tell the user about the changed semantics by way of
tooltips or something similar. Then users won't be surprised that the semantics
has changed. Probably this approach won't find many supporters because nobody
wants to abandon the well-established lock icon.
- b) add a dialog with an OK button that is shown the first time a "locked" icon
appears. It could say that the semantics of the lock icon has changed a little
and where one can find further information.

Obviously the current situation is much worse than the behaviour proposed by Bob
Lord, but even if Bob's proposal is realized, it's still true that the lock's
semantics has changed, and IMO the user should be informed about it.

Note that Bob Lord's proposal is equivalent to marking bug 28848 WONTFIX. This
doesn't imply any judgement about the quality of his arguments, be it positive
or negative. I just want to point out that his proposal different from an
earlier proposal from [e-mail] 2000-03-21 19:03 in that bug:
> nelson, in the case of a gif from a insecure site, our proposal is to (a) Warn 
> the user, (b) set the lock to the 'broken' state, and (c) display the image 
> unadulterated.  
I think that supports my position that even in case Bob's proposal is
implemented, the change is worthy of informing the user because s/he wouldn't
expect the new behaviour.

Comment 14

[John Unruh]

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

Comment 15

[Bob Lord]

I'm reluctantly marking this on [rtm-].  I do want this fixed in the next major
release, however.

Comment 16

[Andreas Franke (gone)]

A release note item may be a substitution (read: workaround) for my suggested
informative dialog. (Not perfect, but better than being informed about this bug
by an FUD article.)

Someone please cook up a good text or give a good reason for _not_ release
noting this (when removing the keywords). Preliminary text (due to lack of a
better one): 
  "Contrary to former versions of [...], Netscape 6.0 displays the lock icon
in   
   a `locked' state even on pages that have `mixed' content.
   See bug 47496 for details."

Mozilla 1.0 should get this right.

Comment 17

[John Unruh]

Release note: Contrary to former versions of Netscape Communicator, Netscape 6.0 
displays the lock icon in a `locked' state even on pages that have mixed or 
insecure content.

Comment 18

[Jim Roskind]

That text for a release note above is pretty misleading.  It reads as though the 
feature is broken.  It would almost appear that the icon is meaningless, which 
is not the case.

"The lock now indicates whether the basic page that was provided  arrived via 
SSL.  It does not assure that images and such sub-content are transmitted to the 
browser via SSL, and it is the responsibility of the serving site to adequately 
protect the user beyond this level."

Note that in previous verions (Navigator 4.x etc.) there are examples of 
sub-content provided when a locked icon is presented that are also not provided 
via SSL.  Examples included Java or JS generated items.

Comment 19

[John Unruh]

I made the change to the release notes page, bug 50809.

Comment 20

[Nelson Bolyard (seldom reads bugmail)]

I invite you all to visit https://junruh.mcom.com/oneframe.html

ALL of the visible content on this page is sent insecurely,
yet the lock appears locked.  

This is the wave of the future, as long as N6 permits it.
IMO, we're kidding ourselves if we think web sites are not
going to expolit this to the max.

Comment 21

[John G. Myers]

Fixed by the patch to bug 31982

Comment 22

[John Unruh]

Verified.

Comment 23

[Andreas Franke (gone)]

Thanks for fixing this. :) Can someone please summarize the current behaviour
wrt. jar's proposal, or post a pointer where to find this information? I have no
doubt that this is fixed, but I can't verify it because bug 31982 is
confidential and all testcases seem to be located behind a Netscape firewall...

Comment 24

[Andreas Franke (gone)]

Oops, I meant lord's proposal, of course.

Comment 25

[John G. Myers]

I believe lord's proposal is as dead as dirt.  If there are any insecure content 
on the page, images, frames, or whatever, then the lock icon shows broken.

(There is probably one exception.  If a securely downloaded MIME object is 
handled by a plug-in which uses an insecure back channel to obtain the content it 
displays, this will not be detected.)

Comment 26

[Andreas Franke (gone)]

Thanks for the info.

Comment 27

[John Unruh]

Mass changing Security:Crypto to PSM

Comment 28

[John Unruh]

Mass changing Security:Crypto to PSM