Why is Firefox connecting to ROGUE sites & without consulting with the HOSTS file?

[Jannah Jankowski]

Why does Firefox (in Safe Mode or not) connect to rogue sites?
http://i.cubeupload.com/T274r0.jpg

Why doesn't Firefox respect the Windows HOSTS file?
http://i.cubeupload.com/P0jKaY.jpg

In my hosts file are entries to block rogue sites that show up as
connections Firefox makes on its own, even when Firefox is opened to a
blank page in SAFE MODE.

Worse, Firefox does not seem to respect the Windows HOSTS file.
How can that even be possible?

1. I add an entry to the Windows hosts file and SAVE it.
2. I start Firefox in SAFE mode and open to a blank page.
3. Firefox _still_ shows up as "ESTABLISHED" to that rogue site.

How can that possibly be that Firefox doesn't respect the hosts file?

Where do these rogue connections come from anyway?


------------------ Here are just the first six of amazonaws --------
127.0.0.1 ec2-52-25-189-162.us-west-2.compute.amazonaws.com # firefox
safemode
127.0.0.1 ec2-52-26-2-199.us-west-2.compute.amazonaws.com # firefox
safemode
127.0.0.1 ec2-54-148-80-75.us-west-2.compute.amazonaws.com # firefox
safemode
127.0.0.1 ec2-54-213-112-246.us-west-2.compute.amazonaws.com # firefox
safemode
127.0.0.1 ec2-54-213-123-171.us-west-2.compute.amazonaws.com # firefox
safemode
127.0.0.1 ec2-54-69-9-44.us-west-2.compute.amazonaws.com # firefox safemode
------------------ Here are just the first six of cloudfront --------
127.0.0.1 server-52-84-24-10.sea32.r.cloudfront.net # firefox safemode
127.0.0.1 server-52-84-24-129.sea32.r.cloudfront.net # firefox safemode
127.0.0.1 server-52-84-24-141.sea32.r.cloudfront.net # firefox safemode
127.0.0.1 server-52-84-24-205.sea32.r.cloudfront.net # firefox safemode
127.0.0.1 server-52-84-24-28.sea32.r.cloudfront.net # firefox safemode
127.0.0.1 server-52-84-24-7.sea32.r.cloudfront.net # firefox safemode
------------------

[»Q«]

In
<news:mailman.551.1467221218...@lists.mozilla.org>,

Jannah Jankowski <JannahJ...@JannahJankowski.com> wrote:

> Why doesn't Firefox respect the Windows HOSTS file?
> http://i.cubeupload.com/P0jKaY.

> 127.0.0.1 ec2-52-25-189-162.us-west-2.compute.amazonaws.com

> 127.0.0.1 server-52-84-24-10.sea32.r.cloudfront.net

All of the info you posted, including the screenshot, shows Firefox
connecting to 127.0.0.1. That is *because* you have used your hosts
file to map some domains to that IP address; that's the *function* of
a hosts file.

Firefox does not "consult" a hosts file, and this has nothing to do
with Firefox "respecting" a hosts file or not. Your hosts file is only
used by your network stack when it's determining what IP address
belongs to a hostname.

[Jannah Jankowski]

»Q« wrote:

> All of the info you posted, including the screenshot, shows Firefox
> connecting to 127.0.0.1. That is *because* you have used your hosts file
> to map some domains to that IP address; that's the *function* of a
> hosts file.
>
> Firefox does not "consult" a hosts file, and this has nothing to do with
> Firefox "respecting" a hosts file or not. Your hosts file is only used
> by your network stack when it's determining what IP address belongs to a
> hostname.

Thank you for attempting an answer, because this has perplexed me.

I realize there are two questions:
a. What does Firefox try to contact rogue servers?
b. How does Firefox respect the HOSTS file?

The first question is still valid, even if the second one is more confused.

