User.js: Firefox connections on about:blank page

Created on 24 Jun 2015  路  33Comments  路  Source: pyllyukko/user.js

Hi, just installed user.js and I've noticed that when I start Firefox (about:blank is my start page) he make some connections:
netstat -nputw|grep firefox
tcp 0 0 xxx.xxx.xxx.xxx:33848 216.58.208.206:443 ESTABLISHED 13427/firefox
tcp 0 0 xxx.xxx.xxx.xxx:49776 216.58.208.206:80 ESTABLISHED 13427/firefox
tcp 0 0 xxx.xxx.xxx.xxx:42962 93.184.220.29:80 ESTABLISHED 13427/firefox
tcp 0 0 xxx.xxx.xxx.xxx:41561 52.25.32.149:443 ESTABLISHED 13427/firefox
tcp 0 0 xxx.xxx.xxx.xxx:33846 216.58.208.206:443 ESTABLISHED 13427/firefox
tcp 0 0 xxx.xxx.xxx.xxx:36906 68.232.34.191:443 ESTABLISHED 14420/firefox

There is any way in user.js to disable this automatic connections?
Thanks!

PS. OS: Fedora 22 x64, Firefox 38.0.5, no add-ons loaded

needs more info

Most helpful comment

user_pref("extensions.webservice.discoverURL", "http://0.0.0.0"); Explained...

@Gibbio OCSP connections are most needed.

By removing the URLs in about:config the browser has way less connections.

Also addons may start connections, as for adblockers retrieving blacklists, but others have hard-linked calls: an example is Ghostery that can't be used without these calls to its own servers.

Also Ubuntu has its own modifications, as the Ubuntu Firefox Modifications addon.

All 33 comments

Hi.

Probably it is possible to disable these automatic connections.

Are you able to provide more information about these connections? For instance by observing the network traffic with tcpdump or Wireshark or some other tool. The connections going to port 80 should be clearly visible in the traffic capture and for the HTTPS connections (port 443), the DNS lookups would help. Also, an intercepting proxy tool, such as Burp can be put in between your browser and the internet to observe what's happening.

Currently, there are some automatic connections that are allowed on purpose. Namely browser.safebrowsing.malware.enabled and the plugins.update.notifyUser setting that opens the Mozilla plugin check page.

