278003 - lock icon and certificates spoofable with any insecure protocol

Status: RESOLVED DUPLICATE of bug 258048

(Core :: Security, defect)

Description

[Darin Fisher]

lock icon and certificates spoofable with any insecure protocol

this report is an extension of bug 277564.  the problem reported there can be
reproduced using "window.opener.location=" and any URL type that results in a
document that never finishes loading.  the real bug is that we don't update the
lock icon until we get OnStateChange(STATE_STOP) for the toplevel document.

I will post a testcase, derived from the one in bug 277564, shortly.

Comment 1

[Darin Fisher]

OK, here's my testcase:

  http://friedfish.homeip.net/test/bugs/278003/test.html

It is derived from this one:

  http://beta51.minutedesign.com/test2-3.html

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

bz's comment in bug 277564 comment 19 makes sense to me. But what we should do
IMHO is to show an unsecure lock as soon as we start getting data, and on
STATE_STOP 'upgrade' it to a secure or whatever lock.

Comment 3

[Daniel Veditz [:dveditz]]

(In reply to comment #2)
> But what we should do IMHO is to show an unsecure lock as soon as we start
> getting data, and on STATE_STOP 'upgrade' it to a secure or whatever lock.

I thought of that at first, but won't we then end up triggering the
entering/leaving SSL dialogs all over the place? I know most people turn them
off anyway, but we' need to be careful not to make it totally useless.

Comment 4

[Darin Fisher]

yeah, i agree... we should not show the secure lock icon until we know that
everything is secure.  perhaps we could show the mixed icon while the page is
loading.

Comment 5

[Darin Fisher]

maybe we need another lock state... a lock with a question mark on it or
something :-)

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

yeah, rather a questionmark (or no icon at all?) then the mixed one since the
mixed looks more secure then the page might actually be.

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

hm... what is the problem with showing the secure icon in the first
STATE_TRANSFERRING? that icon will show the right state for the currently
displayed content - everything secure. as soon as something insecure arrives,
the icon will be updated accordingly.

why's this a problem?

Comment 8

[Darin Fisher]

biesi: yeah, that may be fine provided we display the security state change
dialogs at the right time :-/

Comment 9

[Daniel Veditz [:dveditz]]

We have had several similar timing bugs with the lock icon. We need to attack
them as a group and then regression test against all the dependencies of bug
130949 (alias: lockicon).

Comment 10

[chris hofmann]

try for 1.8b and tbe point releases

Comment 11

[Darin Fisher]

Marking this bug as a duplicate of the earlier report.  They are essentially the
same thing.

*** This bug has been marked as a duplicate of 258048 ***