Protocol filtering refuses to work on Firefox

[alpe 0]

It doesn't work on firefox. All pages go through unfiltered, ignored.
I already tried using firefox portable (with new profile), resetting configs, clean install (including using the eset uninstaller), remove every folder that has eset or nod32 in name and every registry entry related to it too. Already tried to add firefox to the protocol filtering rules with "scan" action. Nothing.
But if I rename firefox.exe to anything else (like firefox2.exe) the protocol filtering works. That doesn't make sense.
Any help?

Edited September 3, 2018 by alpe

[Marcos 5,070]

Please let us know what ESET product and version you use so that we can move the topic to the appropriate product forum.

Also please provide steps-by-step instructions how to reproduce it, including the exact version of Firefox that you have installed and information how you performed the test. With portable versions of Firefox , SSL/TLS filtering won't work unless you manually import the ESET root certificate to the trusted root CA certificate store.

[alpe 0]

Eset Internet Security 11.2.49.0.
I tried all firefox versions from 56 to 63.0a1.
On portable, the pages just load normally even without the root certificate, bypassing nod32 protocol filtering completelly. If I rename the exe to anything else, then it works, displaying the error of untrust issuer.

I'm not sure how to provide steps.
But I tried making a clean eset and firefox install, making sure all folders/registry entries of them were removed betweeen installs.
What is weird is that it don't work only if the exe name is "firefox.exe". Like if there was a rule marked to "ignore" it. But there is no such rule, as it's a clean install and I even tried adding a rule to force "scan".
Already tried changing SSL filtering mode to "policy". The window asking what to do never shows up, unless I rename the exe. It's like "firefox.exe" specifically is completelly invisible to the protocol filtering.

Edited September 3, 2018 by alpe

[Marcos 5,070]

Do you mean that if you download the eicar test file from http://www.eicar.org/download/eicar_com.zip it is not detected by web protection?

[alpe 0]

On http it is, on https no. Only after the download is made that it removes it.

Edited September 3, 2018 by alpe

[itman 1,659]

Verify in whatever version of FireFox you are using that Eset's SSL Filter CA certificate is installed in FireFox's root CA store. If Eset's certificate is not installed, Eset will not be able to perform SSL protocol scanning.

 

[alpe 0]

It is. And even if it was not, it should display the unknown issuer warning, which doesn't happen.
It happens if I rename the exe.

[Marcos 5,070]

Are you able to reproduce it on another machine, e.g. on a VM? For now do not perform the tests using a portable Firefox.

[alpe 0]

Haven't tried. Probably no. It's probably something on my current installation. What is weird is that it persist after a clean install of both nod32 and firefox (with registry and installation folders cleanup) and only when the exe is name firefox.exe.
Guess I'll just have to use it with the exe renamed.

Edit: I'm using normal Firefox. I only tried portable to see if it would work on it.

Edited September 3, 2018 by alpe

[alpe 0]

Creating a new windows user don't solve it either.

Edited September 3, 2018 by alpe

[itman 1,659]

Try this.

Open up Eset's GUI and then open up Eset's SSL filtered applications as shown in the below screen shot. Verify if the correct path is shown there for where FireFox is located. Also verify that it is set to "Auto". If Firefox is not listed; or the path for it is incorrect; or if multiple entries exist there for it, do the following.

1. If FireFox is not listed, manual add it specifying it full path location and set it to "Auto".

2. For anything else, delete anything listed there for FireFox. Then manual add it specifying it full path location and set it to "Auto".

Now see if Eset is scanning HTTPS web sites in FireFox. 

[alpe 0]

Tried too. Nothing. Setting it to "scan" too, no change. :/
Really weird, it's like there's an invisble rule set to "ignore" for "firefox.exe" (regardless of path) that takes precedence over this.

[itman 1,659]

Did you try this?

Quote

ESET and NOD32 security products

If you use an ESET security product such as NOD32 Antivirus or ESET Internet Security, turning off one of the following settings and then turning it back on may help eliminate the error.

• Enable application protocol content filtering
• Enable SSL/TLS protocol filtering

For detailed instructions, see this AskVG.com article.

https://support.mozilla.org/en-US/kb/secure-connection-failed-error-message#w_eset-and-nod32-security-products

Edited September 3, 2018 by itman

[alpe 0]

Yes.

[Peter Randziak 1,130]

Hello @alpe, 

do you have master password (password to protect your Firefox password store) set in Firefox?

P.R.

[alpe 0]

No.

[Marcos 5,070]

Maybe shooting a video showing the process of replication from the download and installation of Firefox to issue reproduction could shed more light. Also gather ELC logs when Firefox is installed and running and post the generated archive here.

[alpe 0]

Here.
This is on a new windows user (new firefox profile, by extension), that I created on my pc just to run the test.
Some explanations:

1) At 0:29 I leaved "Exclude communications with trusted domains" unmarked, so that everything is checked. Same reason it is in policy mode.

2) 0:34 the warning that dropbox display is because SSL filtering is in policy mode, so everything is filtered. Dropbox checks the certificate issuer, so it should be marked as "ignore" which it isn't on this test.

3) At 01:46 and 02:36 pages load from cache first, then I press CTRL-F5 to update.

I forgot to do this on the recording, but after it I checked and firefox was on the list of ssl/tls filtered applications. I marked it as "scan" and rerun the test with the same results.

eis_logs.zip

recording.zip

Edited September 6, 2018 by alpe

[alpe 0]

I created a rule on SSL filtering for "*/firefox.exe" and marked as scan, and it worked. I removed it, and it keeps working.
I'm almost certain I already tried this before, but now it worked.
I possibly created a rule for "*/firefox.exe" a long time ago and marked as ignore for test purposes, and somehow it turned invisible, and creating this rule again with other value overwrote it.