When I set the plugins.update.notifyUser to false, I can only see a connection to aus4.mozilla.org that is related to the H.264 plugin (should be disabled with media.gmp-gmpopenh264.enabled, I'll look into it).

I pushed a commit (65375871f42783a408365ad3d01416feecf9d72d), that sets browser.aboutHomeSnippets.updateUrl to ""... if you can check if that helped at all?

tested with new version, got 2 connection:
93.184.220.29
54.230.185.55

here the captures:
http://www.armtc.net/54.230.185.55.pcap
http://www.armtc.net/93.184.220.29.pcap

Also forgot to mention about extensions.update.enabled (I probably need to document these in the README). I disabled the search engine update with c9f0ec441e82048cf78e892c975f580ea8e47bf5, as it really doesn't seem that relevant anyway.

tested with new version, got 2 connection:
93.184.220.29
54.230.185.55

I checked the pcaps and:

  • 93.184.220.29 seems to be an OCSP request (this is intended)
  • 54.230.185.55 seems to be a request to self-repair.mozilla.org which seems to be yet another new Firefox feature (sigh!) called self-heal.

I wasn't able to find any setting related to that with a quick glance, but I'll keep looking, as it certainly sounds like something we want to disable. Thanks for reporting this!

Wait, no... It might be the Heartbeat thingie, as the default value of browser.selfsupport.url is https://self-repair.mozilla.org/%LOCALE%/repair, but that should've been taken care of with ca2c759c801c7d691073fadf7d488e37006acaaa. Hmm.

Can you replicate this behavior in your environment? Maybe is just a Fedora OS customizations...
I've just created a little bash script with a netstat:
while true ; do
sleep 0.1
netstat -nputw|grep firefox
done
run script and then run firefox, wait a few seconds then connections start.

If you need more help/test ill help you!

Can you replicate this behavior in your environment?

No. I'm not able to reproduce this, but I'll keep looking and I'm sure we'll figure it out. Can you double check the value of browser.selfsupport.url?

I've made this test:
fresh install of Xubuntu 15.04 i386 (virt-manager vm)
sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install git
reboot

start firefox, disabled all the plugins/addons and changed default page to about:blank
git clone https://github.com/pyllyukko/user.js
cp user.js/user.js .mozilla/firefox/38hc8da2.default/
start firefox, check about:config for browser.selfsupport.url -> is empty
close firefox, start loop script with netstat as root then start firefox. After few seconds I can see firefox quering dns and then he connect to:
52.25.32.149:443
216.58.208.206:443
93.184.220.29:80

Will try to reproduce this on Iceweasel (Debian) in the coming days.

Thanks, @nodiscc. I'll keep trying to reproduce this also.

Looks like I've managed to implement few bugs with 65375871f42783a408365ad3d01416feecf9d72d and c9f0ec441e82048cf78e892c975f580ea8e47bf5 :( They should be fixed now with b213091306c4d4210b86377be65a9eaa64ddfa03.

@Gibbio, can you try again now?

Sorry for the late reply, i've tested today with latest user.js version but i'm keep getting those connections. Seem that Firefox is getting worst every release :(

Sorry for the late reply, i've tested today with latest user.js version but i'm keep getting those connections. Seem that Firefox is getting worst every release :(

We'll just have to keep trying then...

Any progress on finding out the culprit? Is PaleMoon better in this regard?

@CHEF-KOCH : Okay will experiment as time allows, thanks.

@Gibbio: Can you check if about:networking reveals anything?

close firefox, start loop script with netstat as root then start firefox. After few seconds I can see firefox quering dns and then he connect to:
52.25.32.149:443
216.58.208.206:443
93.184.220.29:80

second ip is google owned and it redirects to www.google.com
third is a digicert ocsp server
first no idea, but its not an ocsp server

why would it be nothing to worry about? its an amazon ec2 instance. anybody could own it

this user has all addons disabled and is concerned about automatic connections so it would be nice to find out what all of the connections are for. im sure they are harmless but doesnt mean they are wanted

@Gibbio ive listed a bunch of ocsp servers including the ones shipped with firefox by default at #73
pretty sure 2 of the requests you got after disabling addons etc were ocsp requests (the google ip is very close to, and acts exactly like a google ocsp server i encountered). they are nothing to worry about

however, for firefox to be making ocsp requests in the first place, i think it means some ssl requests were made to some sites first. it can be all sorts of things. this user.js doesnt disable all background requests by default. also even if you disable your addons, they can still be checked for updates. maybe go through user.js and/or about:config and look for anything with urls or any enabled features which contact urls to investigate. worst case scenario its something user.js missed out but i doubt it since you're using an older version of firefox

i wasnt suggesting anyone make an ip whitelist, or any whitelist. it was just so that people could know whether or not ips belong to ocsp servers

i dont expect it to be a timeless list. and theres no talk of blocking or whitelisting! i just did it because i felt like it. people can do whatever they like with it. lol

which noscript project?

sure, do u want to talk somewhere else? we kinda hijacked this issue

I noticed from about:networking that my Firefox is still making connections to both tiles.services.mozilla.com and tiles-cloudfront.cdn.mozilla.net. We might need to configure browser.newtabpage.directory.source to deal the final blow to this tile nuisance.

yeah i have mine set to "" and i dont get those connections

yeah i have mine set to "" and i dont get those connections

Thought so. Any idea what's the difference with specifying "" and "data:application/json,{}" (from http://forums.mozillazine.org/viewtopic.php?f=7&t=2888321)?

nah no idea. i dont think there'd be any added benefit by doing the latter

Ping @Gibbio. Can you try again?

user_pref("extensions.webservice.discoverURL", "http://0.0.0.0"); Explained...

@Gibbio OCSP connections are most needed.

By removing the URLs in about:config the browser has way less connections.

Also addons may start connections, as for adblockers retrieving blacklists, but others have hard-linked calls: an example is Ghostery that can't be used without these calls to its own servers.

Also Ubuntu has its own modifications, as the Ubuntu Firefox Modifications addon.

I think this can be closed. As pointed out above the methodology is flawed. A better approach would be:

  • Setup a packet capture/analysis tool on a gateway machine
  • Ensure all Firefox traffic is forwarded through that machine
  • Ensure no other OS/application network traffic is present
  • Import required certificate in the packet analysis tool, MitM all connections
  • Post decrypted _contents_ and metadata of intercepted traffic here.

This can be done in another issue.

This issue comes from some about:config entry:

user_pref("browser.safebrowsing.enabled", true);
user_pref("browser.safebrowsing.malware.enabled", true);

These features are set to false in my own hardened user.js as they need some connections to work, as downloading a blacklist of hashes from both mozilla and google.

I also remove every single URL, as:
user_pref("extensions.blocklist.url", "https://blocklist.addons.mozilla.org/blocklist/

CNAME of blocklist.addons.mozilla.org is mozaws.net which has various possible IP calls:
https://ipinf.ru/sites-on-ip.php?domain=versioncheck.prod.mozaws.net

Was this page helpful?
0 / 5 - 0 ratings

Related issues

brakenow picture brakenow  路  7Comments

Riyyi picture Riyyi  路  3Comments

jawz101 picture jawz101  路  3Comments

berrythesoftwarecodeprogrammar picture berrythesoftwarecodeprogrammar  路  5Comments

BananaMangoFestival picture BananaMangoFestival  路  10Comments