7

If I add a rule in Privoxy:

echo '{ +redirect{s@http://@https://@} }
.mozilla.org' >> /etc/privoxy/user.action

then I can't install Firefox Add-ons. Why?
I though the Firefox Add-ons installed through only HTTPS! If it's ain't using only HTTPS then it could be compromised in a way, that someone makes a tool that automates that: fetch the Add-on installs in a subnet (e.g.: LAN) and replace them with malicious code.. presto..a torjaned Add-on has been installed, and can do anything what the user can (who is running the Firefox).
This is important! Could someone confirm me?
Thanks.

LanceBaynes
  • 6,209
  • 12
  • 60
  • 92
  • Going direct seems to be over https: https://addons.mozilla.org/en-US/firefox/?browse=featured – Rakkhi May 23 '11 at 08:48
  • Also examining addons request using tamper data in Firfox 4.1 https://services.addons.mozilla.org/en-GB/firefox/discovery/pane/4.0.1/WINNT#{%22sslpersonas_standar... – Rakkhi May 23 '11 at 08:49
  • but If I _FORCE_ that "mozilla.org" could be only reachable with HTTPS then it times out! – LanceBaynes May 23 '11 at 09:11
  • For me at least it always redirects to https version – Rakkhi May 23 '11 at 09:21
  • If you see HTTPS in the browser bar, that doesn't means that the site you're viewing ONLY uses HTTPS. See e.g.: youtube.com... you can type https://youtube.com etc.. but IF YOU FORCE the .youtube domain to only use HTTPS..then the videos wont load... no flash viedos, no HTML5 videos..so it's not using fully HTTPS, I think the videos on an HTTP-only server... I'm thinking something similar with the Firefox Add-ons...but when coming to browser Add-ons, it could mean sec. hole? (fixme) – LanceBaynes May 23 '11 at 10:00

2 Answers2

11

Mozilla extensions, no matter what the download site says, are served through this URL:

http://releases.mozilla.org/pub/mozilla.org/addons/NUMBER/EXTENSION_NAME.xpi

But, here is the thing: releases.mozilla.org is load-balanced through DNS, it's used like a Content Distribution Network. Here is the dig result:

;; ANSWER SECTION:
releases.mozilla.org.   60  IN  CNAME   releases.geo.mozilla.com.
releases.geo.mozilla.com. 60    IN  A   216.165.129.141
releases.geo.mozilla.com. 60    IN  A   64.50.233.100
releases.geo.mozilla.com. 60    IN  A   64.50.236.52
releases.geo.mozilla.com. 60    IN  A   64.50.236.214
releases.geo.mozilla.com. 60    IN  A   128.61.111.9
releases.geo.mozilla.com. 60    IN  A   129.101.198.59
releases.geo.mozilla.com. 60    IN  A   131.188.12.212
releases.geo.mozilla.com. 60    IN  A   155.98.64.83
releases.geo.mozilla.com. 60    IN  A   156.56.247.196
releases.geo.mozilla.com. 60    IN  A   204.152.184.113
releases.geo.mozilla.com. 60    IN  A   204.152.184.196
releases.geo.mozilla.com. 60    IN  A   204.246.0.136
releases.geo.mozilla.com. 60    IN  AAAA    2001:6b0:e:2018::1337

Those are all the IPs that domain can take, you can hit a different server every time you use the URL. They are all different servers, usually hosted in various universities around the world.

And here comes the problem:

The result of tests I did just know confirm that none of these servers supports HTTPS connection.

So if you blindly try to reach https://releases.mozilla.org/pub/mozilla.org/addons/NUMBER/EXTENSION_NAME.xpi the request will fail, or will take too long because some of the servers don't immediately refuse the connection so it has to time out.

time wget https://releases.mozilla.org/pub/mozilla.org/addons/138/stumbleupon-3.81-fx+sm.xpi
https://releases.mozilla.org/pub/mozilla.org/addons/138/stumbleupon-3.81-fx+sm.xpi
Resolving releases.mozilla.org... 129.101.198.59, 131.188.12.212, 155.98.64.83, ...
Connecting to releases.mozilla.org|129.101.198.59|:443... failed: Connection timed out.
Connecting to releases.mozilla.org|131.188.12.212|:443... failed: Connection refused.
Connecting to releases.mozilla.org|155.98.64.83|:443... failed: Connection timed out.
Connecting to releases.mozilla.org|156.56.247.196|:443... failed: Connection refused.
Connecting to releases.mozilla.org|204.152.184.113|:443... failed: Connection timed out.
Connecting to releases.mozilla.org|204.152.184.196|:443... failed: Connection refused.
Connecting to releases.mozilla.org|204.246.0.136|:443... failed: Connection refused.
Connecting to releases.mozilla.org|216.165.129.141|:443... failed: Connection refused.
Connecting to releases.mozilla.org|64.50.233.100|:443... failed: Connection refused.
Connecting to releases.mozilla.org|64.50.236.52|:443... failed: Connection refused.
Connecting to releases.mozilla.org|64.50.236.214|:443... failed: Connection refused.
Connecting to releases.mozilla.org|128.61.111.9|:443... failed: No route to host.
Connecting to releases.mozilla.org|2001:6b0:e:2018::1337|:443... failed: Network is unreachable.

real    **9m31.370s**

It took 9:30 minutes for the request to finally fail (I don't have IPv6 connection right now so I don't know if the last server supports it, but I doubt it).

For third party verification this helps: https://www.ssllabs.com/ssldb/analyze.html?d=releases.mozilla.org

Just to make it clear: Extensions like HTTPS Everywhere will not work - in fact I tested it and the addon is still served through HTTP (it does not rewrite releases.mozilla.org - if it did, you wouldn't be able to get the extension.)

john
  • 10,998
  • 1
  • 36
  • 43
  • But it does at least some checks to verify that the XPI file is that XPI file thats on the mozilla servers, no?? – LanceBaynes May 23 '11 at 17:02
  • The only thing HTTP Everywhere does is to rewrite URL's from http://something to https:// something, according to rules it has. There is no rule for releases.mozilla.org, this url is not rewritten or checked in any way. – john May 23 '11 at 17:17
  • OMFG...then people could modify/compromise the unencrypted XPI files to whatever they want! so it's a security bug. – LanceBaynes May 23 '11 at 17:33
1

Yup, Mozilla Addons install on HTTP requests by default. Though if you use, HTTPS Everywhere, it installs on SSL mode.

MyPreciousss
  • 119
  • 3