Jump to content

itman

Most Valued Members
  • Content Count

    8,040
  • Joined

  • Last visited

  • Days Won

    195

Everything posted by itman

  1. Below is a screen shot of what is the problem in IE11. The website certificate chain validation appears to be borked. Also I have excluded the web site from Eset SSL/TLS protocol scanning. Otherwise, you would see Eset's root certificate at the top of the certificate chain. Therefore and again, Eset SSL/TLS protocol scanning is not the source of this problem. Note that the top of the chain root certificate shows a Sertigo CA root certificate. However in reality, it is a UserTrust CA root certificate. It really appears to me that IE is not correctly processing the additional download
  2. I will also state this. Eset should perform a detailed analysis on what this web site: https://tvs.bce.lt/ is doing. BTW - the web site provider is located in Lithuania which "speaks volumes" as to its status. As a test, I did a global URL Allow List exclusion on it. When accessing the web site in IE11, I proceeded to receive 95 connection alerts; most related to AngularJS scripts running on the site's web server. Then the alerts stopped with a blank web page being rendered. This implies that something within IE11 prevented the web page from rendering. Only a Process Monitor session will
  3. I really don't have an answer for that. As I posted on my Win 10 installation, the same non-web page rendering occurred both in IE11 and Edge with Eset Protocol Filtering disabled. So as far as Win 10 operation goes, this issue is not Eset related. However, I am using Eset Internet Security running on Win 10 Home and you are using Eset Endpoint Security running on a Win 7 version. Note that Win 7 is an unsupported OS and I don't know the what updates from it have been applied. It may very well be that IE11; or is it IE10 on your device, is allowing SHA-1 root certificates verificati
  4. This thread ended with the issue being related to Eset LiveGrid connectivity. Check your Eset Event log for any entries realted to this status.
  5. I need to revise what I posted above. The FireFox AAA Services root cert. is not the same as that one present in the Win root CA store. The FireFox AAA Services root cert. contains both SHA-1 and SHA-256 thumbprints whereas the Win root CA store cert. only contains a SHA-1 thumbprint. This is why the web site web site is fully accessible via FireFox and not so in Microsoft browsers. Note that Microsoft browsers use the Win root CA store exclusively for web site cert. chain validation processing. Referring back to what I posted previously, it appears OSCP servers used in web site cer
  6. If this is in reference to bypassing the Eset activation problem, the answer is no.
  7. Based on your screen shot, it appears you are attempting to create these Eset exceptions using the HIPS? These PUA exceptions need to be created as real-time scan exceptions.
  8. Again, only a detailed forensic analysis would show where the e-mail hack occurred. Based on your statement, it appears that it occurred against Earthlink e-mail servers. If this is indeed the case, the attacker probably harvested e-mail logon data from the servers and used that to gain access to your e-mail and e-mail account.
  9. I don't have Chrome installed, so I can' test with it. Try using Chrome on your end ,and see if the web site use is OK.
  10. I did some further analysis. I found the AAA Services root cert. in FireFox. It's listed under the name of "Comodo AAA Services root." It also matches that for the same cert. in the Win root CA store. So we can rule out a certificate issue here. I next thought that perhaps it was a TLS downgrade issue since this web site supports downgrade to TLS 1.0 and 1.1. Note Microsoft browsers now only support TLS 1.2 connections. But Firefox shows a TLS 1.2 connection. So we can rule out this one out also. Now here is where it gets really weird. In both IE11 and Edge, I inspected the code
  11. FYI: https://www.reddit.com/r/Windscribe/comments/in4khu/hosts_file_has_been_block/
  12. I disabled Eset protocol filtering. This means Eset Web Access and Phishing protection were fully disabled. I tried to access this web site in IE11 with the same result; blank web page displayed. As far as I am concerned, this web site issue has nothing to do with Eset protections. Why access to the web site works on devices w/o Eset installed must be related to something else.
  13. I would say responding properly to this Eset alert depends on where you downloaded Windscribe from: https://www.lowyat.net/2020/222527/backdoor-windscribe-vpn-installer/
  14. Here's what another SSL Checker web site yields. Note this was done with Eset SSL/TLS protocol scanning certificate exclusion for the web site:
  15. Do what @Marcos instructed and we'll proceed from there. It appears your client devices having this issue are all Win 7 based?
  16. I am pretty sure I know what the issue is and it's a "humdinger." Again refer to the QUALS path #2 path analysis. Note that the thumbprint for the AAA Certificate Services certificate was calculated using SHA256. This implies that the corresponding cert. accessed from the OSCP server they used in the analysis was created using SHA256. However, the AAA Certificate Services certificate in the Win root CA store on my device is using SHA1. So I am not sure that Eset's adding this SHA256 cert. to their OSCP servers will solve the issue. It might require Microsoft using an update to the A
  17. It gets worse. Here's the web site cert. thumbprint per FireFox: -EDIT- Scratch this analysis. I forgot to exclude the site from Eset SSL/TLS scanning.
  18. I do see one issue. Refer to the AAA Certificate Services root CA store cert. shown the QUALS path #2 cert. verification chain. I checked my Win 10 root CA certificate store and an AAA Certificate Services certificate does indeed exist there. However, the thumbprint shown doesn't match that shown for the same cert. in the QUALS analysis. This I assume is the reason why the web site won't render in any browser that uses the Win root CA certificate store by default such as IE11 and Edge. It appears to me some type of "man-in-the-middle" activity is occurring when trying to access
  19. I can connect to the web site in FireFox w/o an Eset cert. exclusion for it. It has to be something in how Internet traffic is being routed from your location in the Congo in regards to cert. chain validation processing.
  20. You can try Chrome since it uses its own certificate store. I did test with the Eset cert. exclusion using Edge Chromium and the result was the same as for IE11. Also below is a screen shot from FireFox w/Eset cert. exclusion still in place. The certificate chain processing is correct. It appears both IE11 and Edge are both using the path #2 chain noted in the QUALS screen shot. It is the extra chain cert. download in this validation path that is the issue for those browsers.
  21. I excluded the web site from Eset SSL/TLS protocol scanning and per below screen shot, it will still not display properly in IE11. At this point, I would say Eset is not the problem. Note that the certificate chain displayed is not correct since the web site root CA store certificate is missing. Since the site displays properly in Firefox regardless of Eset SSL/TLS scanning exclusion, use it for access to this web site.
  22. Per Quals SSL Server check, a chain path has an extra cert. in it. This status has caused past issues with Eset SSL/TLS protocol scanning:
  23. I can open this web site fine in FireFox. It won't open at all in IE11. All I get is a blank web page. Ditto for Edge. However, Edge didn't show any Intermediate cert. in the cert. chain path. So something is wrong with the cert. validation path for this web site.
×
×
  • Create New...