Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 238566 - Checking SSL certificate verifies wrong site when new page is slow to load
: Checking SSL certificate verifies wrong site when new page is slow to load
[sg:fix] need patch
: fixed-aviary1.0.1, fixed1.7.6
Product: Core Graveyard
Classification: Graveyard
Component: Security: UI (show other bugs)
: Other Branch
: All All
: -- normal (vote)
: ---
Assigned To: Darin Fisher
: bmartin
Depends on:
Blocks: lockicon sg-ff101
  Show dependency treegraph
Reported: 2004-03-24 15:29 PST by David Hough
Modified: 2016-09-27 13:03 PDT (History)
9 users (show)
dveditz: blocking1.7.6+
dveditz: blocking‑aviary1.0.1+
asa: blocking1.8b+
asa: blocking‑aviary1.5+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Description David Hough 2004-03-24 15:29:43 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8

In a browser window I had the site open. On selecting a
secure site from bookmarks,,,logon,00.html, the top-right icon
was rotating, the status at the bottom announced that it was waiting on and the padlock was on. The displayed screen was the
original page. On clicking on the padlock the Page Info window
claimed that the website had been verified. On viewing the
security certificate it was the one for Eventually the
barclays site responded and the browser window updated. My settings are such
that the browser does not explicitly warn me when entering a secure site.

There appears to be a problem where the new site certificate has been verified
but not all information has been updated because some threshold in loading the
new page has not been passed.

Reproducible: Sometimes
Steps to Reproduce:
1. Display an insecure (http) web page
2. Select a secure site (https) from bookmarks
3. As quickly as possible after (2), click on the padlock, lower left corner

Actual Results:  
Depending on the speed of response of the secure site it is possible to get a
claimed verification of the insecure page with the secure page certificate.
Double-clicking the padlock can in some cases bring up two Page Info windows,
one for each site. Problem has been reproduced with a different pair of sites
( and In step (2) it is likely
that a typed URL will work as well as a bookmarked one.

Expected Results:  
The padlock should not appear until the new page is more advanced in loading or
at the very least should not display information containing the URL of the wrong

I've ticked the security box in case there's a trick here for an insecure site
to access a secure site using javascript in some way that allows it to appear to
be verified as that site.
Comment 1 David Hough 2004-03-25 14:33:20 PST
I've since managed to duplicate this using both Firefox 0.8 and Mozilla 1.4 on a
Mac running OS X 10.2.8 (not mine, hence not trying the latest Mozilla). It's
not easy to do when things are running at normal speed, possibly a slow dial-up
might make it easier to reproduce.

Current method is to clear the cache, only one active window. Browse to an
insecure page and type in the URL of the secure page but don't hit return.
Position the mouse cursor over the padlock, hit return and click on the padlock
the instant you see it lock.

The media tab on the page info shows one image from the secure site, the title
suggests it's the background graphic, and all other images are from the insecure
Comment 2 Heikki Toivonen (remove -bugzilla when emailing directly) 2004-03-27 12:14:33 PST
Based on the comments changing some fields and assigning to PSM.
Comment 3 Daniel Veditz [:dveditz] 2004-06-07 09:41:45 PDT
This sounds like it could be part of the the same underlying flaw as bug 240053
which was fixed around 4/15. Does this still happen?
Comment 4 Daniel Veditz [:dveditz] 2004-09-07 16:11:57 PDT

*** This bug has been marked as a duplicate of 258048 ***
Comment 5 Daniel Veditz [:dveditz] 2004-09-07 16:23:57 PDT
I take that back, bug 258048 is sort of the opposite.
Comment 6 Daniel Veditz [:dveditz] 2004-09-07 16:24:24 PDT

*** This bug has been marked as a duplicate of 257308 ***
Comment 7 Daniel Veditz [:dveditz] 2004-09-08 17:53:14 PDT
Darin doesn't think this is a dupe, reopening
Comment 8 chris hofmann 2005-02-01 13:29:16 PST
try for 1.8b and the point releases
Comment 9 Darin Fisher 2005-02-17 13:18:00 PST
I suspect that this may be a duplicate of bug 258048.
Comment 10 Darin Fisher 2005-02-18 13:33:30 PST
(In reply to comment #9)
> I suspect that this may be a duplicate of bug 258048.

Ok, I agree with dveditz.  That bug seems like the opposite.  It is likely that
this is a duplicate of bug 240053 instead.  I haven't been able to reproduce
this bug yet using Firefox 1.0.  I'm trying an older version to see if I can
repro it there, just to verify my approach.
Comment 11 Darin Fisher 2005-02-18 13:56:49 PST
I'm unable to reproduce this.  I'm not sure that it is a duplicate of either of
those bugs, but I suspect that it may be a duplicate of one of the recently
fixed lock icon bugs.  The patch in bug 258048 gives me confidence that the URL
bar will remain in sync with the lock icon state, and other patches give me
confidence that we will not update the lock icon state until we are actually
feeding data into the browser window, so I think we can mark this bug WORKSFORME.

Please reopen this bug if you can reproduce the problem with a recent firefox
1.0.1 branch build:

or with a recent mozilla 1.7 branch build:

Comment 12 David Baron :dbaron: ⌚️UTC-7 2005-02-18 16:18:17 PST
I'm going to mark this as fixed1.7.6 and fixed-aviary1.0.1, even though it's
really worksforme.  Since we have fixed1.7.6 and verified1.7.6, it seems like we
really should be calling the first keyword resolved1.7.6.  In any case, that
will make it show up on the appropriate lists.

Darin, you were testing on the aviary 1.0 branch, right?  And the relevant code
is in sync for 1.7.6 (and for the suite), as well, right?  If not, please remove
these keywords...
Comment 13 Darin Fisher 2005-02-18 16:33:03 PST
dbaron: I tested this bug with Firefox 1.0 primarily.  The other bugs I
mentioned were tested across the board.
Comment 14 Jay Patel [:jay] 2005-02-23 15:29:54 PST
Verified WFM.  Going from http to https we keep the secure url bar/lock icon
synced with the secure page load.

Note You need to log in before you can comment on or make changes to this bug.