Jump to content

cmit

Members
  • Posts

    92
  • Joined

  • Last visited

Posts posted by cmit

  1. 28 minutes ago, itman said:

    I would say that is the answer we have been looking for. So we can "bury" that issue from discussion.

    @itman this is not the 100% answer you have been looking for because it is only the popup notification disabled but the Firefox itself the first time did show the yellow untrusted alert that shows the option to accept and continue for users' Firefox but not all.

    thanks but the people from ESET still do not have any answer to my original question (my first two posts) why we had to delete the ESET certificate from Firefox's Certificate Manager -> restart computer for every user of the same computer in order to have an option to "accept and continue" or be able to just able to view websites right away?

    This is getting more confusing is the issue from ESET, from Firefox, or from both, or simply our own ESET policy setting?
    From other threads other people have posted on ESET Forum, i don't think we are the only ESET customer having this inconvenient issue.

     

    image.png.b6dc48cba4aa770ebc51ddc819688f6b.png

  2. 5 minutes ago, itman said:

    Refer to the below screen shot. Is the noted option set to "Ask ……….?" I believe if that is set to block, Eset will just block the activity and you will not receive any alerts on the activity:

     

    Eset_Ask.thumb.png.b67663a95ae049accadd0996fd654c59.png

     

    16 minutes ago, itman said:

    There is another possibility in regards to your Eset installations.

    Reviewing again your posted badssl.com test results, it appears the connections were actually blocked. So the real issue is why you're not receiving any Eset alerts? In the List of SSL/TLS filtered applications section of the Eset GUI are all your browsers set to "Auto?"

     

    Screenshot below my setting should answer your question.

    image.thumb.png.29e86ee57c27348324fb53e5f438297c.png

     

    Our "Display alerts" and "Display notifications on desktop" is set to disabled. Is this the reason we didn't get that red and yellow alert? Some of our computer's Firefox do display the yellow untrusted alert within the browser (not the ESET popup) though. Some of our staff freak out when seeing popup from antivirus program.

    image.png.d22ecb72c335025cc68fc75a1d673924.png

  3. 9 minutes ago, itman said:

    Do this:

    1. Navigate to IE11's Tools option.

    2. Open Internet options.

    3, Click on Content tab. Click on Clear SSL slate. When the popup message appears that SSL slate has been cleared, click on OK for that popup. Close IE11.

    The above forces IE11 to repopulate its SSL cache with current certificates from all Windows CA stores sources. Reopen IE11 and perform the badssl.com test again reverifying that the web site's Eset root certificate matches the thumbprint in the Windows root CA certificate store.

    Eset's updates via ESMC should not have any bearing on replacement of Eset's root certificate in the endpoint's Windows root CA certificate store; at least it doesn't for EIS. My Eset root certificate dates back to my last full install of EIS ver. 12. 

    how is your IE11 verification procedure on ESET SSL certificate related to the issues I have been talking about since all ESET certificates are valid (not expired)?

  4. 23 minutes ago, itman said:

    To begin with, I am having no issues in regards to the badssl.com web site test using either IE11 or Firefox. My test results are identical to those previously posted by @Marcos; initially a red popup Eset alert is displayed about a revoked certificate and thereafter,  a yellow untrusted certificate popup alert for each badssl.com test performed. 

    this is the opposite from what you mentioned before:
    image.png.4be888f96466f42a05a7b53a7b248a3d.png

  5. On 5/12/2019 at 1:21 PM, itman said:

    If "you're following my drift" in the previous posting, it's starting to appear to me that some type of man-in-the-middle activity is occurring for your Internet connections. It is the only explaination I can think of for the Eset non-alert status when accessing the https://badssl.com/dashboard/ web site.

    @itman Could you give example of the man-in-the-middle activity on our Internet connections?
    Do you mean could be related to our ESMC setup, our domain controller policies, or from possible external threat activities?

    I am still waiting for @Marcos or someone else from ESET to explain why you and I both have the
    badssl.com result (ESET non-alert status) instead of ESET's alert.

  6. On 5/12/2019 at 5:49 AM, itman said:

    In IE11 and for the Eset forum web site, click on the lock symbol on the IE11 toolbar. Does it state Eset SSL Filter CA for Website Identification?

    Likewise, go https://badssl.com/dashboard/ and do the same and verify Eset SSL Filter CA is also shown.

    Also for both these sites, verify that the web site certificate chains to the Eset SSL Filter CA certificate:

    Eset_Cert.png.5ffc06b8ba162f8843168ed723770340.png

    -EDIT- Additionally for both web sites, verify that the thumbprint for the Eset SSL Filter CA chained root certificate matches the thumbprint for the corresponding Eset SSL Filter CA certificate stored in the Windows Trusted Root Certification Authorities folder:

    Eset_Thumbprint.thumb.png.c2ce8bc7a738a4719db341c0febefab1.png

     

    Both the ESET forum and the badssl.com/dashboard websites state ESET SSL Filter CA on all three tested computers
    but two of three tested computers' IE's ESET SSL Filter CA's thumbprint do not match the ESET SSL Filter CA in the certmgr.msc's Windows Trusted Root Certification Authorities folder.

    What does this mean? How is this related to the issues we are having?

    All certificates are valid (not expired).
    Every time there's newer version of ESET EndPoint AntiVirus released, we trigger update from ESMC. Would this be the cause of some thumbprint not matched?

    image.png.2df1392517ecec8ebc71852a43908aeb.png

     

    I need at least two people from ESET to comment on the issues I'm having.
    @Marcos @MichalJ

    image.png

    image.png

    image.png

  7. 1 hour ago, itman said:

    I have a theory about something.

    You stated that when you ran the https://badssl.com/dashboard/ test using IE11, you did not get any Eset alerts. On the device you did the testing using IE11, run certmgr.msc. Open the Trusted Root Certification Authorities folder.  Open the Certificates folder. Navigate to the Eset SSL Filter CA certificate and open it. If the certificate doesn't exist, we have found the problem. If the certificate exists, does it show that it has been revoked, is expired, or untrusted?

     

    Screenshots below what from three test computers I tested:

    image.png.7c808cf7896d97df01a4ba1f2d5d6b65.png

    image.png.486dd457d751a644e43aac70136fa99b.png

    image.png.c6853d58844d2cc4bd9595986d98f3ab.png

     

    Quote

    why is the last certificate shown with a valid from date of today?

    I have no idea. Maybe (don't quite remember) I have deleted the ESET certificate authority from Firefox -> reboot computer.

    ------------------------------------------------------------------------------------

    @itman  sry don't quite understand what you mean"If the Eset root CA certificate exists and in a valid status and/or does not exist ".
    My ESET root CA certificates do exist and are in a valid status but what does then "and/or does not exist" mean?

    ------------------------------------------------------------------------------------

     

    Now testing on a 4th computer.
    When using Firefox to connect to my test router, Firefox shows this
    image.png.6287b7b678588c438290d716195f1b3c.png

    But when using IE11, the test router's login page (in https) shows up fine.
    The certmgr.msc does show valid ESET certificate on this 4th computer as well.
    This 4th test computer also does not show ESET alert on Firefox and IE when going to badssl.com/dashboard (shows the red sha1-intermediate and dh1024 connected).

     

  8. 12 minutes ago, itman said:

    BTW - did you open an Eset support ticket on this? I don't know if this is solvable via forum replies.

    Yes about 2 months ago but got to nowhere.
    Created another ticket today. Will probably get another reply with general questions from Tier 1 ESET Support after 2+ days (1 day if lucky, usually the ESET Standard Business email support's reply is slow in my experiences so far).

  9. 2 minutes ago, itman said:

    That is very strange indeed. Especially that Eset's root CA certificate is installed in Chrome's corresponding root CA store. Obviously, something blocked the connections since you passed all the tests; i.e. "cannot connect." Did you get any other alerts from the browser's themselves about an untrusted certificate when the test was running?

    Are you talking about alerts from ESET or from this baddssl.com website?
    No alerts from ESET.
    But has a few red connected results on Firefox and Chrome.

    Are all the badssl.com's "Not Secure" result supposed to be all green (cannot connect)?

    image.thumb.png.69456227e6f4fded7650b408618c02b7.png

    image.thumb.png.5983a69614693dc030032821a16c2207.png

  10. 39 minutes ago, Marcos said:

    Did you get warnings like this? 

    image.png

    No, no ESET warning at all on three computers tested (Firefox and Chrome) when going to https://badssl.com/dashboard/
     

     

    41 minutes ago, Marcos said:

    Are both these eicar files detected upon download?

    https://secure.eicar.org/eicar_com.zip
    hxxp://www.eicar.org/download/eicar_com.zip

    Yes on all Chrome and Firefox that has ESET certificate installed.

     

     

    53 minutes ago, Marcos said:

    If ESET's root certificate is not listed in Mozilla's trusted root CA certificate list, do the following:
    - disable SSL filtering
    - reboot the machine
    - without launching any application, re-enable SSL filtering.

    This method did not work on that 1 of 3 test computers' Firefox newly installed. But this computer's Chrome already has ESET certificate and did detect both the eicar_com.zip files.

  11. 1 hour ago, itman said:

    Passed all the tests except for SHA-1 Intermediate of which IE11 shows a few including Microsoft's. What about a Comodo code signing cert? Should I get rid of that one?

    What do you mean getting rid of Comodo code signing cert?
    If you remove it from your browser, doesn't that put your web browser at risk of your antivirus not protecting the browser? (same purpose of enabling ESET SSL/TLS protocol filtering)

  12. 12 minutes ago, itman said:

    Did Eset certificate alert display for each test?

    No.
    But I noticed one of the computers that just had a fresh latest Firefox installed does not have ESET certificate exist when I went to this Firefox's Certificate Manager (still no ESET certificate in this Firefox after computer restart).
    Basically, as long as the ESET certificate is not within the web browser, all these issues go away, but loses the meaning and purpose of the "https everywhere".

  13. Same issues still happening often on multiple domain users (some from same computers but logged in with different Windows accounts).
    The suggested solutions in this link (https://support.eset.com/kb5833/?locale=en_US&viewlocale=en_US) also wastes time for system administrators.

    These two additional options ("SSL/TLS protocol filtering mode" and "List of SSL/TLS filtered applications") are just temporarily workarounds and not really working in all four scan actions (auto, scan, ignore, ask) we tested.
    Putting Internet Explorer, Firefox, Chrome into the excluded application from SSL/TLS scanning contradicts with what's mentioned about the "risk of disabling SSL/TLS protocol filtering".
    image.png.67e0621aa3550ac733f881b57ee20bb4.png

    image.png.0a2e876ffc1e933e8a47ee598c77766c.png

    If nobody from ESET can confirm if this is Firefox's issue (or Chrome or IE) or ESET's or our own issue, then two "ultimate" solutions can think of:
    1. set an ESET policy to just disable SSL/TLS protocol filtering for all domain computers.
    2. totally uninstall ESET and look for other antivirus alternatives.

     

    This is probably the moment somebody from ESET gonna ask for log collectors again on our computers (mostly at different location) and still might not have a conclusion.

    I have enabled the full diagnostics on a test computer but only can see the SysInspector.
    Log Collectors and Diagnostic logs are empty even after requested and turned ON.
    (Talked to two people from ESET Business Support chat but in my option they lack experiences about this part and just sent a few ESET Online Help links for customers to read without a full solution/explanation about these issues.)

    image.thumb.png.da33c7294664beb447ee68860d233a42.png

    image.png.a6e210156120ec7f1a6fbfdea72e6f48.png

    image.png.8416b2271f5b86f90d5f9a577188a673.png

     

    What's the purpose of using ESMC to check domain computers convenient if there's file size limit for log collector?
    (https://help.eset.com/esmc_admin/70/en-US/client_tasks_diagnostics.html)

    image.png.89055f0a198546e642155a43ec49b46f.png

  14. Is this Firefox's issue or ESET's or both? (or our own issue?)
    I believe my case is not related to this anymore (https://www.ghacks.net/2019/02/01/mozilla-halts-firefox-65-distribution-on-windows/) because the error message no longer says SEC_ERROR_UNKNOWN_ISSUER after Mozilla released fixed update.

    Cannot say if this is affecting all our domain users but most of our users still having the "SSL_ERROR_BAD_CERT_ALERT" without any options to select.
    The ONLY proper solution is to delete the ESET certificate authority from Firefox -> restart the computer (not log off) -> then will be able to access websites right away.
    If not right away, at least Firefox would shows "Warning: Potential Security Risk Ahead" to allow user to have the "Accept the Risk and Continue" button to click.
    We had to repeat this "solution" on every domain user of the same computer.
    (i.e. if there are 5 different Windows user accounts use the same computer, had to restart this same computer 5 times. Waste of time.)

    This issue also happening on brand new computer with fresh latest Firefox installed.

    image.png.6896fc4f1aed5f5db798d93a53bcd86b.png

     

    image.png.43de80e42be1a114790355a3a6f2002e.png

     

    image.png.a133e2675a7366a2040fe4fb1432b18e.png

    ESET tech support had suggested as follows:
    - temporarily disable the policy
    - on a client disable SSL/TLS filtering and make sure the error doesn't occur
    - reboot the machine
    - without launching any applications, re-enable SSL/TLS filtering
    - wait ~2-3 seconds, then launch a browser and open an https website

    But this solution did not work. I even clean-uninstalled and re-installed my ESET EndPoint AntiVirus.

    image.thumb.png.b97d1a4d2f1ae4972f42d339f0c40499.png

    Any ultimate proper suggestion/solutions?
    I have already collected and submitted the ESET logs (collector) but nobody from ESET has detailed explanation but simply suggested a work around.
    At least we need to know is this ESET's or Mozilla's issues or both or is this something else just never ends?

     

  15. 1 minute ago, cyberhash said:

    @cmit and @itman

    I'd say the firefox world has big problems, never seen any update for any software that has actually changed the installation folder without any user interaction 🙃, plus the delivery was via an in product update.

    I also see that after the 66.0.4 update , there is another (in product update) tonight to 66.0.5 ............ lets see what this breaks 🤒

     

     

    my concern and question is is this Mozilla's issue or ESET's issue?
    Even thought ESET "fixed it" (not sure if temporarily) by updating the detection engine but WHY did the ESET treat this .xml file as a trojan?
    Could any experts from ESET please explain in details?
    If this is the "big problems" of the firefox world, need to let Mozilla know.

  16. 4 minutes ago, JamesR said:

    Hello, please update the detection engine in ESET and the detection method should now be corrected, and the .xml no longer detected.

    1. So this is ESET's fault?
    2. What's the root cause of this FP?
    3. What's the updated detection engine version #?
    4. What is this VisualElementsManifest.xml for? I see Chrome and Windows tile also has this .xml file.
    5. What should be done with those already "affected" computers? restore from quarantine?
    6. so this "cleaned by deleting" really means "moved" to quarantine?
  17. Does the Scan function (In-Depth) scan more areas when EDTD is enabled vs no EDTD?

    I have also noticed that after the EDTD is enabled for our workstations, it takes 1.5 or double of time to complete the scheduled periodic in-depth scan.

    i.e.
    - usually takes 4-4.5 hrs without EDTD
    - with EDTD enabled, takes at least 6 hrs (or even 9 hrs) to complete the scan.

    This is another question related to the justification of if the EDTD really necessary (more $$$ times # of computers) or are those computers without EDTD (only EndPoint AntiVirus or EndPoint Security or File Security) basically have much higher chances of getting hit by threats?

    i.e.
    For the EDTD licenses cost, we would have to buy the bucket of 250 licenses even though we only around 190 devices needed. No option to allow customers to manually choose exactly how many licenses only required to purchase.

×
×
  • Create New...