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

RESOLVED FIXED

Status

()

Toolkit
Add-ons Manager
RESOLVED FIXED
11 years ago
9 years ago

People

(Reporter: John O. Kopf, Assigned: dveditz)

Tracking

({fixed1.8.0.10, fixed1.8.1.2})

unspecified
x86
Windows 2000
fixed1.8.0.10, fixed1.8.1.2
Points:
---
Bug Flags:
blocking1.8.1.2 +
wanted1.8.1.x +
blocking1.8.0.10 +
wanted1.8.0.x +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

11 years ago
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

11 years ago
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

11 years ago
>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.
(Reporter)

Comment 3

11 years ago
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

11 years ago
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.
Component: General → Extension/Theme Manager
QA Contact: general → extension.manager
Summary: I can't get Firefox to stop complaining about an expired certificate. → Something tries to MITM Firefox's automatic connection to addons.mozilla.org, resulting in an annoying expired-certificate dialog

Updated

11 years ago
Flags: blocking1.8.1.2?
What happens when you manually check for updates in the add-ons mgr?
(Assignee)

Comment 6

11 years ago
(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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8.0.10?
(Reporter)

Comment 7

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

Comment 8

11 years ago
Assigning it to dvedtiz, who said he can get a patch together quickly for 1.8.1.2/1.8.0.10.
Assignee: nobody → dveditz
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.8.1.2?
Flags: blocking1.8.1.2+
Flags: blocking1.8.0.10?
Flags: blocking1.8.0.10+

Comment 9

11 years ago
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.
(Assignee)

Comment 10

11 years ago
Created attachment 252941 [details] [diff] [review]
Catch bad cert errors and fail the update checks
Attachment #252941 - Flags: superreview?
Attachment #252941 - Flags: review?(robert.bugzilla)
(Assignee)

Updated

11 years ago
Attachment #252941 - Flags: superreview? → superreview?(darin.moz)
(Assignee)

Updated

11 years ago
Whiteboard: need reviews
(Assignee)

Comment 11

11 years ago
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?
(Assignee)

Comment 12

11 years ago
Created attachment 252970 [details] [diff] [review]
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.
Attachment #252941 - Attachment is obsolete: true
Attachment #252970 - Flags: superreview?(darin.moz)
Attachment #252970 - Flags: review?(sspitzer)
Attachment #252941 - Flags: superreview?(darin.moz)
Attachment #252941 - Flags: review?(robert.bugzilla)

Comment 13

11 years ago
It seems a shame not to share this code between the update service and the extension manager.
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 on attachment 252970 [details] [diff] [review]
turn off progress meter in error case

clearing review, to hear back about the #include suggestion.
Attachment #252970 - Flags: review?(sspitzer)
(Assignee)

Comment 16

11 years ago
Created attachment 253115 [details] [diff] [review]
same thing moved into a shared fragment
Attachment #252970 - Attachment is obsolete: true
Attachment #253115 - Flags: superreview?(darin.moz)
Attachment #253115 - Flags: review?(sspitzer)
Attachment #252970 - Flags: superreview?(darin.moz)
(Assignee)

Comment 17

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

A review from rstrong would be good too.
Attachment #253115 - Flags: review?(robert.bugzilla)
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

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

sr=darin w/ s/update/shared/ per rstrong
Attachment #253115 - Flags: superreview?(darin.moz) → superreview+
(Assignee)

Comment 20

11 years ago
Created attachment 253136 [details] [diff] [review]
same thing, new folder
Attachment #253115 - Attachment is obsolete: true
Attachment #253136 - Flags: review?(robert.bugzilla)
Attachment #253115 - Flags: review?(sspitzer)
Attachment #253115 - Flags: review?(robert.bugzilla)
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
Attachment #253136 - Flags: review?(robert.bugzilla) → review+
(Assignee)

Comment 22

11 years ago
Fix checked into trunk
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Assignee)

Updated

11 years ago
Attachment #253136 - Flags: approval1.8.1.2?
Attachment #253136 - Flags: approval1.8.0.10?

Comment 23

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

Approved for both branches, a=jay
Attachment #253136 - Flags: approval1.8.1.2?
Attachment #253136 - Flags: approval1.8.1.2+
Attachment #253136 - Flags: approval1.8.0.10?
Attachment #253136 - Flags: approval1.8.0.10+

Updated

11 years ago
Whiteboard: need reviews → needs landing
(Assignee)

Comment 24

11 years ago
checked into 1.8/1.8.0 branches
Keywords: fixed1.8.0.10, fixed1.8.1.2

Updated

11 years ago
Whiteboard: needs landing

Updated

11 years ago
Duplicate of this bug: 381179
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.