On this picture (http://i.cubeupload.com/T274r0.jpg), you see two
different rogue server connections that are "ESTABLISHED" by Firefox.

Whether I have those two rogue servers listed in my hosts file, or not,
Firefox (even opened to a blank page in safe mode) attempts to establish a
connection to those two rogue servers (and plenty more).

So the main question is why does Firefox connect to such rogue servers?

The secondary question is really how to *stop* Firefox from connecting to
rogue servers. I attempted to stop Firefox from connecting to rogue
servers by turning off everything in Firefox preferences that cause it to
connect to rogue servers (e.g., web forgeries, reported attack sites,
search engine updates, firefox updates, etc.).

What remains after turning off everything in the Firefox preferences is
that Firefox tries to connect to amazonaws.com & cloudfront.net rogue
servers (whether in safe mode or not, and when opening to a blank page).

Why?
The main question is *how* do we prevent Firefox from trying to connect to
these rogue servers?

[Ed Mullen]

On 6/29/2016 at 1:26 PM, Jannah Jankowski's prodigious digits fired off:

<https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections?redirectlocale=en-US&redirectslug=Firefox+makes+unrequested+connections>

or

<http://tinyurl.com/ojrkb6j>


--
Ed Mullen
http://edmullen.net/
"An ounce of practice is worth more than tons of preaching." - Mohandas
Gandhi

[Christian Riechers]

On 06/29/2016 09:12 PM, Jannah Jankowski wrote:
> »Q« wrote:
>> All of the info you posted, including the screenshot, shows Firefox
>> connecting to 127.0.0.1. That is *because* you have used your hosts file
>> to map some domains to that IP address; that's the *function* of a
>> hosts file.
>>
>> Firefox does not "consult" a hosts file, and this has nothing to do with
>> Firefox "respecting" a hosts file or not. Your hosts file is only used
>> by your network stack when it's determining what IP address belongs to a
>> hostname.

<snip>

> What remains after turning off everything in the Firefox preferences is
> that Firefox tries to connect to amazonaws.com & cloudfront.net rogue
> servers (whether in safe mode or not, and when opening to a blank page).

Can you explain what makes these servers 'rogue' ones?

[Jannah Jankowski]

Jannah Jankowski wrote:

> I realize there are two questions:
> a. What does Firefox try to contact rogue servers?
> b. How does Firefox respect the HOSTS file?
>
> The first question is still valid, even if the second one is more
> confused.

If we just concentrate on the Windows HOSTS file, we can see that Firefox
does *something* with the Windows HOSTS file in some cases:
MAJOR BUG: Firefox ignores the hosts file
https://support.mozilla.org/en-US/questions/1011327

Apparently Firefox does "something" with the "DNS Cache":
At what point does Firefox read/reread the hosts file?
http://forums.mozillazine.org/viewtopic.php?f=7&t=2565953

That file talks about the setting "network.dnsCacheExpiration".

[Jannah Jankowski]

Ed Mullen wrote:


> <https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-
connections?redirectlocale=en-US&redirectslug=Firefox+makes+unrequested
+connections>
>
> or
>
> <http://tinyurl.com/ojrkb6j>

Thank you for that reference to:
How to stop Firefox from making automatic connections
https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections

1. Automatic updates and Security
I already has set Firefox to "Never check for updates".

2. Since I'm debugging why Firefox is slow, I already
wiped out all profiles and had recently installed the
latest software, so there were no addons.
Even so, I had already globally set addons to update
only manually.

3. I had not thought about "blocklists", so I changed
extensions.blocklist.enabled;true
to
extensions.blocklist.enabled;false

4. I already had Firefox set to not "Block reported
web forgeries."

5. I already had Firefox set to not "Block reported
attack sites".

6. I had not thought about "signatures" so I changed
browser.safebrowsing.downloads.remote.enabled;true
to
browser.safebrowsing.downloads.remote.enabled;false

7. I had tracking protection turned on, so I turned
it off.

8. I had already turned off the setting to "Query
OCSP responder servers to confirm the current
validity of certificates".

9. I had not known about the "network.prefetch-next"
setting so I changed it from
network.prefetch-next;true
to
network.prefetch-next;false

10. I just recently learned of Firefox DNS prefetching:
So I turned it off, changing
network.dns.disablePrefetch;true
to
network.dns.disablePrefetch;false

11. I changed the Firefox speculation from
network.http.speculative-parallel-limit;6
to
network.http.speculative-parallel-limit;0

12. There is apparently no way to turn off the
Firefox prefetch of Addon information if the Addons
page is invoked; so I left that alone as there
are no addons.

13. I already had Firefox set to "When Firefox
starts to Show a blank page".

14. I have no extensions as I had wiped out my
profiles and reinstalled Firefox fresh on Windows.
But I checked and Extensions (add ons actually)
are set to manually update.

15. I never use bookmarks so the only bookmarks
are those that Firefox adds by default. There is
no mention if any of those firefox default bookmarks
are "live bookmarks", but just in case, I deleted
all the bookmarks supplied by Firefox.

16. Unfortunately, I could delete all the garbage
bookmarks that Firefox installed *except* the
useless bookmark named "View Pocket List".

*HOW DO YOU GET RID OF THE POCKET BOOKMARK?*

Changing this setting did not work:
browser.toolbarbuttons.introduced.pocket-button;true
to
browser.toolbarbuttons.introduced.pocket-button;false

17. I have no unfinished downloads to prevent restarts.

18. I'm not using a custom search plugin.

19. I'm not using Firefox sync.

20. I'm not using "Firefox Hello - video and voice
conversations online" features. Nonetheless, I changed
loop.enabled;true
to
loop.enabled;false

21. I had already set the new tab to open blank:
browser.newtabpage.enhanced;false

While I was there, I changed
services.sync.prefs.sync.browser.newtabpage.enhanced;true
to
services.sync.prefs.sync.browser.newtabpage.enhanced;false

22. I changed browser.newtabpage.directory.source from
browser.newtabpage.directory.source;https://tiles.services.mozilla.com/v3/links/fetch/%LOCALE%/%CHANNEL%
to
browser.newtabpage.directory.source;< a blank value >

23. I changed browser.aboutHomeSnippets.updateUrl from
browser.aboutHomeSnippets.updateUrl;https://snippets.cdn.mozilla.net/%STARTPAGE_VERSION%/%NAME%/%VERSION%/%APPBUILDID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/
to
browser.aboutHomeSnippets.updateUrl;< a blank value >

24. I set the browser.search.geoip.url from
browser.search.geoip.url;https://location.services.mozilla.com/v1/country?key=%MOZILLA_API_KEY%
to
browser.search.geoip.url;< a blank value >

25. I changed browser.startup.homepage_override.mstone from
browser.startup.homepage_override.mstone;47.0
to
browser.startup.homepage_override.mstone;ignore

26. I changed extensions.getAddons.cache.enabled from
extensions.getAddons.cache.enabled;true
to
extensions.getAddons.cache.enabled;false

27. I changed browser.selfsupport.url from
browser.selfsupport.url;https://self-repair.mozilla.org/%LOCALE%/repair
to
browser.selfsupport.url;< a blank value >

28. I searched for the media.gmp-gmpopenh264.enabled
setting to set it to false, but it did not exist.

29. WebRTC seemed extremely complicated, so I left
it alone as the page said not how to turn it off.

30. The browser.casting.enabled was already set to
browser.casting.enabled;false

Did I miss anything?

[Jannah Jankowski]

Christian Riechers wrote:

>> What remains after turning off everything in the Firefox preferences is
>> that Firefox tries to connect to amazonaws.com & cloudfront.net rogue
>> servers (whether in safe mode or not, and when opening to a blank page).
>
> Can you explain what makes these servers 'rogue' ones?

That's a simple question, but you don't have the problem
that I have.

My problem is that whenever I start Firefox, my CPU jumps to 100%
and stays there forever. When I close Firefox, my CPU drops to
single digit percentages.

The problem made Firefox impossible to use, so I wiped out the
every firefox related directory I could find and uninstalled
FIrefox with CCleaner and ran registry cleans with Ccleaner
and ensured that Firefox was absolutely gone from my system.

Then I installed a clean copy of Firefox 47.0 on Windows.

Firefox *still* consumes 100% of the cpu "at times", so I'm
trying to debug why Firefox is behaving so badly.

I am taking it one step at a time, so I just implemented
the 30 steps that Ed Mullen proposed, and, so far, that
*seems* to have helped. I have only run Firefox twice
since implenting those 30 solutions.

At this point, *any* domain that Firefox goes to when I
simply start Firefox in Safe Mode to a blank page that
is cryptically named (such as the ones listed in the OP)
certainly remain on the suspect list.

[Ralph Fox]

On Wed, 29 Jun 2016 12:26:26 -0500, Jannah Jankowski wrote:

> Why does Firefox (in Safe Mode or not) connect to rogue sites?
> http://i.cubeupload.com/T274r0.jpg
>
> Why doesn't Firefox respect the Windows HOSTS file?
> http://i.cubeupload.com/P0jKaY.jpg
>
> In my hosts file are entries to block rogue sites that show up as
> connections Firefox makes on its own, even when Firefox is opened to a
> blank page in SAFE MODE.
>
> Worse, Firefox does not seem to respect the Windows HOSTS file.
> How can that even be possible?

If you want the HOSTS file to block Firefox from opening a connection,
you need to find which domain name Firefox used -- which may not be
the same as the domain name showing in Process Hacker.

i) The same server can have multiple domain names. For example,
"paint.net" and "ip-50-63-202-26.ip.secureserver.net" go to
the same server at IP address 50.63.202.26

