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 184.108.40.206 Reproducible: Always
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.
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
Version: 1.8 Branch → 1.7 Branch
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.
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?
12 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
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)
Comment on attachment 255673 [details] [diff] [review] Patch v1 Approved for the 1.8 and 1.8.0 branches, a=dveditz
Keywords: fixed220.127.116.11, fixed18.104.22.168
verified with 22.214.171.124 rc3 Windows and Linux 126.96.36.199 rc2 Mac trunk Windows
Status: RESOLVED → VERIFIED
Keywords: fixed188.8.131.52, fixed184.108.40.206 → verified220.127.116.11, verified18.104.22.168
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.