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

VERIFIED WORKSFORME

Status

Core Graveyard
Security: UI
VERIFIED WORKSFORME
14 years ago
11 months ago

People

(Reporter: David Hough, Assigned: Darin Fisher)

Tracking

(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)

Details

(Whiteboard: [sg:fix] need patch)

(Reporter)

Description

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 http://www.modisintl.com open. On selecting a
secure site from bookmarks,
https://ibank.barclays.co.uk/fp/1_2m/online/1,,logon,00.html, the top-right icon
was rotating, the status at the bottom announced that it was waiting on
ibank.barclays.co.uk and the padlock was on. The displayed screen was the
original modisintl.com page. On clicking on the padlock the Page Info window
claimed that the website www.modisintl.com had been verified. On viewing the
security certificate it was the one for ibank.barclays.co.uk. 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
(http://soccernet.espn.go.com and https://my.if.com). 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
site.

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.
(Reporter)

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
site.
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 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
I take that back, bug 258048 is sort of the opposite.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---

*** This bug has been marked as a duplicate of 257308 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago13 years ago
Resolution: --- → DUPLICATE
Group: security
Darin doesn't think this is a dupe, reopening
Blocks: 130949
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Assignee: kaie → darin
Group: security
Status: UNCONFIRMED → NEW
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+

Updated

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

Comment 9

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

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.
(Assignee)

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:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-aviary1.0.1/

or with a recent mozilla 1.7 branch build:
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-1.7/

Thanks!
Status: NEW → RESOLVED
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
(Assignee)

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.
Status: RESOLVED → VERIFIED
Group: security

Updated

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.