Closed Bug 335801 Opened 16 years ago Closed 15 years ago

Loading a cert URL can make an http page look like https (gold address bar, lock icon)

Categories

(Core Graveyard :: Security: UI, defect)

1.7 Branch
defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: stephan.email, Assigned: KaiE)

References

(Blocks 1 open bug, )

Details

(Keywords: verified1.8.0.12, verified1.8.1.4, Whiteboard: [sg:low] spoof (steps to reproduce in comment 3))

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060428 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060428 Minefield/3.0a1

If you visit a site that contains a https:-link to a certificate already in Mozillas database and you click this link a small window pops up ("The certificate already exists") while the site in the browser window stays the same.
But the security information (rulbar coloring, lock icon, page-info dialog data) get updated to the information of the certificates https-link. So it looks like original page was authenticated and you would be on a secure connection.

This can also be automated by using meta-refresh.

See the URL for an example, just click on one of the links to one of the certificates on this page.

This also happens in Firefox 1.5.0.2

Reproducible: Always
Attached image Screenshot
Problem reproducible in "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061115 Minefield/3.0a1".  Screenshot attached below.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Who maintains the code that determines when the lock icon appears?  The last few fixes came from Darin, but I don't know if he's still contributing much code to Mozilla.

Why does do the security indicators (lock icon and address bar color) have such a strong tendency to get out of sync with the rest of the browser, including the URL displayed in the address bar?  From a quick skim of bug 130949's dependencies, all of these bugs seem to be examples of that tendency: 312363, 317380, 307027, 300613, 283733, 271194, 268483, 258048.
Blocks: lockicon
Flags: blocking-firefox3?
OS: All → Windows XP
Hardware: All → PC
Summary: page looks secure/verified but isn't (colored urlbar, lock icon) → Loading a cert URL can make an http page look like https (gold address bar, lock icon)
Whiteboard: [sg:low] spoof
Confirmed on Mac trunk.

Steps to reproduce:
1. Load http://www.geotrust.com/resources/root_certificates/index.asp
2. Click the first "Download" link under "Root 1 - Equifax Secure Certificate Authority".
3. Dismiss the dialog (by pressing Esc or clicking OK).

Result: https-style UI even though the URL is still the same http URL.
OS: Windows XP → All
Hardware: PC → All
Whiteboard: [sg:low] spoof → [sg:low] spoof (steps to reproduce in comment 3)
Philor put together a simpler demo: http://dev.philringnalda.com/ssl/.

reed says he can reproduce with 2.0.0.x (on Linux).
Flags: blocking1.8.1.3?
Flags: blocking1.8.0.11?
Assignee: nobody → kengert
Component: Security → Security: UI
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: firefox
Version: unspecified → 1.8 Branch
Flags: blocking1.9?
Version: 1.8 Branch → 1.7 Branch
Attached patch Patch v1Splinter Review
We need to test this fix, I'm not sure if we indeed must ignore all events with flag nsIChannel::LOAD_RETARGETED_DOCUMENT_URI
But from reading the sources and comments, this is my understanding, because the load has been redirected to a different consumer or display context.
Comment on attachment 255673 [details] [diff] [review]
Patch v1

While I would like to continue to test this for 1-2 additional days in my daily browsing, the patch seems correct so far.

Christian, do you agree it is the right fix, to ignore any web progress events with LOAD_RETARGETED_DOCUMENT_URI set?
Attachment #255673 - Flags: superreview?(cbiesinger)
Attachment #255673 - Flags: review?(cbiesinger)
Attachment #255673 - Flags: superreview?(cbiesinger)
Attachment #255673 - Flags: superreview+
Attachment #255673 - Flags: review?(cbiesinger)
Attachment #255673 - Flags: review+
Comment on attachment 255673 [details] [diff] [review]
Patch v1

I propose to land it on both stable branches.
Attachment #255673 - Flags: approval1.8.1.3?
Attachment #255673 - Flags: approval1.8.0.11?
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.8.1.3?
Flags: blocking1.8.1.3+
Flags: blocking1.8.0.11?
Flags: blocking1.8.0.11+
I had checked this in to trunk one week ago.
Resolving bug as fixed.

If you'd be able to test a nightly trunk build and confirm it works for you, this would be appreciated.

I have been continously running a 1.8 branch build that contains this fix for over a week, and I have been using logging, and only ever saw this flag being set when I initiated a download, or when content was opened in an external viewed, this gives me additional confidence this fix is correct.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment on attachment 255673 [details] [diff] [review]
Patch v1

Since this crosses modules and is intimately security-related, would like a second review before approving for branches (looks good though).
Attachment #255673 - Flags: review?(darin.moz)
Attachment #255673 - Flags: review?(darin.moz) → review+
Comment on attachment 255673 [details] [diff] [review]
Patch v1

Approved for the 1.8 and 1.8.0 branches, a=dveditz
Attachment #255673 - Flags: approval1.8.1.4?
Attachment #255673 - Flags: approval1.8.1.4+
Attachment #255673 - Flags: approval1.8.0.12?
Attachment #255673 - Flags: approval1.8.0.12+
Flags: blocking1.9?
fixed1.8.1.4, fixed1.8.0.12
verified with
2.0.0.4 rc3 Windows and Linux
1.5.0.12 rc2 Mac
trunk Windows
Status: RESOLVED → VERIFIED
Depends on: 383369
This has caused bug 383369.
The original STR no longer work for me.
Philor's URL no longer works for me.
This is because the CA is now using a wrong content type for delivering the CA cert.

Bug 383369 will require us to work on a new patch for this bug, so I need a new test site for this bug. I created a new one here:

http://kuix.de/misc/test335801/
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.