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

VERIFIED FIXED

Status

--
major
VERIFIED FIXED
13 years ago
2 years ago

People

(Reporter: stephan.email, Assigned: kaie)

Tracking

(Blocks: 1 bug, {verified1.8.0.12, verified1.8.1.4})

1.7 Branch
verified1.8.0.12, verified1.8.1.4
Dependency tree / graph
Bug Flags:
blocking1.8.1.4 +
wanted1.8.1.x +
blocking1.8.0.12 +
wanted1.8.0.x +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:low] spoof (steps to reproduce in comment 3), URL)

Attachments

(2 attachments)

(Reporter)

Description

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

Comment 1

12 years ago
Created attachment 245709 [details]
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.

Updated

12 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

12 years ago
OS: Windows XP → All
Hardware: PC → All

Comment 2

12 years ago
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: 130949
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

Comment 3

12 years ago
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)

Comment 4

12 years ago
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)

Updated

12 years ago
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
(Assignee)

Comment 5

12 years ago
Created attachment 255673 [details] [diff] [review]
Patch v1

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

Comment 6

12 years ago
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+
(Assignee)

Comment 7

12 years ago
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+
(Assignee)

Comment 8

12 years ago
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
Last Resolved: 12 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)

Updated

12 years ago
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?
(Assignee)

Comment 11

12 years ago
fixed1.8.1.4, fixed1.8.0.12
Keywords: fixed1.8.0.12, fixed1.8.1.4
verified with
2.0.0.4 rc3 Windows and Linux
1.5.0.12 rc2 Mac
trunk Windows
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.0.12, fixed1.8.1.4 → verified1.8.0.12, verified1.8.1.4
Depends on: 383369
This has caused bug 383369.
(Assignee)

Comment 14

11 years ago
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.