ii) Process Hacker does not show which domain name Firefox used.
Process Hacker gets the IP address, (say) 50.63.202.26, and
does a reverse-DNS lookup to get one of the domain names.
That domain name may not be the same as the domain name which
Firefox used.

iii) Adding a domain name (say) "ip-50-63-202-26.ip.secureserver.net"
to your hosts file can only block Firefox when Firefox uses
that same domain name to open a connection. It will not block
Firefox when Firefox uses another one of the server's domain
names, (say) "paint.net", to open a connection.

> 1. I add an entry to the Windows hosts file and SAVE it.
> 2. I start Firefox in SAFE mode and open to a blank page.
> 3. Firefox _still_ shows up as "ESTABLISHED" to that rogue site.

Firefox connects to the server using another domain name which
is not in the HOSTS file. Because that other domain name is not
in the HOSTS file, it is not blocked.

Process Hacker does not show the domain name which Firefox used.
Process Hacker shows another domain name for the same server.
Process Hacker obtains the other domain name using reverse DNS.

> How can that possibly be that Firefox doesn't respect the hosts file?
>
> Where do these rogue connections come from anyway?
>
>
> ------------------ Here are just the first six of amazonaws --------
> 127.0.0.1 ec2-52-25-189-162.us-west-2.compute.amazonaws.com # firefox
> safemode
> 127.0.0.1 ec2-52-26-2-199.us-west-2.compute.amazonaws.com # firefox
> safemode
> 127.0.0.1 ec2-54-148-80-75.us-west-2.compute.amazonaws.com # firefox
> safemode
> 127.0.0.1 ec2-54-213-112-246.us-west-2.compute.amazonaws.com # firefox
> safemode
> 127.0.0.1 ec2-54-213-123-171.us-west-2.compute.amazonaws.com # firefox
> safemode
> 127.0.0.1 ec2-54-69-9-44.us-west-2.compute.amazonaws.com # firefox safemode
> ------------------ Here are just the first six of cloudfront --------
> 127.0.0.1 server-52-84-24-10.sea32.r.cloudfront.net # firefox safemode
> 127.0.0.1 server-52-84-24-129.sea32.r.cloudfront.net # firefox safemode
> 127.0.0.1 server-52-84-24-141.sea32.r.cloudfront.net # firefox safemode
> 127.0.0.1 server-52-84-24-205.sea32.r.cloudfront.net # firefox safemode
> 127.0.0.1 server-52-84-24-28.sea32.r.cloudfront.net # firefox safemode
> 127.0.0.1 server-52-84-24-7.sea32.r.cloudfront.net # firefox safemode
> ------------------

