Jump to content

ExcelIT2417

Members
  • Content Count

    15
  • Joined

  • Last visited

Profile Information

  • Location
    USA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hey @jmparsons, We had the same issue with Dropbox starting on Friday 12/11/2020 for a few clients. For whatever reason Eset seems bugged with this part of its SSL/TLS filtering. Dropbox has a support article noting the conflict and recommending users to add the full path Dropbox.exe to Eset SSL/TLS filtered application list and set it to ignore Dropbox so Eset stops blocking it. https://help.dropbox.com/installs-integrations/desktop/cant-establish-secure-connection Note: if you are using an ESMC you can just add it to any assigned policy for those workstations. If you
  2. Also to make sure I'm clear for future readers, the server and email client do finalize negotiations at TLS 1.2 and communication takes place encrypted as such for the entirety of the connection past the first few Client/Server Hello portions of TLS handshake. So from a network protocol layer standpoint, SSL is never used and never even shows up at any point with any version in the network traffic. Maybe Eset is pulling from the GUI setting of the email client somehow as you had suggested itman? Or maybe it was a convenient way to determine the setting back then (using or reading some Out
  3. Glad to hear it, we are also posting some information on the home user forum page where this problem is also happening. Somehow we have data going to both forum pages. I did some testing on my end and Eset is actually blocking traffic that isn't even SSL 2.0 or lower with that setting enabled or locally disabled. To quote from my post over there: https://forum.eset.com/topic/26019-protocol-filtering-stops-access-to-emails/page/3/ Just did some testing, as I suspected when Outlook 2013 or higher is set to "SSL" (2016 or higher actually labels it as SSL/TLS) it tries to negotiate TLS f
  4. Just did some testing, as I suspected when Outlook 2013 or higher is set to "SSL" (2016 or higher actually labels it as SSL/TLS) it tries to negotiate TLS first. In the attached you can see I have Outlook set to SSL, connecting to imap and smtp gmail servers, the wireshark packets showing the TLSv1.2 Server Hello message with the Cipher Suite used AES 128 with SHA 256. The external ip address is clarified to represent what imap.gmail.com resolved to at the time of testing. When Eset has the block obsolete enabled, it blocks this traffic which is incorrect as its not using SSL 2.0 or lower at t
  5. I'm not sure what to think at this point. Windows 10 claims no SSL 2.0 support out of the box (and we didn't use registry to enable). From Gsuite website it looks like even if you set for SSL it just uses TLS instead. I can verify that Office 365 works the same way in the background. That even if Outlook 2013 or higher is set to just Imap with "SSL" in the GUI, that in the background Microsoft will actually try to negotiate the highest encryption possible (TLS 1.3) and then work its way backwards until client and server agree. It would be more accurate to label "SSL" as "SSL/TLS" in Outlook GU
  6. Also I've been researching and Microsoft Outlook 2013 as of July 2015 patch while running on Windows 10 1607 or later should have SSL 2.0 disabled by default. It should only have SSL 3.0 as an option for SSL: *Note: We have made no registry changes to force enabling SSL 2.0 or lower, it is very much the out of the box Windows 10 setup with regards to SSL / TLS From Microsoft: TLS is a standard closely related to SSL 3.0, and is sometimes referred to as "SSL 3.1". TLS supersedes SSL 2.0 and should be used in new development. Beginning with Windows 10, version 1607 and Windows Ser
  7. Hello, Wanted to update this thread as well as I think I've figured out the problem with Eset Endpoint Antivirus doing the same thing. It seems from my testing there's a bug in the engine or the GUI where regardless of what you set "Block encrypted communication utilizing the obsolete protocol SSL v2" to the engine ignores it. The way I fixed ours is through our ESMC server. With the business version you can have all your endpoints managed by a central server. When we push out a policy with it disabled from the central server, then the engine respects the setting and stops blocking SSL. B
  8. Hello, Did some more testing on my end and I think I found the bug in Eset Endpoint Antivirus anyway when managed by 1 central ESMC that applies a policy to the endpoints. We have "Enable SSL/TLS filtering" enabled by ESMC policy, unable to be changed by the endpoint local settings. We then have "Block encrypted communication utilizing the obsolete SSLv2" disabled by default on the clients, but not set by the ESMC policy. In the ESMC policy it is set to "Setting won't be set by this policy, it will be editable (unlocked) on the client". In that GUI screen, it shows the defaul
  9. Just to chime in, we have a separate thread going on the business user forums for Eset Endpoint Antivirus - tested with 7.3.2041.0 and 7.3.2044.0 with the exact same issues. When SSL filtering is on, Outlook cannot connect to the email servers. Tried this across 5 companies we manage across over 30 pcs connecting to different email hosting providers. There are more pcs I just haven't had a chance to test them yet. So far not 1 computer I log into will work in Outlook if SSL filtering is turned on. In some rarer cases it even stops Firefox from browsing HTTPS pages correctly. The user calls sta
  10. Ran the update from 7.3.2041.0 to 7.3.2044.0 and same results when SSL filtering enabled with any computer I remote into and try to use IMAP or SMTP via SSL in Outlook. I have yet to remote into a computer and have Outlook work when the setting is enabled, probably gone through 30 pcs so far across 5 companies with a few different email hosting providers in the mix.
  11. Thanks for the suggestion I do appreciate it. But for now we're not changing dozens of computers from SSL to TLS. Maybe in the future we will go down that road, TLS is better from a security perspective. In any case, this appears to be an Eset issue - whether caused by Microsoft/Eset/or something else. Checking those machines, their last Windows updates were patch Tuesday in October so nothing has changed on the Microsoft update front anyway (we first started receiving calls on Monday morning 11/2/2020). Even if all email was on TLS, we would still be getting SSL issues in browsers for ex
  12. So the larger problem seems to be with Outlook when it connects via SSL (Microsoft 365 exchange connections appear to be unaffected). After re-enabling the SSL filtering on all computers, I checked about 10 randomly where I know they have IMAP/SMTP via SSL only setup. All 10 random computers cannot connect to the IMAP/SMTP servers when the SSL filtering is enabled. These are over about 5 separate companies with unique infrastructures, different ISPs, etc. I have other computers with Firefox that do work when the setting is enabled, so this particular pc may just be weird, or may be a
  13. Hello, Here are the results for the Firefox computer: 1) Windows Certificates Trusted Root Certification Authorities: When SSL/TLS is disabled its gone, when enabled its back. And it matches the creation / expiration date in Eset Gui and there is only 1 of them. 2) yes when enabled or disabled that prefs.js file exists 3) yes when enabled or disabled - roots.enabled is true and locked and the setting above it - enterprise_roots is set to true 4) Eset does not appear in Firefox Authorities when enabled or disabled. Also I noticed in Eset GUI it mentions adding Eset certifi
  14. Hello, Thanks for replying. I will check all of the points your requested when I can. Currently the devices are in use so I'll have to wait until after hours to grab some diagnostic data and do some testing. Currently the 2 pcs I saw with Outlook SSL issues were running fully patched Outlook 2013 connecting to GSuite services. 1 pc Win 10 Pro 1903 64bit, 1 pc Win 10 Pro 2004 64bit The 1 pc with Firefox issues was a fully patched standard install version of Firefox (82.0.2) - Win 10 Pro 1903 64bit In regards to the TLS 1.2+, currently the above platforms should already
  15. Hello, We are having issues similar to those in this thread from Eset NOD 32: We are running Eset Endpoint Antivirus V 7.3.2041.0 So far this morning we have had 2 users at separate companies unable to access email via Outlook for GSuite. The protocol used is SSL. The only thing that fixes it is disable SSL/TLS filtering altogether. I checked the certificate status and it says the certificate is ok and valid but the cert looks like it was generated on 10/27/2020. Another user called from another company and could not access https websites via Firefox. Disabling SSL/TLS pro
×
×
  • Create New...