This is on the edge of security sensitive so I'll hide it for now anyway. There are a couple of potential issue relating to downloading XPIs after redirects. In the case of add-on installs initiated from webpages we currently allow downloading to continue after an initial https request for the file is redirected to http, I'm not sure if that should be allowed or not, but I know that AMO currently relies on the behaviour. In the case of add-on updates initiated through the add-ons manager, bug 389816 had the aim to only allow installation from servers trusted by built-in CAs when an add-on update was started over SSL. It didn't quite manage it. Though the server of the initial URL is checked, if that request is then redirected we neither ensure the final download happens over SSL nor do we check that the final server is trusted by a built in CA if it was SSL. The built in CA stuff probably isn't a real issue, we are likely to drop that requirement for add-on installs/updates in bug 435743. The question is should we allow an XPI download to be redirected from https to http for either add-on updates (I think not) and add-on installs (maybe).

I would assume preventing MITM was part of the purpose of requiring SSL for the initial download, in which case redirects to http would break that.

(In reply to comment #1) > I would assume preventing MITM was part of the purpose of requiring SSL for the > initial download, in which case redirects to http would break that. XPInstall makes no such requirement, the initial download of an install can be over plain HTTP. Since users can (and usually do) download executables over HTTP there's only downside in making XPInstall more restrictive. There is an SSL (or signed snippet) requirement for the updateURL. The rationale is that a user might feel comfortable with their network at the time of initial download and can cancel the install if they're not, but the daily silent update checks can happen at unpredictable times when the user might be remote on a compromised network. The AMO site itself requires SSL, because we control it and don't trust all users to be able to make knowledgeable judgments about the safety of their network. Plus we'd like to set a good example of responsible software delivery over the internet. AMO gives the user a sha-256 hash of the install over the secure channel before using HTTP for the download itself, so the download is safe from both MITM network tampering as well as hacked mirrors. (Using the hash requires JavaScript on the site, so if that's disabled then the download could be insecure. Too bad we don't have "link fingerprints" :-( bug 377245)

A couple of days ago Steven Roddis wrote the security alias with just this bug's concern, namely 1) Users might get a false sense of security seeing the "https:" URL in the dialog, and based on that go ahead and install on a potentially insecure network when actually it redirects to plain HTTP. 2) AMO itself does this redirection to insecure HTTP. I've explained AMO in comment 2, and as long as the user has JavaScript enabled the redirection is safe. But there are definitely times when a redirect to HTTP would be risky. I proposed that we abort the install if we redirect from https to http unless the site has given us a hash of the install package. (This means JavaScript would be required for AMO, unless we want to upgrade the site to avoid the redirect in that case. Should be few enough people that we could avoid melting down the local server.)

Apparently AMO is not correctly sending hashes right now (bug 544660). If XPInstall rejected https -> http redirects without hashes we would have discovered this earlier. On the other hand that would completely break AMO in the JS-disabled case. Better user-facing information about the potential insecurity of the download would be another way to combat this false sense of security (bug 310355).

Given that <http://www.carbonwind.net/blog/post/Firefox-Extension-download-process-and-the-mess-within.aspx> describes the problem, we can disclose the bug now.

On the add-ons manager rewrite branch we now only allow a redirect from https to http if a hash was provided for the download.

(In reply to comment #6) > On the add-ons manager rewrite branch we now only allow a redirect from https > to http if a hash was provided for the download. Does that mean non-js users won't be able to install off AMO anymore (because the hash is only applied if triggered with JS on)?

(In reply to comment #7) > (In reply to comment #6) > > On the add-ons manager rewrite branch we now only allow a redirect from https > > to http if a hash was provided for the download. > > Does that mean non-js users won't be able to install off AMO anymore (because > the hash is only applied if triggered with JS on)? That would be the case if we left this as-is. Why does AMO need the initial URL to be https? A potential option I can see is that non-JS users could download from a pure https connection that never redirects to http. I'm not sure if we have good stats on how much traffic that would be since I guess you can't use the mirror network in that case.

Yea, we can (and will need to) figure something out there. Perhaps we do just serve these requests from the app heads. Another option I could think of (throwing it out there in spite of it exceeding the scope here slightly): How about an intelligent <a> tag in HTML5 that Firefox recognizes. This way we don't rely on JavaScript to do the hash magic for us. Example: <a rel="moz-xpi-install" href="foo.xpi" data-hash="123456abc..." data-icon-url="http://...">install me!</a> This syntax has two advantages: - it provides hash checking, whether or not JS is user-disabled. - it is much more concise than binding a JS event to the same link. - it falls back just as well as the current code, if the browser does not understand the rel=moz-xpi-install and data attributes.

(In reply to comment #9) > Yea, we can (and will need to) figure something out there. Perhaps we do just > serve these requests from the app heads. > > Another option I could think of (throwing it out there in spite of it exceeding > the scope here slightly): How about an intelligent <a> tag in HTML5 that > Firefox recognizes. This way we don't rely on JavaScript to do the hash magic > for us. Example: > > <a rel="moz-xpi-install" href="foo.xpi" data-hash="123456abc..." > data-icon-url="http://...">install me!</a> > > This syntax has two advantages: > - it provides hash checking, whether or not JS is user-disabled. > - it is much more concise than binding a JS event to the same link. > - it falls back just as well as the current code, if the browser does not > understand the rel=moz-xpi-install and data attributes. This is nice, though I'd expect it to be non-trivial to implement. Something that would be easier would be if the hash got included in the headers of the first request to the https url that redirects you, something custom like: X-Target-File-Hash: 83768237236862 Detecting the presence of that in the code that handles the non-JS case would be pretty trivial.

Such a header would be trivial for us to add as well. We'd just send it before the Location: header and that should do the trick, I presume.

Dan, I mentioned my idea from comment 10 to you in passing a short time ago, does it seem like a useful thing to add? A few questions probably need to be considered: Should we use the hash for direct linking only or even if the url was loaded from an InstallTrigger call? If we do allow this from InstallTrigger what if the InstallTrigger provided a hash too, which one takes priority? More bikesheddy, what header name would be appropriate?

I believe the concerns here are fixed by the dependencies. Firefox 4 won't allow https -> http redirects unless a hash has been provided either by an InstallTrigger.install call or by a header in the https response.

We should probably wontfix this for 3.6, I doubt we'll backport this.