Jump to content

Recommended Posts

3 minutes ago, BALTAGY said:

Adguard only block Ads

Irrelevant since it has to scan all HTTPS traffic first to determine if ads exist.

You have to pick one HTTPS scanner here; Eset's or Adguard's. If you pick Adguard's, they are responsible for monitoring all HTTPS traffic for malicious activity.

Or, you need to configure Adguard along the lines of how uBlock Origin works. That is HTTPS web pages are scanned after being decyrpted by FireFox but prior to being rendered on the desktop.

Edited by itman
Link to post
Share on other sites
  • Replies 129
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

I did test v13.0 and v12 all of them have same problem in a clean system only ESET and Firefox But once i installed chrome it works fine I think ESET need to check it, maybe a module update is n

The issue is fixed in the Internet protection module version 1396; currently it is available on pre-release update servers.

Posted Images

  • ESET Insiders

Snap1.jpg

Did test in a clean system without Adguard and ESET don't show in Firefox

Link to post
Share on other sites
  • ESET Insiders
Posted (edited)

Here's the logs after downloading eicarcom2.zip and while ESET didn't add it self into Firefox

It's a clean system only ESET + Firefox + IDM installed

eis_logs.zip

Update:
Just installed chrome in this clean system and everything works fine

Update2:
wilderssecurity.com/ shows Adguard certificate in chrome but ESET still block eicarcom2.zip

Edited by BALTAGY
Link to post
Share on other sites
1 hour ago, BALTAGY said:

Did test in a clean system without Adguard and ESET don't show in Firefox

Then something is wrong with how Firefox is configured. In the latest versions of Firefox; i.e. 74 and 75 it uses the Windows root CA certificate store by default. In other words, Eset's root certificate is no longer required to be installed in FireFox's Authorities certificate store.

Another problem that has surfaced with some Eset users is they have multiple Eset root certificates in the Windows root CA certificate store. If that applies to you, delete all except the latest Eset certificate there and see if that resolves the issue in FireFox.

Edited by itman
Link to post
Share on other sites
  • ESET Insiders
Just now, itman said:

Then something is wrong with how FireFox is configured. In the latest version of Firefox, it uses the Window root CA certificate store by default. In other words, Eset's root certificate is no longer required to be installed in FireFox's Authorities certificate store.

I did test v13.0 and v12 all of them have same problem in a clean system only ESET and Firefox

But once i installed chrome it works fine

I think ESET need to check it, maybe a module update is needed

Link to post
Share on other sites
  • Administrators

I'll wait for ELC logs with advanced protocol filtering logs from issue reproduction included. Please leave Adguard uninstalled while troubleshooting the issue.

Link to post
Share on other sites
  • ESET Staff
13 hours ago, hardwired said:

This is what happens to me, Firefox isn't filtering at all on a new install/new Windows install. Other browsers did but not Firefox.

This is very likely the issue we are already aware of. It manifests itself only on a fresh install of our product.
It will be addressed by the Internet protection module update.

Link to post
Share on other sites

I had a similar issue on a clean installation of ESET. What worked for me is that I deleted the ESET certificate from the trusted root certificate of Windows then restarted the PC.

Link to post
Share on other sites

As far as use of the full installed Adguard product and its use of SSL/TLS protocol scanning, my previous comments still stand.

Do not use two security products that are perform like browser scanning activities at the same time. It amounts to an "invitation to disaster" scenario that could lead to:

1. borked browser HTTPS web page rendering.

2. Conflicts between both products SSL/TLS security scanning activities resulting in possible loss in either or both products ability to scan for malware activities.

If you must use Adguard with Eset, use its browser add-on/extension option or add its filtering lists to a product such as uBlock Origin add-on.

As far as Adguards HTTPS issues, refer to this: https://kb.adguard.com/en/general/https-filtering/https-filtering-known-issues

Finally if you insist on using Adguard installed version with Eset, make sure you disable Adguard's use of Windows Filtering Platform (WFP) as shown here: https://kb.adguard.com/en/windows/solving-problems/wfp-driver . Of note is Eset's SSL/TLS protocol filtering uses WFP. I assume disabling WFP use forces Adguard to install a network mini-port filter driver for your network adapter. It then scans HTTPS traffic using that driver. Or preferably, disable Adguard's HTTPS scanning in this same configuration settings section.

Edited by itman
Link to post
Share on other sites
On 4/24/2020 at 1:10 PM, Posolsvetla said:

This is very likely the issue we are already aware of. It manifests itself only on a fresh install of our product.
It will be addressed by the Internet protection module update.

Can you tell when this is going to be fixed? I'll reinstalled my WIndows after the release of Windows 10 2004 on May 12 so I hope it to be fixed before that.

Link to post
Share on other sites
3 hours ago, SeriousHoax said:

Can you tell when this is going to be fixed? I'll reinstalled my WIndows after the release of Windows 10 2004 on May 12 so I hope it to be fixed before that.