--
Kind regards
Ralph

[Good Guy]

On 29/06/2016 20:39, Jannah Jankowski wrote:

That file talks about the setting "network.dnsCacheExpiration".

then why not try to change these settings:

--

[Mayayana]

I just answered your post in the Win7 group. I think
the dnsCache setting is important to set to 0. And not
just for HOSTS. It's a nutty setting altogether. There's
no reason for caching DNS for more than a day or so.

Beyond that, I think what you may be seeing is
rental servers. I've noticed the same with Akamai.
Akamai is one of a number of rental servers that
large sites hire to carry traffic. Akamai carries a great
deal of traffic for big sites. They also spy and sell
the data. It's almost like a wiretap. They're not the
website you visit, but in many cases they're the
website serving the files, which affords them Google-
like spying capabilities, even though most people
have never even heard of the company.

Cloudfront seems to be the same -- an Amazon
version of server rental, or "content delivery network".
There seems to be a technical detail amiss in how
those connections are handled. (Not a FF problem.
Just a vulnerability in the HOSTS/DNS system.)
For example, if I go to microsoft.com I may connect
to Akamai, even though I'm blocking Akamai. That
seems to indicate that Microsoft is somehow passing
the request through, so that there's never an actual
DNS lookup for Akamai. Thus, HOSTS never gets
consulted. As far as I know there's nothing you can do
about that, other than to avoid visiting sites that
subcontract their web server load to sleazeball
operations like Akamai. That would leave you unable
to visit many of the biggest sites online.

[Jannah Jankowski]

Good Guy wrote:

> then why not try to change these settings:
>

> DNS-Settings
> <http://content.screencast.com/users/JT19560819/folders/Jing/
media/18c330fe-b863-4126-85f6-5441ea78ee0c/2016-06-29_2207.png>

The question is *what* to set them to so that
the DNS cache is consulted *every* time Firefox
needs to resolves a domain to an IP address.

Here is what an about:config shows for "network.dns":
network.dnsCacheExpirationGracePeriod;60
network.dnsCacheExpiration;60
network.dnsCacheEntries;400
network.dns.offline-localhost;true
network.dns.localDomains;
network.dns.ipv4OnlyDomains;
network.dns.get-ttl;true
network.dns.disablePrefetch;false
network.dns.disableIPv6;false
network.dns.blockDotOnion;true

Which settings are the important ones that cause
Firefox to check DNS *every* time?

[Good Guy]

On 29/06/2016 22:19, Jannah Jankowski wrote:

The question is *what* to set them to so that the DNS cache is consulted *every* time Firefox needs to resolves a domain to an IP address.

