Firefox connections on about:blank page about user.js

[Atavic]

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.

[berrythesoftwarecodeprogrammar]

@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

[Atavic]

See: https://github.com/Oros42/firefox_change_prefs

[pyllyukko]

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 (6537587), that sets browser.aboutHomeSnippets.updateUrl to ""... if you can check if that helped at all?

[Gibbio]

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

[Gibbio]

More captures here:
http://www.armtc.net/52.25.32.149.pcap
http://www.armtc.net/216.58.208.206.pcap
http://www.armtc.net/173.194.65.93.pcap

checked and all plugins/addons are disabled

[pyllyukko]

Also forgot to mention about extensions.update.enabled (I probably need to document these in the README). I disabled the search engine update with c9f0ec4, 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!

[pyllyukko]

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 ca2c759. Hmm.

[Gibbio]

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!

[pyllyukko]

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?

[Gibbio]

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

[nodiscc]

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

[pyllyukko]

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

[pyllyukko]

Looks like I've managed to implement few bugs with 6537587 and c9f0ec4 :( They should be fixed now with b213091.

@Gibbio, can you try again now?

[Gibbio]

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 :(

[pyllyukko]

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...

[Hunter-Github]

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

[Hunter-Github]

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

[pyllyukko]

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

[berrythesoftwarecodeprogrammar]

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

[berrythesoftwarecodeprogrammar]

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

[berrythesoftwarecodeprogrammar]

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

[berrythesoftwarecodeprogrammar]

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

[berrythesoftwarecodeprogrammar]

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

[berrythesoftwarecodeprogrammar]

which noscript project?

[berrythesoftwarecodeprogrammar]

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

[pyllyukko]

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.

[berrythesoftwarecodeprogrammar]

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

[pyllyukko]

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)?

[berrythesoftwarecodeprogrammar]

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

[pyllyukko]

Ping @Gibbio. Can you try again?

[nodiscc]

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.

[Atavic]

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