Firefox Extension download process and the mess within

[ Update
The https://bugzilla.mozilla.org/show_bug.cgi?id=544660 bug was reported as fixed.

So where were we and where are we ?

Say I try it now:

As I commented previously on this blog entry, fixing this bug resolves little.
The above error is not a security warning/error.
If the user queries after it, might end up right here(unofficial Mozilla related web site):
http://kb.mozillazine.org/Unable_to_install_themes_or_extensions_-_Firefox#Invalid_file_hash

According to that entry: Manually install the extension (right-click the install link -> "Save Link As"-> save the .jar or .xpi file, then drag the file icon onto an open Firefox window).

Say I do that(it’s a reasonable explanation, and I’m on the correct web site, using HTTPS) and after I drag the downloaded extension:

It’s not hard to guess that I’ve manually downloaded the extension from the “wrong” place(this will happen even if I manually copy and paste the "HTTPS URL" which was a "safe" URL).
Also is not hard to guess what will follow when I hit Install Now above.

Mozilla’s very own take over that error:
This error message may be caused when you have Firefox set not to allow third-party cookies. To prevent this error, you need to temporarily enable third-party cookies.

]

[ Update
Giorgio Maone has filed a bug for this:
https://bugzilla.mozilla.org/show_bug.cgi?id=544660 ]

This is something that I’ve discussed a while ago with Ivan Ristic.

Say you go to https://addons.mozilla.org and download a popular extension. Maybe NoScript. The download location appears to be over HTTPS.

But not quite.
If we take a look:

• A request is used to search for the latest version. The location of this (latest) version is indicated with a 302 response(it has an https:// in front).

• now it searches for the specific version(over HTTPS), as instructed previously with the 302 response. And another 302 response(this time it has just a http:// in front) indicates the location of the file.

• and so the actual extension download happens over plain HTTP, although visually you have the impression that this is done over HTTPS.

This related bug hints at the possibility of having the extension download happening over HTTP and a file hash to be sent over HTTPS, which seem fairly reasonable.
However, it’s not clear what exactly happens(hence the mess word from the title of this blog post). Asking on that bug page seems to be a waste of time.

Edited to add
[Giorgio Maone commented that the hash is embedded in the download page. I was looking for it in the wrong place. Thanks Giorgio for the correction.

The modified extension’s hash:

Still, in my tests, this changes nothing to what is listed bellow for the default installation of Firefox 3.6 and 3.5.7(tried that today).

It only fails by default when I attempt to add the extension from the Add-ons pop-up window:

]

Today I had some time, so I’ve decided to play a little with this.

Test plan:
- a test VM using Windows XP SP3(I already have it in my lab), on which Firefox 3.6 will be installed. Snap Shots were used, to revert the machine to a clean state and re-test.
- a test web server holding my version of NoScript, initial test: instead I used the Adblock extension simply renaming the file.
- analyze the current location of NoScript. Which was: http://releases.mozilla.org/pub/mozilla.org/addons/722/noscript-1.9.9.45-fx+sm+fn.xpi
- on the VM using Windows XP SP3 we need to simulate somehow an environment where an attacker has access to the wire. The simplest trick is to use DNS for that and have the client resolving releases.mozilla.org to my web site. Editing the hosts file on the client did the trick.
- so the client will download the extension over HTTP from my web site, while keeping the green of the EV certificate visible to the user.

Let’s see what happens.
Navigate to https://addons.mozilla.org and attempt to Add to Firefox NoScript. This is a blind test. I’m not interfering except with the DNS trick.

Well, Wladimir Palant is now the author of NoScript, and of course, I’m downloading it over HTTPS.

Hit install, and things went fine, it tells me that Adblock was installed and to restart Firefox:

I do that, and the confirmation:

At this point, the extension download process tends to become amusing.

What happens if we modify the original NoScript extension, say have it to start NoScript with allow scripts globally by default.

Did that, re-test on a clean machine:

Click install and:

So are they using a hash after all ?
Then, why I was able to install Adblock instead of NoScript. Maybe they did not bind things properly.
Need a re-test.

Re-tested(rebooted my web site in the process), and it worked this time(looks like a misfire from my lab), without any major warnings.

Re-tested a couple of time, and success every time.

Wow!

Following Ivan’s suggestion to see what’s inside that SSL traffic, I’ve used Burp Proxy, made it use a custom certificate with SAN DNS Names fields, made Firefox trust the CA that issued this certificate, so that we will not get any warnings if either services.addons.mozilla.org or addons.mozilla.org or are used as destinations.

Tested again, and success one more time. Quickly looking at the history on Burp Proxy, and I could not spot any hash whatsoever(see the above within the edited section).

Assuming I’m not rusty, and missed something, this is not quite a safe way of downloading and installing an extension(politely saying that).

Ivan Ristic also hinted that the Submitting an add-on to AMO document is not clear if whether updates are also reviewed or not.

On a side note, they seem to do extension version checks update over HTTPS, this was spotted on my laptop: