[ 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:
![ff_aft_1[4] ff_aft_1[4]](/blog/image.axd?picture=ff_aft_1%5B4%5D.png)
![ff_aft_5[4] ff_aft_5[4]](/blog/image.axd?picture=ff_aft_5%5B4%5D.png)
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:
![ff_aft_6[4] ff_aft_6[4]](/blog/image.axd?picture=ff_aft_6%5B4%5D.png)
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.
![ff_ext_silly_8 ff_ext_silly_8](/blog/image.axd?picture=ff_ext_silly_8.png)
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).
![ff_ext_silly_5 ff_ext_silly_5](/blog/image.axd?picture=ff_ext_silly_5_thumb.png)
- 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.
![ff_ext_silly_6 ff_ext_silly_6](/blog/image.axd?picture=ff_ext_silly_6_thumb.png)
- and so the actual extension download happens over plain HTTP, although visually you have the impression that this is done over HTTPS.
![ff_ext_silly_7 ff_ext_silly_7](/blog/image.axd?picture=ff_ext_silly_7_thumb.png)
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.
![ff_ext_silly_13 ff_ext_silly_13](/blog/image.axd?picture=ff_ext_silly_13_thumb.png)
The modified extension’s hash:
![ff_ext_silly_14 ff_ext_silly_14](/blog/image.axd?picture=ff_ext_silly_14.png)
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:
![](/blog/image.axd?picture=2010%2f2%2fff_ext_silly_15.png)
]
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.
![ff_ext_silly_1 ff_ext_silly_1](/blog/image.axd?picture=ff_ext_silly_1_thumb.png)
Well, Wladimir Palant is now the author of NoScript, and of course, I’m downloading it over HTTPS.
![ff_ext_silly_2 ff_ext_silly_2](/blog/image.axd?picture=ff_ext_silly_2_thumb_1.png)
Hit install, and things went fine, it tells me that Adblock was installed and to restart Firefox:
![ff_ext_silly_3 ff_ext_silly_3](/blog/image.axd?picture=ff_ext_silly_3.png)
I do that, and the confirmation:
![ff_ext_silly_4 ff_ext_silly_4](/blog/image.axd?picture=ff_ext_silly_4.png)
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:
![ff_ext_silly_10 ff_ext_silly_10](/blog/image.axd?picture=ff_ext_silly_10.png)
Click install and:
![ff_ext_silly_9_inv ff_ext_silly_9_inv](/blog/image.axd?picture=ff_ext_silly_9_inv.png)
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.
![ff_ext_silly_11 ff_ext_silly_11](/blog/image.axd?picture=ff_ext_silly_11.png)
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:
![ff_ext_silly_12 ff_ext_silly_12](/blog/image.axd?picture=ff_ext_silly_12_thumb.png)