STEPS TO REPRODUCE: 0. Connect to a wifi hotspot that rewrites SSL certs (as most public ones do, until you've authenticated / clicked through the EULA). I think any Starbucks wifi network should do (not sure though) 1. Start up Firefox with a fresh profile 2. Immediately enter Private Browsing mode (Ctrl+Shift+P) 3. Wait ~15 seconds. ACTUAL RESULTS: A dialog will appear, warning that "snippets.mozilla.com:443 uses an invalid security certificate" Looks like this is for the fresh profile trying to download "snippets" for about:home, and being thwarted by the rewritten security certs on the hotspot. EXPECTED RESULTS: The snippet-request should just fail silently. No need to spam the user about this (or begin the process of training them to click through cert dialogs). I *think* we get only get ACTUAL RESULTS in Private Browsing mode -- otherwise (in normal mode), we just fail silently (what I'd expect). (I'll try to verify this in a bit, when my "free 15 minutes" at this airport wifi hotspot run out.)

(In reply to comment #0) > 2. Immediately enter Private Browsing mode (Ctrl+Shift+P) Aha! Alternate (simpler) version of step 2: 2. Quickly close the about:home tab (within a few seconds), leaving only the "Thanks for using a pre-release version of Firefox" tab. (which presumably won't actually load, since you probably don't have access to the wider internet yet) If about:home is visible, it seems the snippet-lookup times out silently, and we fall back to using some default snippet. But if I close the about:home tab (or equivalently, open Private Browsing) before we fall back, then we pop up the scary cert warning.

Un-CC'ing Ehsan (I'd originally cc'd him due to my mistaken assumption that this bug depended on Private Browsing), and CC'ing about:home-guru Marco.

This is with the latest m-c trunk nightly, btw: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) Gecko/20110314 Firefox/4.0b13pre

The about:home page is just a normal content page (it has no special privileges), so it can't directly inhibit the bad cert warning dialog for its XHR request the way that chrome can (using e.g. mozBackgroundRequest). I think fixing this would be kind of tricky.

I don't understand -- how do we inhibit the warning when about:home is open? (as we seem to do currently) One thought -- since I don't seem to hit this problem when I leave "about:home" open, perhaps we could hack around it by having a hidden "about:home" page open in the background? Might not be too much overhead, since about:home is lightweight, IIUC. :) A "real" fix would definitely be nicer, though.

Daniel, do you get anything in your error console/web console if you leave about:home open?

Looking at the code, aboutHome.js is just using a regular XHR like any other webpage would: <http://mxr.mozilla.org/mozilla-central/source/browser/base/content/aboutHome.js#215> This probably means that our networking layer is not smart enough to discard (or at least make silent) an XHR request for which the content page has gone away. This seems like a very bad bug to me. CCing bz, who is my netwerk god. Also, I bet that the reason that this doesn't happen if about:home is left open is this error handler: <http://mxr.mozilla.org/mozilla-central/source/browser/base/content/aboutHome.js#217>

Btw, I think we want to revise how about:home works, move to a snippets iframe with type=content, similar to about:addons, so that we can suppress ssl notifications, add proper autocomplete and move code out of upgrade path as well. But not something that can be fixed soon (due to security implications, this will require a deeper security review than the current version)

That error handler would run after the dialog is posed, I would think. More likely is that we can't get back to a docshell from the channel once the tab is closed and that docshell does something magic here... Closing the tab _should_ cancel the necko requests, though. Do you see nsHttpChannel::Cancel being called when the tab is closed?

Oh, I didn't notice the part about having to close about:home for this to happen.

(In reply to comment #6 & comment #9) I'm no longer at the Auckland airport where I first experienced this bug, but I can see what shows up in the console & if nsHttpChannel::Cancel is called in the next day or two, if another nearby wireless hotspot reproduces this.

(Presumably this should be easy to reproduce in the office using the Mozilla-Public WIFI SID?)

I tried using the "Mozilla Guest" network, but couldn't reproduce (using the same machine as when I filed the bug). It miiight have to do with being bandwidth-constrained, too (the Auckland airport wifi network was pretty slow, even just to visit the splash welcome page). But I did try artificially rate-limiting my Mozilla Guest connection to a trickle, and it still didn't reproduce the bug here... So I'm not sure what more I need to do to trigger it.

Do we really need a wifi connection to reproduce this? We could just use the "close about:home very quickly" method, right?

I think we do need a wifi connection -- IIUC, the warning is that we've gotten a response from snippets.mozilla.com, but it uses **an invalid certificate** (for the hotspot's splash page domain).

(In reply to comment #15) > I think we do need a wifi connection -- IIUC, the warning is that we've gotten > a response from snippets.mozilla.com, but it uses **an invalid certificate** > (for the hotspot's splash page domain). What if you add an entry to /etc/hosts to point snippets.mozilla.com to another webserver which supports SSL connections, such as ebay.com?

Good idea -- I just tried that, but as with my earlier trials on "Mozilla Guest" network, I still can't reproduce. :-/ (I verified that I'd triggered cert errors on direct visits to https://snippets.mozilla.com, to be sure the hosts tweak was effective.) So I've still only seen this at the Auckland airport (where it was quite easy to reproduce). I'll ask someone on the Mozilla Auckland team to give this a try when they next fly out of there, and maybe that will turn up some more data...

(removing bit about "rewrites certs" from title, since based on the screenshot, the warning is just for the _wrong_ cert was being served. It's not that the cert was rewritten with an untrusted root, as I'd initially assumed)

Hmm -- FWIW, if I load https://apc.aptilo.com (the domain from the attached screenshot), I get a cert-error screen, with the following issues under "Technical Details": > apc.aptilo.com uses an invalid security certificate. > The certificate is not trusted because the issuer certificate is not trusted. > The certificate is only valid for mercury.aptilonetworks.com > The certificate expired on 12/07/2009 03:15 AM. The current time is 03/17/2011 05:19 PM. > (Error code: sec_error_untrusted_issuer) So this might have to do with using an expired *and* mismatched cert... However, I still can't reproduce in Mountain View, even with that knowledge. (I tried the /etc/hosts trick from Comment 16-17, just remapping snippets.mozilla.com to apc.aptilo.com & artificially slowing my connection.)