366191 - Something tries to MITM Firefox's automatic connection to addons.mozilla.org, resulting in an annoying expired-certificate dialog

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[John O. Kopf]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

I use a broadband wireless connection, and thus often access "localhost".  I use Firefox 2.0.0.1; I regularly leave it active, even when I'm not connected.  EVERY morning when I come to the computer I see the bitch widow (apparently raised during the night when Firefox was trying to contact Mozilla):

"localhost.localdomain" is a site that uses a security certificate to encrypt data during transmission, but its certificate expired on 6/3/2003 1:07 PM.You should check to make sure that your computer's time (currently set to Friday, January 05, 2007 07:42:58 PM) is correct.

Reproducible: Always

Steps to Reproduce:
1.leave Firefox up overnight while disconnecting from broadband network.
2.let Firefox check for updates.
3.
Actual Results:  
Even though I say it is OK, the next morning it is there again.  I have even gone so far as to manually delete EVERY certificate that Firefox claims I have, without effect.

Expected Results:  
I think that Firefox should either accept my approval once and for all, and/or identify where I can get a current certificate.

This is not specific to this version - I've been seeing this since I went broadband!

Comment 1

[Jesse Ruderman]

Do you know why Firefox is trying to access "localhost.localdomain" and why there is an https server at that address with an expired certificate?

Comment 2

[Jo Hermans]

>I use a broadband wireless connection, and thus often access "localhost".

I don't get that. localhost or 127.0.0.1 is your own computer. It has nothing to do with your broadband. You can even access it without a broadband connection.

Maybe you are using a firewall or a local proxy server (ad-filtering software ?). In which case I'm wondering why it would need a certificate at all.

Comment 3

[John O. Kopf]

The initial window message is:
"localhost.localdomain" is a site that uses a security certificate to encrypt data during transmission, but its certificate expired on 6/3/2003 1:07 PM.You should check to make sure that your computer's time (currently set to Monday, January 08, 2007 08:13:02 PM) is correct.

...When I click on OK, a second window appears that says:
You have attempted to establish a connection with "addons.mozilla.org".  However, the security certificate presented belongs to "localhost.localdomain".  It is possible, though unlikely, that someone may be trying to intercept your communication with this web site.If you suspect the certificate shown does not belong to "addons.mozilla.org", please cancel the connection and notify the site administrator.

...Examining Firefox's options, I find no reference to "localhost" or "127/0/0/1", so I don't know how/why Firefox is attempting to access it.

Comment 4

[Jesse Ruderman]

I guess something is trying to intercept the connection Firefox uses to check for extension updates.  I don't know why it would do that.  Firefox should not let you "connect anyway" in this situation, much less "always connect anyway".  It's not obvious to me whether it should fail silently, log an error, or alert you immediately.  Why didn't this get fixed as part of bug 304286?

This will probably go away when bug 327181 is fixed, but it would be nice to have a fix sooner for things like Firefox update and extension update.

Comment 5

[Robert Strong (they/them - no direct email)]

What happens when you manually check for updates in the add-ons mgr?

Comment 6

[Daniel Veditz [:dveditz]]

