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)
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 220.127.116.11 Reproducible: Always
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.
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.
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).
Assignee: nobody → kengert
Component: Security → Security: UI
Product: Firefox → Core
QA Contact: firefox
Version: unspecified → 1.8 Branch
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?
15 years ago
Comment on attachment 255673 [details] [diff] [review] Patch v1 I propose to land it on both stable branches.
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)
Comment on attachment 255673 [details] [diff] [review] Patch v1 Approved for the 1.8 and 1.8.0 branches, a=dveditz
verified with 18.104.22.168 rc3 Windows and Linux 22.214.171.124 rc2 Mac trunk Windows
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/
You need to log in before you can comment on or make changes to this bug.