double fault in NOD32 stops my browsing

[dcouzin 0]

NOD32 v.14.0.22.0 running under Windows 10 Pro v.1809.

A certain website has an untrusted security certificate.  So NOD32 throws up an Alert!  "Website certificate revoked". 
Unfortunately the alert offers no bypass.  I should be able to choose to access the website at my risk, as other antivirus softwares allow.  (I happen to know that the website does nothing strange when I access it by choice using another computer without NOD32.)
So I pause protection in NOD32.  NOD32 loudly warns me that I'm exposed to risk, etc.
But when I try to access that same website, the same NOD32 Alert!  "Website certificate revoked" appears.  

Thus a double fault in NOD32.  First, lack of a bypass when it alerts for a bad security certificate.  Second, incomplete pausing of protection.

Are there workarounds?  

DC

[Marcos 5,234]

Unfortunately you didn't mention the website you visited when revoked cert. was reported. However, it's unlikely to be a false positive.

In case of revoked certificates it is a security risk to visit the website since there must have been a good reason for certificate revocation. If the issue had been fixed, an owner of the website would have replaced the cert. with a valid one.

It's like complaining that ESET doesn't allow you to run a crack because you think it's safe but in fact it would be a malicious trojan disguised as crack.

[dcouzin 0]

@Marcos, You have addressed the first fault: that NOD32 allows no bypass to reach a bad certificate website.  Yes, I am complaining that NOD32 doesn't "allow" me to take calculated risks.  I bought protection, not a minder.

The second fault is that when NOD32 says it is pausing protection (for 10 minutes, etc.) it does not pause protection against bad certificates.  It still "protects" me from that website with the same alert.

I now find that I can stop the protection by entering NOD32's advanced setup and disabling SSL/TSL protocol filtering.  I must enable it after visiting the website.  Cumbersome, but a workaround.

Incidentally the website is that of M.K. Bhadrakumar, a retired diplomat and now political commentator, maybe not for kiddies.

DC

[itman 1,741]

2 hours ago, dcouzin said:

Incidentally the website is that of M.K. Bhadrakumar, a retired diplomat and now political commentator, maybe not for kiddies.

Here's the URL Eset is blocking: https://indianpunchline.com/

Rightfully so. Not only is the site cert. revoked but the intermediate cert. to boot. QUALS SSL cert. analysis here: https://www.ssllabs.com/ssltest/analyze.html?d=indianpunchline.com

[dcouzin 0]

The state of the certificate for indianpunchline.com worsened since I described my workaround yesterday.  Now, even without NOD32's interference, no browser can open that page.

So, was NOD32 smarter than the browsers yesterday, when it wouldn't, but they would let me choose to see that page?  Or was NOD32 just stricter? 

DC

Edited February 14, 2021 by dcouzin
grammar

[itman 1,741]

1 hour ago, dcouzin said:

So, was NOD32 smarter than the browsers yesterday, when it wouldn't, but they would let me choose to see that page?  Or was NOD32 just stricter? 

Depends on which browser you are using.

There are two ways certificates are checked.

1. Certificate Revocation List; i.e. CRL. View this as a static method in that the browser in essence maintains a blacklist of revoked certificates. This list is periodically updated by the browser. Chrome uses this method by default.

2. OCSP responder servers; i.e. OCSP. View this as a dynamic method. These servers are queried whenever a web site certificate needs to be validated. FireFox uses this method by default.

It is somewhat obvious the OCSP sampling as it is referred to is superior to CRL method. CRL update frequency varies in duration but can be hours. OCSP servers are constantly being updated by certificate authorities; usually in minutes.

Eset due to its SSL/TLS protocol scanning must duplicate certificate validations done by browsers due to its man-in-the-middle inspection of encrypted HTTPS network traffic. Eset uses OCSP to accomplish this.

[gemaynard 0]

