459350 - make extension and firefox update url clickable to add certificate exceptions

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[soloturn]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3

company private networks secured by software like webwasher on one hand, and sites re-configuring a different set of allowed certificate signers make it difficult to update firefox as it is not allowed to connect to ssl secured update sites.

it would be beneficial to show the update urls so one can click on it and then add an exception for these certificates to make the later update run through without problem.

the same would apply for the firefox update itself.


Reproducible: Always

Steps to Reproduce:
1. try to update all add-ons via tools add-ons 
2. "an error occurred while trying to find updates for <extension>"
3. no more details are there, no url to click

1. try to update firefox via help - check for updates
2. "AUS: Update XML File Malformed (200)"
3. no further hint what is going on, no update url to click and analyse



Expected Results:  
the update url should be shown so one can click on it and analyse the problem or add a security exception.

Comment 1

[Jesse Ruderman]

I don't think we should "fix" this.  It would make MITM attacks much more likely to succeed.  Administrators who need to MITM everything can add their own root cert or something.

The AUS error message does sound a little bogus, though.

Comment 2

[Dave Townsend [:mossop]]

I believe that the update error message may have been fixed to be something more sensible on trunk already. But I agree, we shouldn't be exposing this ability to regular users.

Incidentally we currently still wouldn't allow updates to add-ons or the app even had you added exceptions for them. We are considering allowing add-on updates when the cert is signed by an installed CA though, see bug 435743 for more details.

Comment 3

[Daniel Veditz [:dveditz]]

Although this would be convenient for users it would make it impossible for Firefox to distinguish between a legitimate update and one that had been tampered with en route. Admins setting up this kind of institutionalized MITM will have to set up their own mitigations, or users will have to manually download and install updates.

Comment 4

[soloturn]

a signed hash of the package to be installed might be a better way to check if the package is not tampered with, not the certificate of the location where you got it from.

Comment 5

[Dave Townsend [:mossop]]

(In reply to comment #4)
> a signed hash of the package to be installed might be a better way to check if
> the package is not tampered with, not the certificate of the location where you
> got it from.

That is an option if developers don't want to use https. This is still a WONTFIX