SeriousHoax
-
Posts
361 -
Joined
-
Last visited
-
Days Won
10
Posts posted by SeriousHoax
-
-
10 minutes ago, LesRMed said:
It's not there for me.
It's right there. Click on the Theme button.
-
13 minutes ago, itman said:
This was discussed in another thread a while back.
Eset SSL/TLS protocol scanning busts it. This can be verified using Firefox and performing this test: https://www.cloudflare.com/ssl/encrypted-sni/ .
Yeah, that thread is locked so couldn't reply there and started this new thread.
Since Avast has enabled support for ECH, it means ESET should be able to do so also if they want.
-
I was wondering if ESET have any plan to add support for "Encrypted Client Hello" in the near future?
In the latest version of Avast which was released at the start of this month, they have added support for it. This is from their changelog and I have also tested and verified it myself in a VM.
QuoteEncrypted Client Hello – We’ve enhanced Web Shield with new support standards, making users’ connections safer. HTTPS connections leak information in the TLS ClientHello to the network, notably the hostname of the website being accessed. When supported by the website, ECH allows encrypting this message with a key provided by the server.
Currently ESET and all the AV products (except Avast) that decrypt HTTPS traffic to scan breaks Encrypted Client Hello. It would be nice if ESET similar to Avast start supporting this new privacy standard.
Sites to test Encrypted Client Hello:
-
10 hours ago, itman said:
If you tested on Eset ver. 17.1.9.0, disable HTTP/3 scanning. AdGuard uses QUIC: https://adguard-dns.io/en/blog/dns-over-quic-official-standard.html .
Haven't tested with the new version yet. But when I tested, I wasn't using Adguard's DNS Over QUIC. It was Quad9 DoH.
-
I can confirm that using AdGuard for Windows (didn't test their VPN) nullifies ESET's ability to block malicious websites no matter what settings are changed in AdGuard. Once AdGuard is on, ESET is gone.
-
41 minutes ago, itman said:
Another interesting observation.
Excluding the browser DoH factor, the TLD is not detected by Eset blacklist used by Sucuri: https://sitecheck.sucuri.net/results/crackingpatching.com .
Could it be that since the site is using a trusted cert., scanning of it is being ignored?
Only decryption of TLS is ignored for sites using trusted certificate, but blacklisted hosts are/should still be blocked by TLD.
-
Web protection not working properly, self-defense somewhat bypassed. Not a good week for ESET 🤔
An ESET official should privately contact Andy Ful on this matter to learn the method he used to disable ESET. He'll only share the details privately to an ESET official if they reach out to him asking the details and possibly take measure so that it doesn't happen again. As Andy Ful suggested, the preventive measure for this should not be a mere signature-based solution.
-
ESET officials need to have a look at this matter and find the solution ASAP.
-
56 minutes ago, itman said:
No problem in Firefox on this regard w/DoH disabled. When I select reload icon, the site is blocked again.
Same here. But on Chrome and Edge it's not behaving correctly even in default settings. So, it's a far more serious issue as more people use Chrome and Edge.
-
1 hour ago, itman said:
I would say DoH should be disabled on all browsers till Eset fixes the problem.
The above issue I showed in the GIF above is happening even when DoH is disabled in Edge. So, the problem is probably worse than we thought.
-
39 minutes ago, itman said:
Another observation.
With DoH disabled in Firefox, attempted access to https://crackingpatching.com/2017/03/avast-pro-antivirus-internet-security-premier-17-2-3419-0-keys.html results in blocking at the TLD as should be;
Time;URL;Status;Detection;Application;User;IP address;Hash
3/10/2024 10:09:53 AM;https://crackingpatching.com;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxxxxx;2606:4700:3034::6815:2b2e;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCBCompatibility issue with DoH.
Have a look at this weird behavior on Edge:
-
12 hours ago, itman said:
Did more testing with the TLD https://crackingpatching.com/
The problem is with DoH enabled in Firefox.
With DoH disabled, Eset will alert and block access every time. When any of the DoH settings are enabled, Eset might block it once after setting change but not thereafter. Doesn't matter what DoH option is selected or DoH provider selected.
I am keeping DoH disabled until this is resolved. Glad you found this problem.
Well, now it's not even working for me in Chromium browsers. In Edge, the first time it blocks and then if I reload the page, it isn't blocked. On my testing Chrome Portable browser in another drive, web protection is not working most of the time even in default settings without DoH. Something is not right. It needs to be looked at fixed soon.
-
2 hours ago, itman said:
Found the problem, I believe.
Eset Filtered Web Site log shows it blocked access;
Time;URL;Status;Detection;Application;User;IP address;Hash
3/9/2024 11:43:27 AM;https://crackingpatching.com;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxx;104.21.43.46;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCBTime;URL;Status;Detection;Application;User;IP address;Hash
3/9/2024 11:43:28 AM;https://accounts.google.com/o/oauth2/postmessageRelay?parent=https://crackingpatching.com&jsh=m;/_/scs/abc-static/_/js/k=gapi.lb.en.8uXxGUoumbY.O/d=1/rs=AHpOoo96qx3mL4tzGUOa-0q0udyPRqEAoA/m=__features__;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxx;2607:f8b0:4023:140d::54;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCBBut web site access is not blocked.
Notice the redirect to Google. Looks like someone has figured out how to bypass Eset Web Filtering on Firefox.
Very interesting🤔
I have two blocks. But mine is a twitter redirect not google.
QuoteTime;URL;Status;Detection;Application;User;IP address;Hash
10-Mar-24 12:51:58 AM;https://platform.twitter.com/widgets/widget_iframe.2f70fb173b9000da126c79afe2098f02.html?origin=https://crackingpatching.com;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;****;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCBTime;URL;Status;Detection;Application;User;IP address;Hash
10-Mar-24 12:51:56 AM;https://crackingpatching.com;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;****;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCB -
48 minutes ago, itman said:
I have Firefox DNS over HTTPS set to Default level w/CloudFlare as DNS provider. I am also using CloudFlare as my Win 10 DNS provider.
When I try to access the malicious URL in question, I can access the web site and even download the malicious crack.
Same here.
I am wondering if this is a FireFox problem since Eset blocks the URL on Chrome?
-EDIT-
I set Firefox DNS over HTTPS to Increased Protection level using CloudFlare as DNS provider. Eset alert now displayed on attempted web page access. However, w/ DNS over HTTPS set to Maximum protection, no web site blocking occurs. I would say this is indeed a Firefox bug.
I don't know whose bug it is but for me the example site is not blocked even in Increased protection mode. I tested two other security products, but they don't have this issue on Firefox.
-
When Firefox is set to use maximum or increased protection in DNS over HTTPS settings then ESET does not block blacklisted websites.
For example, here's a VT link of a fake crack program website already in ESET's blacklist: https://www.virustotal.com/gui/url/5583ee6d3fa820c9c851f37746d9b5a896da37bc7ce93329d6dcc02e4b7d9daa/detection
But with above DNS settings, it is not blocked:
When I set Firefox's DNS over HTTPS settings to Off, ESET blocks it.
There is no such issue on Chromium browsers:
Edit: In case it has some sort of connection, ESET's web protection also doesn't work when used with AdGuard for Windows. Changing any network driver or other related settings has no impact. To be clear, in the explained scenario in my main post I'm not using AdGuard for Windows.
-
2 hours ago, itman said:
Not possible.
Brave uses extensions from the Chrome Store. The only Eset extension available there is for Eset Password Manager.
The help link you gave above has the link to the extension in Chrome store:
https://chromewebstore.google.com/detail/eset-browser-privacy-secu/oombnmpbbhbakfpfgdflaajkhicgfaam
-
35 minutes ago, itman said:
It does not support Brave;
https://help.eset.com/essp/17/en-US/banking_and_payment_protection.html?idh_config_bps.html
Not even if I manually install it?
-
Did you really see ESET's certificate in Brave? I don't think ESET officially supports Brave and also based on your screenshot ESET is not decrypting Brave's traffic as expected. You have to manually add the Brave's exe to Application scan rules in SSL/TLS settings and set it to Scan.
Also, I'm curious to know if "ESET Browser Privacy & Security" extension with Secure Search works in Brave. Do you know @Marcos?
-
Do two more scans with Norton Power Eraser and Kaspersky Virus Removal Tool. These two are the best second opinion scanners.
-
On 11/9/2023 at 8:37 PM, constexpr said:
So far we have evidence of these imcompatibilities https://support.eset.com/en/kb6063-eset-banking-payment-protectioncommon-errors
Thanks for this link, but I see that it only mentions some security software that have keylogger protection.
I'm talking about incompatibility with apps like this one: https://www.omicronlab.com/avro-keyboard.html which is used by a lot of people in my region. ESET is not compatible with this app. An ESET staff on this forum told me that ESET will work to make it compatible but that was a while ago. Nothing has changed so far. I think ESET should add apps like this to the incompatible list.
-
Since keyboard protection became default, I think ESET should have a support/help page where all the software that is known to be incompatible with default ESET settings should be listed.
-
FYI, I have tested some other top products on the site and none of them detected anything. ESET's detection is correct for sure as confirmed by Marcos. This once again proves (to me at least) that ESET is the best at detecting malicious scripts on websites. Many times, ESET is the only one/the first one to detect such things.
-
8 hours ago, itman said:
Still a no-go. All three tests show ECH not enabled.
If I disable Eset HTTPS scanning, all three tests show ECH enabled.
-EDIT- According to Mozilla, ECH in Firefox 118+ is based on existing DoH; DNS over HTTPS, processing. So assume Eset HTTPS scanning is also busting that.
Yeah, all AV products with SSL scanning function bust ECH.
-
46 minutes ago, itman said:
I will also add that I am no fan of anything Cloudfare based; especially their DNS servers. DNS security tests I have run show my ISP(AT&T) DNS servers are far superior to Cloudfare's.
As such, I could care less about this Firefox feature.
It doesn't have to be Cloudflare DNS. Any DNS that supports one of the encrypted DNS protocols like DoH, DoT, DoQ works. For example, I use my custom NextDNS.
BTW, for Firefox one may have to manually set "network.dns.echconfig.enabled" to True. There are methods to enable in Chromium browsers also.
Browser Protection Allowlist Doesn't Work
in ESET Internet Security & ESET Smart Security Premium
Posted · Edited by SeriousHoax
Added more info
I put a keyboard app (that I often use to write letters in my local language) in the Browser protection allowlist but still it randomizes everything I type via that app. Shouldn't putting the app into whitelist mean ESET would allow the app to work normally?
The keyboard app: https://www.omicronlab.com/avro-keyboard-download.html
I'm using the portable version, but the result is the same with the installed version also.
So how do I solve this without turning off Keyboard protection?
Here I only pressed one button on the keyboard multiple times, but ESET is still randomizing typed characters: