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

Status: VERIFIED WORKSFORME

(Core Graveyard :: Security: UI, defect)

Description

[David Hough]

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.

Comment 1

[David Hough]

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.

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Based on the comments changing some fields and assigning to PSM.

Comment 3

[Daniel Veditz [:dveditz]]

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]]

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

Comment 5

[Daniel Veditz [:dveditz]]

I take that back, bug 258048 is sort of the opposite.

Comment 6

[Daniel Veditz [:dveditz]]

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

Comment 7

[Daniel Veditz [:dveditz]]

Darin doesn't think this is a dupe, reopening

Comment 8

[chris hofmann]

try for 1.8b and the point releases

Comment 9

[Darin Fisher]

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

Comment 10

[Darin Fisher]

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

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!

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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]

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]]

Verified WFM.  Going from http to https we keep the secure url bar/lock icon
synced with the secure page load.