I am attempting to reach the Consumer Reports website (https://www.consumerreports.org/) on my desktop computer and the message “Website certificate revoked” is returned.  When I attempt access on my laptop (both are protected by ESET) the website comes up successfully.  I have deleted the CRL and OCSP Cache on the desktop to no avail.  In this situation the problem seems to be with ESET not the website.  What’s going on?

[Marcos 5,234]

2 hours ago, gemaynard said:

I am attempting to reach the Consumer Reports website (https://www.consumerreports.org/) on my desktop computer and the message “Website certificate revoked” is returned. 

We've seen several such reports recently when a Windows API function returned a critical error X509CSF_PartialChain which was caused by a missing root certificate.

Please carry on as follows:
- enable advanced protocol filtering logging in the advanced setup -> tools -> diagnostics
- reproduce the warning
- disable logging
- collect logs with ESET Log Collector and upload the generated archive here.

[itman 1,741]

3 hours ago, gemaynard said:

I am attempting to reach the Consumer Reports website (https://www.consumerreports.org/) on my desktop computer and the message “Website certificate revoked” is returned

No problem here on my Win 10 20H2 desktop using FireFox.

Is the revoked cert. alert from the browser or from Eset? Which browser are you using when the alert appears? Did you use the same browser on the laptop where no issues exist?

Edited February 15, 2021 by itman

[gemaynard 0]

2 hours ago, itman said:

No problem here on my Win 10 20H2 desktop using FireFox.

Is the revoked cert. alert from the browser or from Eset? Which browser are you using when the alert appears? Did you use the same browser on the laptop where no issues exist?

It's from Eset using Chrome.  Same browser on my laptop.

[gemaynard 0]

1 minute ago, gemaynard said:

 

 

 

eis_logs.zip 0 B · 0 downloads

 

eis_logs.zip

[dcouzin 0]

On 2/14/2021 at 9:58 PM, itman said:

Depends on which browser you are using.

There are two ways certificates are checked.

...

indianpunchline.com's certificate status is moving target.  As of yesterday, by disabling NOD32's SSL/TSL protocol filtering I could address the site in Chrome where I could then get around that browser's NET::ERR_CERT_REVOKED by simply typing "thisisunsafe".  As of today, with NOD32's SSL/TSL protocol filtering disabled, Chrome lets me visit the site immediately, without the passphrase.  Yet Firefox doesn't let me visit the site, and NOD32, with SSL/TSL protocol filtering reenabled, certainly doesn't.  Google programmers aren't dunderheads.  The site is safe enough for cautious use.  Chrome's addressbar shows the connection as "Not secure".  Why isn't this sufficient?  Since the goal of browsing is information, not the feeling of absolute safety, why can't NOD32 include some grown-up bypasses?

DC

[itman 1,741]

57 minutes ago, dcouzin said:

Since the goal of browsing is information, not the feeling of absolute safety, why can't NOD32 include some grown-up bypasses?

in regards to your use of Chrome, it does. Exclude the web site's certificate from Eset's SSL/TLS protocol scanning. No need to totally disable SSL/TLS protocol scanning.

Edited February 16, 2021 by itman

[dcouzin 0]

4 hours ago, itman said:

in regards to your use of Chrome, it does. Exclude the web site's certificate from Eset's SSL/TLS protocol scanning. No need to totally disable SSL/TLS protocol scanning.

Based on your suggestion, I put the bad certificate into the "List of known certificates".  In "Access action" I ticked "Allow (even if untrusted)".  In "Scan action" I ticked "Ignore".  Using Chrome then, NOD32 still blocked me from the site.  What did I do wrong?

[itman 1,741]

3 minutes ago, dcouzin said:

Based on your suggestion, I put the bad certificate into the "List of known certificates".  In "Access action" I ticked "Allow (even if untrusted)".  In "Scan action" I ticked "Ignore".  Using Chrome then, NOD32 still blocked me from the site.  What did I do wrong?

Open up Eset GUI and verify the exclusion you created actually exists. You may not have saved it correctly. Remember to always mouse click on "OK" button and any subsequent one that appears when exiting any Eset GUI section. Also verify that you selected the correct certificate to exclude

Also per the QUALS link I posted previously, it is not just the web site cert. that is bad. The Intermediate cert. it is chained to is also bad. This is most likely why Eset is still throwing a cert. alert for the web site:

[dcouzin 0]

1 hour ago, itman said:

Open up Eset GUI and verify the exclusion you created actually exists. You may not have saved it correctly. Remember to always mouse click on "OK" button and any subsequent one that appears when exiting any Eset GUI section. Also verify that you selected the correct certificate to exclude.

The exclusion appears to have been done correctly -- see screenshot -- but NOD32 does not allow access.  It doesn't cede to Chrome (which today allows access) as NOD32 does do when SSL/TLS protocol filtering is totally disabled.

It's little trouble to disable the filtering, use Chrome to visit the site, and then to reenable the filtering.  I'll keep watching how Chrome allows access vs. how NOD32 does.  Presently Chrome does and Firefox doesn't, and even when Chrome doesn't there's "thisisunsafe".

How well does the certificate system assure browsing safety?  And how often do perfectly safe sites have bad certs, even bad intermediate certs? 

DC 

[itman 1,741]

2 minutes ago, dcouzin said:

And how often do perfectly safe sites have bad certs, even bad intermediate certs? 

Any web site with a revoked certificate in any form should be avoided period.

[Marcos 5,234]

You should contact the owner of the website, inform them about the issue and suggest replacing the certificate with a valid one. That is the only actual solution for websites utilizing revoked certificates. Disabling protection just to allow access would be playing with fire.