0   (this is # ZERO)

--

[VanguardLH]

The hosts file is used as a local hostname to IP address lookup.
Obviously it is NOT used when an IP address is already specified. If a
web page references an external resource using its IP address, there is
no DNS lookup (in the local DNS cache, in the local hosts file, or to
the DNS server). With an IP address, DNS is not involved.

It is unclear in your snapshot of Process Hacker if that tool shows you
what was that actual host connect request or not. Looks like an
external tool to monitor connections but it won't know if the client
used a hostname (which then involved a DNS lookup) or an IP address
(which does not involve DNS which also means no involvement of the hosts
file). Maybe the connect request was to an IP address and Process
Hacker is doing the lookup itself (resolve) to tell you the hostname for
that IP address, if it has one (hosts do not need a hostname to connect
to them - humans like names, computers require numbers). If that tool
has an option to "Show DNS name", "Resolve addresses", or something
similar then turn it off. Alas, some network tools (e.g., Sysinternals
TCP View) will switch between showing [resolved] hostnames or IP
addresses. They can only show to where the process connected, not
whether the client used a hostname or IP address. Those tools are
operating outside the client that is issuing the connect requests (and
already did the DNS lookup to get the hostname equated to an IP
address). You would need something, like Wireshark, to match up the DNS
traffic to the connections you see in Process Hacker or TCP View. Else,
you would have to use a tool inside the client to see what the client
actually specified (before it might issue a DNS request). I'm not sure
an external or internal network tool will tell you if a DNS resolution
came from the hosts file or not. For that, you might have to see if the
client (via an internal tool) issued a hostnamed connection request and
then see if there was matching DNS traffic (so any missing traffic would
be accounted for the local hosts resolution). Of course, you could
rename the hosts file so it never gets used and then monitor DNS traffic
(to the DNS server) to see when the client specified hostnames. I don't
know if F12 -> Network tool inside of Firefox will show you its raw
connection requests (so you can tell if it use a hostname or IP address)
or if it "conveniences" the user by also resolving to hostnames even for
IP addressed connection requests.

Rename the hosts file for now so you can actually monitor the DNS
traffic. With traffic monitoring (not just connection listing), you
could tell which connections the client made that were IP addressed (no
DNS traffic for those) and which were hostnamed (which would involved
DNS traffic).

Also make sure you aren't using any local proxy that uses the MITM (man
in the middle) scheme to intercept and interrogate your web traffic.
Several anti-virus programs add their certificate into Firefox's private
certificate store (since it won't use the global cert store) so they can
intercept HTTPS traffic to afford interogation of it to look for
malicious content; else, they cannot look inside HTTPS traffic and are
blind to any nasties within. You will have to disable its HTTPS
scanning feature. Some streaming capture programs also use the MITM
scheme so they can capture videos from HTTPS sites.

In another reply, you mentioned disabling Firefox from updating its
blocklists (regarding extensions, not an adblocker). Firefox does have
its own adblocker although it is disabled by default in normal mode but
enabled by default in private browsing mode. In private mode, add-ons
are disabled so your adblockers are ineffective in private mode and
probably why Mozilla added their own inbuilt tracking blocker. Mozilla
uses the Disconnect.me blocklist and may be updating it even if the
feature is disabled so you have an updated blocklist if and when you do
enable it. Open a private window in Firefox and notice at the right the
option to enable/disable the tracking blocklist. When I first heard
about this, there was just one about:config setting to enable or disable
this feature. When Mozilla later decided to add it, by default, to the
private browsing mode, then there were two settings: one for normal mode
enable/disable (privacy.trackingprotection.enabled) and another for
private mode enable/disable (privacy.trackingprotection.pbmode.enabled).
Again, I don't that disabling these features prevents Firefox from
updating the tracking blocklist.

Did you set geo.enabled to false?

Did you disable the built-in Google-based safebrowsing add-on
(browser.safebrowsing.enabled)? That might be related to the "block
reported attack sites" and "block reported web forgeries" options that
you said you disabled; however, why would there be 2 options for 1
setting in about:config? I haven't bothered toggling those options to
see what about:config settings they affect. There is another setting
(browser.safebrowsing.malware.enabled) so that's perhaps why there are 2
option settings. There are a slew of browser.safebrowsing.* entries in
about:config, some of which deal with the update interval. Again, as
with the tracking blocklist, I don't know that disabling the feature(s)
also means disabling their update.

As to removing the Pocket bookmark ...
I don't have the Pocket bookmark but then I chose to hide it. As I
recall, if you customize the toolbar and drag out the Pocket icon (so it
isn't in the toolbar but in the reserve list) then the Pocket bookmark
disappears. However, I also have extensions.pocket.enabled set False.
You might have to set True so you can customize the toolbar (remove
Pocket) and then change the setting to False.

[Good Guy]

On 29/06/2016 22:19, Jannah Jankowski wrote:

<snipped>

Could you tell us how can we replicate this problem on our machine?  I tried to go to one link and it didn't work:



Also, have tried it in IE11 or Edge or Chrome?

I always thought that looking up the hosts file is the function of the Operating System not the browser's.  It is the OS that blocks or allows certain sites.  For example, you can't block a Microsoft.com site on a Windows system.  Windows won't allow you this.  I don't know if Linux can block Microsoft.com site so Walts can try it and tell us.

--

[»Q«]

In
<news:mailman.512.1467229218...@lists.mozilla.org>,

Jannah Jankowski <JannahJ...@JannahJankowski.com> wrote:

> If we just concentrate on the Windows HOSTS file, we can see that
> Firefox does *something* with the Windows HOSTS file in some cases:

No.

> MAJOR BUG: Firefox ignores the hosts file
> https://support.mozilla.org/en-US/questions/1011327
>
> Apparently Firefox does "something" with the "DNS Cache":

Firefox keeps a cache of DNS query results so that it have to burden
the system with superfluous queries.

> At what point does Firefox read/reread the hosts file?

From the SUMO link you gave above, "Firefox doesn't read the operating
system's hosts file directly. Ever."

> http://forums.mozillazine.org/viewtopic.php?f=7&t=2565953

And from that one, "On a Windows OS Firefox does not read the hosts
file... Windows does."

[Mayayana]

> At what point does Firefox read/reread the hosts file?

>From the SUMO link you gave above, "Firefox doesn't read the operating
system's hosts file directly. Ever."

> http://forums.mozillazine.org/viewtopic.php?f=7&t=2565953

And from that one, "On a Windows OS Firefox does not read the hosts
file... Windows does."

---------------------

I don't think so. Any normal software
calling a server will use something like
gethostbyname to resolve the URL to IP
address. (Unless it's just using the IE
wrapper functions from the likes of
wininet.dll or urlmon.dll.) It would make
sense that it would first check the HOSTS
file. gethostbyname is not a kernel32 or
user32 function. It's a winsock function.
Which is to say that it's probably a call
to the selected DNS server, as opposed
to being equivalent to "WindowsGetMeThisIP".

Software using a function like
UrlDownloadTofile wouldn't check HOSTS,
but that function is just a wrapper around
an IE browser window, which normally also
adds to the IE cache and history record.
That may be the source of the misunderstanding:
Many Windows programmers mistakenly think
the IE wrapper functions are the core Internet
functions. It's unlikely that FF would use
such high-level wrapper APIs. That would
make it no more than an IE wrapper browser,
like Maxthon.

To test that I just went to your link in
Pale Moon with Filemon running. I see the
following series of file seeks from Pale Moon,
repeated several times. No other process
is shown to open HOSTS:

palemoon.exe:1164 OPEN C:\WINDOWS\system32\drivers\etc\hosts SUCCESS
palemoon.exe:1164 READ C:\WINDOWS\system32\drivers\etc\hosts SUCCESS Offset:
0 Length: 4096
palemoon.exe:1164 READ C:\WINDOWS\system32\drivers\etc\hosts SUCCESS Offset:
4096 Length: 4096
palemoon.exe:1164 READ C:\WINDOWS\system32\drivers\etc\hosts END OF FILE
Offset: 6600 Length: 4096

[VanguardLH]

Jannah Jankowski wrote:

> How does Firefox respect the HOSTS file?

Shouldn't be a choice by Firefox. When Firefox issues a connection
request that uses a hostname, DNS resolution gets involved. It is then
the operating system that handles the DNS lookup, so it is the OS that
determine to first look at the hosts file (for local resolution) and, if
not resolved, then issue a lookup request to the DNS server.

Web-centric clients don't tell the OS how to do the DNS resolution. If
the client uses an IP address, DNS is not involved (which resolves
hostnames to IP addresses). If the client uses a hostname then it has
to issue a network API request to the OS for DNS resolution often
through WNet functions. See:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa385406(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=vs.85).aspx

Applications having to perform their own network functions disappeared
when we moved away from MS/IBM-DOS (and even then many apps relied on
external libraries with the required network functions).

[Jannah Jankowski]

You are wise beyond your years! :)
I didn't mention it, but I also found that bringing up a PDF in Firfox
caused Adobe Acrobat Reader to run which caused that Akamai to show up so
I had already put these lines in my HOSTS file
127.0.0.1 a184-25-56-91.deploy.static.akamaitechnologies.com # adobe
127.0.0.1 a23-45-86-146.deploy.static.akamaitechnologies.com # adobe
127.0.0.1 a23-5-219-228.deploy.static.akamaitechnologies.com # adobe

[Jannah Jankowski]

Good Guy wrote:

> I always thought that looking up the hosts file is the function of the
> Operating System not the browser's. It is the OS that blocks or allows
> certain sites. For example, you can't block a Microsoft.com site on a
> Windows system. Windows won't allow you this. I don't know if Linux
> can block Microsoft.com site so Walts can try it and tell us.

I am not the expert, so I can only conjecture how I think it works.

1. You type www.somewhere.com along with http (i.e., port 80)
2. Firefox checks the Firefox DNS cache, but it's not there
3. Firefox checks the Windows DNS cache, but it's not there
4. So Windows first checks the HOSTS file, but it's not there
5. Then Windows checks the Windows DNS cache, but it's not there
6. So Windows checks what the DNS server is
7. For me, that's gonna be set to the router 192.168.1.1
8. So Windows asks 192.168.1.1 who the DNS Server is
9. The router returns the Google DNS Server 8.8.8.8
10. So Windows sends a port 53? DNS request to 8.8.8.8
11. (It actually follows a hierarchy so let's simplify here.)
12. 8.8.8.8 returns the IP address 1.2.3.4 to the DNS cache
13. 1.2.3.4 is handed back to to Windows from 8.8.8.8
14. Windows puts www.somewhere.com=1.2.3.4 into the Windows DNS cache
15. Windows hands Firefox that information
16. Firefox puts www.somewhere.com=1.2.3.4 into the Firefox DNS cache
17. Firefox sends the port 80 request to 1.2.3.4
18. And 1.2.3.4 returns the information to Firefox

Upon the *next* invocation of the same URL...
1. You type www.somewhere.com along with http (i.e., port 80)
2. Firefox checks the Firefox DNS cache, and finds 1.2.3.4
17. Firefox sends the port 80 request to 1.2.3.4
18. And 1.2.3.4 returns the information to Firefox

That's how I *think* it goes.
The Firefox cache skips steps 3 to 16 above.

However, the whole firefox cache thing is confusing.
So this is just a guess.

I throw it out there for someone who actually knows what they're talking
about to clarify.

[Jannah Jankowski]

VanguardLH wrote:

> Web-centric clients don't tell the OS how to do the DNS resolution.

That makes sense, but it doesn't jive with the tentative information that
we have which is that Firefox maintains its own DNS cache.

So I'm confused.

[VanguardLH]

Any client can maintain its own DNS cache or rely on the one in Windows.
Entries in the cache have already been resolved so the IP addresses are
known and no further DNS is involved thereafter. Having a local or
private cache means not having to spend time performing DNS resolution:
you keep (for awhile) what you already resolved before. Firefox also
uses its own private certificate store that can wreck havoc with some
anti-virus and video capture programs. They probably have their reasons
for using this private data (only known with THAT app).

You might want to set network.dnsCacheEntries to zero to see if that
makes a difference. You can go to about:cache to see those stats. You
could use Ctrl+F to search a list to see if the "rogue sites" are in the
memory or disk cache.

http://kb.mozillazine.org/Network.dnsCacheEntries

That says the default Firefox private DNS cache stores the last 20
resolutions. Well, mine is configured for 400. I've never modified
that setting plus it is shown non-bolded which means it specifies the
default value.

There is also an addon to use as a frontend GUI to about:cache
(https://addons.mozilla.org/en-US/firefox/addon/cacheviewer/). Maybe it
gives some more information than about:cache; however, it has its own
searchbox along with sorting.

[Mayayana]

| >> Web-centric clients don't tell the OS how to do the DNS resolution.
| >
| > That makes sense, but it doesn't jive with the tentative information
that
| > we have which is that Firefox maintains its own DNS cache.
|
| Any client can maintain its own DNS cache or rely on the one in Windows.

I think this is getting into red herring territory, while also
combining different issues.

Reading HOSTS:
FF can and should cache HOSTS, to avoid unnecessary
DNS lookups. If FF calls gethostbyname or getaddrinfo it
may be winsock checking HOSTS, but it's still in the service
of FF. FF could also make it's own DNS call, after getting
the preferred DNS serverIP from a call to GetNetworkParams.
Whether or not FF ever actually reads HOSTS directly, and
whether it makes DNS calls, is not really relevant.

FF DNS cache:
FF can and does also store a DNS cache of its own. That
should probably be disabled. In my experience it doesn't
seem to work properly and may block sites for a long period
after they've changed their IP address.

The topic at hand:
The original issue was that cloudfront URLs were in
the HOSTS file but those same URLs were being connected
to. Cloudfront is an Amazon server service. I suspect that
something like AcmeAV is calling home to
updates.AcmeAV.com, which is then being patched through
to cloudfront, to handle the traffic load. Since
updates.AcmeAV.com is not in the HOSTS file it's not
blocked. Since the cloudfront connection happens on
the other end there's no DNS lookup and thus no HOSTS
lookup.

All of this discussion has been about checking HOSTS
when HOSTS probably has nothing to do with it. The OP
needs to figure out what's calling home.

[Mayayana]

| You are wise beyond your years! :)

You know my age? Interesting. :)

| I didn't mention it, but I also found that bringing up a PDF in Firfox
| caused Adobe Acrobat Reader to run which caused that Akamai to show up so
| I had already put these lines in my HOSTS file
| 127.0.0.1 a184-25-56-91.deploy.static.akamaitechnologies.com # adobe
| 127.0.0.1 a23-45-86-146.deploy.static.akamaitechnologies.com # adobe
| 127.0.0.1 a23-5-219-228.deploy.static.akamaitechnologies.com # adobe
|

Ick! Adobe looking for updates and/or calling home
to report your file reading with every use. I can't
say I'm surprised, though I am appalled. Yet another
good reason to avoid Adobe products. (In case
malware vulnerabilities and stunning bloat were
not bad enough.)

[Christian Riechers]

I think it would have helped if you had mentioned the high CPU problem
in the first place, instead of that silly 'rogue' server statement.

See if this article helps.
https://support.mozilla.org/kb/firefox-uses-too-many-cpu-resources-how-fix

[Jannah Jankowski]

VanguardLH wrote:

> That says the default Firefox private DNS cache stores the last 20
> resolutions. Well, mine is configured for 400. I've never modified
> that setting plus it is shown non-bolded which means it specifies the
> default value.

I have wiped out both the Windows and Firefox DNS cache.

For example, on Windows, I ran:
c:\> ipconfig /displaydns
c:\> ipconfig /flushdns

And, on Firefox, I changed the network.dnsCacheEntries and a few other
related settings.

On Windows, using "Process Hacker", I turned off the service "Dhcp
client" (aka C:\WINDOWS\System32\svchost.exe -k netsvcs) and I changed the
Firefox DNS cache from 400 (which is the default) to 0.

I am testing it all now, as I made over 40 related changes in the past
day, and Firefox seems to have quieted down greatly with respect to both
CPU intensity consumed and rogue web sites visited without my knowledge -
but time will tell as sometimes small wins are fleeting.

[Mark12547]

In article <mailman.551.1467221218.18600.support-
fir...@lists.mozilla.org>, JannahJ...@JannahJankowski.com says...

> How can that possibly be that Firefox doesn't respect the hosts file?
>
>

I may be repeating myself. (It wouldn't be the first time.) (It wouldn't
be the first time.)

Firefox has a DNS cache in it. If it has the address of a server in its
DNS cache, it will not look elsewhere to for the server name, which
saves time compared to having to ask Windows every time for the
information.

So, to get Firefox to ask Windows, that DNS record has to be flushed out
of Firefox's DNS cache. One sure way I know to do this is to shut down
ALL Firefox windows, and then restart Firefox. (If any Firefox window is
open, Firefox will keep its DNS cache.) There are other ways, e.g.,
setting network.dnsCacheExpiration to 0, then setting it back to 60
(seconds); or using add-on DNS Flusher; though at least one earlier
version of Firefox had an issue with DNS not flushing the DNS records
for a host when there was a certificate for that host, at least with the
network.dnsCacheExpiration method. But shutting down all windows of
Firefox and then restarting Firefox should flush the Firefox DNS cache.

If Firefox needs to resolve a host name and it isn't in the Firefox DNS
cache Firefox will ask Windows to resolve the DNS entry.

When Windows is asked to resolve the DNS entry, Windows will check its
hosts file (in Windows 7 Home Premium (64-bit), this is hosts (no
extension) in C:\Windows\System32\drivers\etc). If hosts contains a
matching server name, the IP address on that line will be used to
populate the Windows DNS cache and to pass the information back to
Firefox. If Windows doesn't find the server name in the hosts file,
Windows checks the Windows DNS cache. If the record is in the Windows
DNS cache, Windows will inform Firefox of the pertinent information.

Otherwise (neither Firefox nor Windows has DNS record for the server),
Windows will ask the DNS server that it is configured to use (either one
of the servers one specified in the TCP setups in Windows, or from the
extended DHCP handshake with the router, which for us home users
typically ultimately leads to the ISP's DNS servers).

Once Windows has retrieved the DNS record(s) from the DNS server, the
Windows DNS cache gets the record(s), and the information is passed on
to Firefox. When Fiefox gets the DNS record(s) (Firefox doesn't care if
it came from the hosts file, Windows DNS cache, or from a DNS server, it
just cares that it has a DNS record), Firefox puts in its own DNS cache
as well as use the IP address to address the server.

Windows respects the "time to live" on the DNS record it had retrieved.
(Windows also limits the "time to live" to be no more than 86,400
seconds (1 day), so if a DNS record arrives with a TTL over 86400,
Windows will reduce to to be 86400. This number can be changed by a
registry entry.) Once the "Time To Live" has ticked down to zero, the
DNS record is deleted from the Windows DNS Cache.

DNS records can also be flushed out of the Windows DNS cache by using
the cmd window command,

ipconfig /flushdns

(I don't know if the user needs administrative privileges for the
command to work, but as an administrator but running the command with
just normal privileges it flushed the DNS cache.)

Restarting Windows will also clear the Windows DNS cache.


Now there is a possibility of Windows _not_ using the hosts file: in
googling around I came across someone who had edited his hosts file and
saved it to another place, deleted the original hosts file, and copied
the edited file to its home. Problem is that the file lost its original
privileges. Typically this file should have the security of "SYSTEM" and
"Administrators" with Full control, modify, Read & execute, Read, Write
(but not Special permissions), and then "Users" (everyone else) with
Read & execute, read. If the task that reads the hosts file can't read
it, then obviously the hosts file entries won't be used.

Again, these "Security" settings are as I see them on my Windows 7 Home
Premium (64-bit) system, and may be different on another system.