275284 - update.mozilla.org is not accessible over http

Status: RESOLVED WONTFIX

(mozilla.org Graveyard :: Server Operations, task)

Description

[Deyan Stoykov]

update.mozilla.org can only be accessed via https. A user who wants to analyse
the  network traffic during the update process (in order to troubleshoot a
problem or just to get a better understanding of the way it works) can not do
that, because it is encrypted.

Steps to Reproduce:

1. Make a http request to update.mozilla.org.

Actual Results:

You get a HTTP "301 Moved permanently" response, that redirects the user agent
to https://....

Expected result:

The contents of update.mozilla.org should be accessible over an unencrypted as
well as over an encrypted connection for the reasons mentioned above. Since
app.update.url and extensions.update.url are set to https://update.mozilla.org/
by default, people will only use http:// if they have a good reason to do so and
change manually these preferences.

Alternatively, a virtual host with a subdomain that allows http could be set up,
while update.mozilla.org stays with its current configuration.

Comment 1

[Dave Miller [:justdave]]

I have a feeling we probably don't want to do this, but I'll let Dan make the
call.  I'm not sure what all the security implications are of exposing this
application to cleartext traffic.

Comment 2

[Frank Wein [:mcsmurf]]

I don't think the update process it the critical thing (where https is needed),
but rather the login panel on the website itself, etc. If you need to do some
debugging there, you can use the logging functions of Mozilla/Firefox (see
http://www.mozilla.org/projects/netlib/http/http-debugging.html, http logging
also works for https).

Comment 3

[Daniel Veditz [:dveditz] (OOO: back Aug 26)]

The update process is(In reply to comment #2)
> I don't think the update process it the critical thing (where https is needed),
> but rather the login panel on the website itself, etc.

The update process is absolutely critical. Without SSL an attacker could
silently redirect the client to get the update information from a fake site and
then install nasty counterfeit stuff defined there.

What about a separate test/beta site? We have something similar for bugzilla. We
do have a beta update site but I'm not sure how public it is, and the current
one wouldn't help much debugging problems in the live site since there have been
many changes.

What sort of problems do you need to debug? Couldn't you do it from a debug
version of Firefox that logs the traffic post encryption?

I'm pretty sure this is a WONTFIX unless you can come up with a more compelling
case.

Comment 4

[Deyan Stoykov]

(In reply to comment #3)
> The update process is(In reply to comment #2)
> > I don't think the update process it the critical thing (where https is 
needed),
> > but rather the login panel on the website itself, etc.
> The update process is absolutely critical. Without SSL an attacker could
> silently redirect the client to get the update information from a fake site 
and
> then install nasty counterfeit stuff defined there.
> What about a separate test/beta site? We have something similar for bugzilla. 
We
> do have a beta update site but I'm not sure how public it is, and the current
> one wouldn't help much debugging problems in the live site since there have 
been
> many changes.
> What sort of problems do you need to debug? 

Well, whenever an attempt to update an extension fails, I get a very 
uninformative error message. Most of the time I'd like to know why it failed. 
Was it an malformed .rdf file? A bad link to the .xpi file? A 404 or something 
else? A version mismatch? Anything alse? I even had no idea what info does it 
send, in what format and what does it expect to get back in response (I found 
some documents about that on the web later). This is sort of a barrier to 
community participation in the improvement of the software.

> Couldn't you do it from a debug version of Firefox that logs the traffic 
> post encryption?

I wasn't aware of the http debugging functionality when I submitted the bug. 
Although not as convinient as ethereal, it sort of does work for what I need. 
It also seems to be available in Firefox 1.0 (Final), not only in the nightly 
builds.

> I'm pretty sure this is a WONTFIX unless you can come up with a more 
compelling
> case.

I've made my point. I'm not making any assertions on how do the pros of 
the "force https" approach compare with the cons, but at least you are now 
aware of my concerns.

Comment 5

[Dave Miller [:justdave]]

closing this out based on the previous feedback on this bug.