Checking SSL certificate verifies wrong site when new page is slow to load



Core Graveyard
Security: UI
14 years ago
11 months ago


(Reporter: David Hough, Assigned: Darin Fisher)


(Blocks: 1 bug, {fixed-aviary1.0.1, fixed1.7.6})

Other Branch
fixed-aviary1.0.1, fixed1.7.6
Dependency tree / graph
Bug Flags:
blocking1.7.6 +
blocking-aviary1.0.1 +
blocking1.8b +
blocking-aviary1.5 +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:fix] need patch)



14 years ago
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

14 years ago
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
Based on the comments changing some fields and assigning to PSM.
Assignee: firefox → kaie
Component: General → Client Library
OS: Linux → All
Product: Firefox → PSM
QA Contact: bmartin
Hardware: PC → All
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?
Whiteboard: [sg:needinfo]

*** This bug has been marked as a duplicate of 258048 ***
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
I take that back, bug 258048 is sort of the opposite.
Resolution: DUPLICATE → ---

*** This bug has been marked as a duplicate of 257308 ***
Last Resolved: 13 years ago13 years ago
Resolution: --- → DUPLICATE
Group: security
Darin doesn't think this is a dupe, reopening
Blocks: 130949
Resolution: DUPLICATE → ---
Assignee: kaie → darin
Group: security
Ever confirmed: true
Whiteboard: [sg:needinfo] → [sg:fix]
Blocks: 278184

Comment 8

13 years ago
try for 1.8b and the point releases
Flags: blocking1.8b?
Flags: blocking1.7.6?
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.0.1?
Flags: blocking1.7.6?
Flags: blocking1.7.6+
Flags: blocking-aviary1.0.1?
Flags: blocking-aviary1.0.1+


13 years ago
Flags: blocking1.8b?
Flags: blocking1.8b+
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1+
Whiteboard: [sg:fix] → [sg:fix] need patch

Comment 9

13 years ago
I suspect that this may be a duplicate of bug 258048.

Comment 10

13 years ago
(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

13 years ago
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:

Last Resolved: 13 years ago13 years ago
Resolution: --- → WORKSFORME
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...
Keywords: fixed-aviary1.0.1, fixed1.7.6

Comment 13

13 years ago
dbaron: I tested this bug with Firefox 1.0 primarily.  The other bugs I
mentioned were tested across the board.

Comment 14

13 years ago
Verified WFM.  Going from http to https we keep the secure url bar/lock icon
synced with the secure page load.
Group: security


13 years ago
Component: Security: UI → Security: UI
Product: PSM → Core
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.