(In reply to comment #2)
> I don't get that. localhost or 127.0.0.1 is your own computer. It has nothing
> to do with your broadband. You can even access it without a broadband
> connection.

There seems to be a popular junk/test self-signed cert going around that uses "localhost.localdomain" that people are installing on their webservers. Maybe it was distributed with some example of how to set up an SSL server or something and people who use it can't figure out how to create their own self-signed cert. Self-signed certs are already pretty worthless, but if you use this localhost.localdomain one instead of one "We don't know this CA" error you also get an "expired" error and a hostname mismatch error.

And then if you install the same server on multiple hosts FF2 started completely blocking access to any past the first because they use the same serial number.

There may be times when a self-signed cert is sufficient, but jeez, generate your own self-signed cert. The tools are free.

Anyway, we should have thought about this when fixing bug 304286, but app update and extension update are two separate mechanisms and need to be fixed in separate places.

Comment 7

[John O. Kopf]

A quick fix might simply be to include an UNEXPIRED certificate to "localhost.localdomain" into subsequent releases.

Comment 8

[Jay Patel [:jay]]

Assigning it to dvedtiz, who said he can get a patch together quickly for 1.8.1.2/1.8.0.10.

Comment 9

[Jay Patel [:jay]]

dveditz:  Any progress here?  Still think we can get this for 1.8.1.2?  It not, let's clear the blocking flags and get this next time.

Comment 10

[Daniel Veditz [:dveditz]]

Attachment: Catch bad cert errors and fail the update checks

Comment 11

[Daniel Veditz [:dveditz]]

I don't know that this code needs sr=, I added Darin because he fixed similar bugs in app update. If rstrong is out today maybe sspitzer or bsmedberg could review this area instead?

Comment 12

[Daniel Veditz [:dveditz]]

Attachment: turn off progress meter in error case

Forgot to turn off the progress meter in the error case. Not necessary in the similar blocklist update because there's no item progress UI to turn off.

Comment 13

[Darin Fisher]

It seems a shame not to share this code between the update service and the extension manager.

Comment 14

[(not reading, please use [e-mail] instead)]

dan, sorry for the delay.

the patch seems reasonable to me.  I think you still want r=rstong.

> It seems a shame not to share this code between the update service and the
> extension manager.

darin, good point. could we put the cert handler in a separate .js file (in toolkit?) and use the xul preprocessor to include in nsUpdateService.js.in and nsExtensionManager.js.in?

for completeness:

about his patch, dan writes:  "It's nearly identical to the stuff for bug 304xxx in app update, plus 340198. slight difference in error handling, that's it."

about "Forgot to turn off the progress meter in the error case", dan writes that "it's a bug in nsExtensionManager.js, but not in app update.  it's not in the bad cert handling code, it's in handling errors once one is discovered. The app update doesn't really have a UI tie. it just checks in the background. or, if you check manually it just pops a result dialog. no progress meter to stop"

Comment 15

[(not reading, please use [e-mail] instead)]

Comment on attachment 252970 [details] [diff] [review]
turn off progress meter in error case

clearing review, to hear back about the #include suggestion.

Comment 16

[Daniel Veditz [:dveditz]]

Attachment: same thing moved into a shared fragment

Comment 17

[Daniel Veditz [:dveditz]]

Comment on attachment 253115 [details] [diff] [review]
same thing moved into a shared fragment

A review from rstrong would be good too.

Comment 18

[Robert Strong (they/them - no direct email)]

Comment on attachment 253115 [details] [diff] [review]
same thing moved into a shared fragment

Looks good... the only change I'd like is for the shared code to live in a shared location. Could this live under toolkit/mozapps/shared/src instead?

Comment 19

[Darin Fisher]

Comment on attachment 253115 [details] [diff] [review]
same thing moved into a shared fragment

sr=darin w/ s/update/shared/ per rstrong

Comment 20

[Daniel Veditz [:dveditz]]

Attachment: same thing, new folder

Comment 21

[Robert Strong (they/them - no direct email)]

Comment on attachment 253136 [details] [diff] [review]
same thing, new folder

>Index: toolkit/mozapps/update/src/nsUpdateService.js.in
...
>@@ -122,12 +122,14 @@ var gApp        = null;
> var gPref       = null;
> var gABI        = null;
> var gOSVersion  = null;
> var gConsole    = null;
> var gLogEnabled = { };
> 
>+#include ../../shared/src/badCertHandler.js
>+
Please add a comment similar to the one in th EM of
// shared code for suppressing bad cert dialogs

with that r=me

Comment 22

[Daniel Veditz [:dveditz]]

Fix checked into trunk

Comment 23

[Jay Patel [:jay]]

Comment on attachment 253136 [details] [diff] [review]
same thing, new folder

Approved for both branches, a=jay

Comment 24

[Daniel Veditz [:dveditz]]

checked into 1.8/1.8.0 branches