I installed both FireFox and Eset on a clean Win 10 x(64) 1909 installation and have zip issues in regards to any FireFox certificate issues. I did however install Eset first, prior to installing FireFox.

Link to post
Share on other sites
43 minutes ago, itman said:

I installed both FireFox and Eset on a clean Win 10 x(64) 1909 installation and have zip issues in regards to any FireFox certificate issues. I did however install Eset first, prior to installing FireFox.

How long ago did you do it?

Link to post
Share on other sites
Just now, SeriousHoax said:

How long ago did you do it?

A couple of months ago. The Eset version was the 13.0.24.

Link to post
Share on other sites
21 hours ago, itman said:

A couple of months ago. The Eset version was the 13.0.24.

This is why you didn't have this issue. This is a recent problem with new installation. Current Internet protection module is the faulty one I think. The one before that was fine.

Link to post
Share on other sites
  • Administrators

At this point we cannot tell when a new module could be available. I'd count with ETA 1-2 weeks.

Link to post
Share on other sites
16 minutes ago, SeriousHoax said:

Current Internet protection module is the faulty one I think.

You will receive the new module if you switch to pre-release updates.

Link to post
Share on other sites
3 hours ago, itman said:

You will receive the new module if you switch to pre-release updates.

I'm still seeing the issue even with the pre release version of IPM 1395. SSL version eicar2 can still be downloaded without being detected.

Link to post
Share on other sites
  • Administrators
13 minutes ago, NewbyUser said:

I'm still seeing the issue even with the pre release version of IPM 1395. SSL version eicar2 can still be downloaded without being detected.

This is expected as I wrote today:

At this point we cannot tell when a new module could be available. I'd count with ETA 1-2 weeks.

Link to post
Share on other sites
On 4/24/2020 at 3:10 AM, Posolsvetla said:

This is very likely the issue we are already aware of. It manifests itself only on a fresh install of our product.
It will be addressed by the Internet protection module update.

I'm a bit confused here. I did a fresh install of both Win 10 x(64) 1909, EIS ver. 13.0.24 since upgraded to 13.1.21, and Firefox on 2/10/2020.

I am having no issues with EIS detecting eicarcom2.zip in either HTTP or HTTPS mode using Internet Protection Module 1395.

Is this something related to a fresh install of ver. 13.1.16 or 21 perhaps?

Edited by itman
Link to post
Share on other sites
12 minutes ago, itman said:

I'm a bit confused here. I did a fresh install of both Win 10 x(64) 1909, EIS ver. 13.0.24 since upgraded to 13.1.21, and Firefox on 2/10/2020.

I am having no issues with EIS detecting eicarcom2.zip in either HTTP or HTTPS mode using Internet Protection Module 1395.

Is this something related to a fresh install of ver. 13.1.16 or 21 perhaps?

It's possible it's related to fresh installs. I'm on a trial which I started roughly two weeks ago, 18 days ago to be precise. 13.1.21. Firefox is the only browser experiencing the issue.  Are you using the latest FF? 75?

Edited by NewbyUser
Additional info
Link to post
Share on other sites

Appears the Eset "bugged" version is 13.1.16 since that is the latest ver. available for download.

Well, this ver. should shortly after install, update to ver. 13.1.21; the version I am running w/o this issue. So I still don't see where the problem is.

And yes, I am running the latest ver. 75 of FireFox.

Link to post
Share on other sites

While I'm not a programmer, from my perspective with Eset's modular approach, it shouldn't technically "matter" what version was initially installed. That being said things don't always work as planned or designed lol. It also seems it may not be an "Eset" problem, all other browsers work as expected so perhaps it's a Mozilla issue. Could also be related to archive scanning depth. Only the double zip https eicar doesnt seem to be scanned, the single zip gets detected.  

Link to post
Share on other sites

This issue has nothing directly to do with FireFox or detection of test malware in a 2x zip file.

I just ran the comprehensive archive test at the Fortinet "Test Your Metal" web site: http://metal.fortiguard.com/ . This will test detection in up to 10x zipped files plus every other archiving method "known to compression mankind." Eset scored exactly the same as when I tested it previously scoring 17/18 - an Excellent rating. The only thing it missed was the password protected archive.

Of note however is all downloads were HTTP.

Eset_Fotinet.thumb.png.bad2615e492580b17f2ab83d1afd48ee.png

Edited by itman
Link to post
Share on other sites

SInce I'm not programming expert,lol, what does it have to do with? If Eset works everywhere else, why just FF? It would seem to me EIS detects everything in the Fortinet test as well, so what is different other than FF?

 

Same result here btw with fortiguard metal test 17/18

Edited by NewbyUser
Additional Info
Link to post
Share on other sites

I still state that the issue here is most likely multiple Eset root certificates in the Windows root CA certificate store. All but the most recent certificate should be removed from there. 

As far as Eset's root certificate presence in FireFox's Authorities certificate store, it really shouldn't matter since FireFox is now configured to defer to the  Windows root CA certificate store.

Link to post
Share on other sites
Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    No registered users viewing this page.


×
×
  • Create New...