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

Status: VERIFIED FIXED

(Core Graveyard :: Security: UI, defect)

Description

[Stephan Hohe]

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

[Jackie Liu]

Attachment: 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.

Comment 2

[Jesse Ruderman]

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.

Comment 3

[Jesse Ruderman]

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.

Comment 4

[Jesse Ruderman]

Philor put together a simpler demo: http://dev.philringnalda.com/ssl/.

reed says he can reproduce with 2.0.0.x (on Linux).

Comment 5

[Kai Engert (:KaiE:)]

Attachment: 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.

Comment 6

[Kai Engert (:KaiE:)]

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?

Comment 7

[Kai Engert (:KaiE:)]

Comment on attachment 255673 [details] [diff] [review]
Patch v1

I propose to land it on both stable branches.

Comment 8

[Kai Engert (:KaiE:)]

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.

Comment 9

[Daniel Veditz [:dveditz]]

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

Comment 10

[Daniel Veditz [:dveditz]]

Comment on attachment 255673 [details] [diff] [review]
Patch v1

Approved for the 1.8 and 1.8.0 branches, a=dveditz

Comment 11

[Kai Engert (:KaiE:)]

fixed1.8.1.4, fixed1.8.0.12

Comment 12

[Tracy Walker [:tracy]]

verified with
2.0.0.4 rc3 Windows and Linux
1.5.0.12 rc2 Mac
trunk Windows

Comment 13

[Steve England [:stevee]]

This has caused bug 383369.

Comment 14

[Kai Engert (:KaiE:)]

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/