Jump to content

ExcelIT2417

Members
  • Posts

    15
  • Joined

  • Last visited

Everything posted by ExcelIT2417

  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 want to only exclude on workstations having the issue locally, you can add it locally from that workstation just make sure your ESMC policy is set to Append for Workstation settings otherwise it won't let you add them.
  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 Outlook file/reg entry) before the patch to Outlook 2013 which enabled TLS using SSL setting? I don't see any other reason it would block it. Just weird that this worked absolutely fine up until last week with no changes that I can tell on Eset program front / Windows update front, unless it came through a definition update to Eset? At this point I think Eset needs to take a look and figure out why they are blocking legitimate TLS 1.2 traffic when that setting is enabled, and fix their GUI bug where it doesn't respect what you set it to locally.
  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 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 SSL V2 enabled or locally disabled only, it blocks this traffic which is incorrect as its not using SSL 2.0 or lower at this time it is using TLS 1.2.
  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 this time. I will post this as well on the business forum page.
  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 GUI. Its possible GSuite and Outlook are doing the same dance. I suspect they are negotiating TLS instead, in which case if the version is high enough it would fall back to being an Eset issue - where they are incorrectly identifying which traffic to block via that obsolete setting. I'm going to run Wireshark and try to get the exact version SSL or TLS a pc negotiates for our email clients that didn't work. I'll post the results here. https://support.google.com/a/answer/100181?hl=en SSL and TLS Transport Layer Security (TLS) has replaced SSL. When using G Suite, be aware that all settings that mention SSL now use TLS. TLS is an industry-wide standard based on Secure Sockets Layer (SSL) technology that encrypts mail for secure delivery. G Suite supports TLS versions 1.0, 1.1, 1.2, and 1.3.
  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 Server 2016, SSL 2.0 has been removed and is no longer supported. Applications that require a high level of interoperability should support SSL 3.0 and TLS. Because of the similarities between these two protocols, SSL details are not included in this documentation, except where they differ from TLS. The following is from RFC 2246: https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-versus-ssl#:~:text=Beginning with Windows 10%2C version,and is no longer supported.&text=Because of the similarities between,where they differ from TLS.
  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. But with the just the local gui set to disabled, it still blocks. Not sure if this is applicable for the version in this thread, but it worked for us. https://forum.eset.com/topic/26108-ssltls-protocol-filtering-breaking-email-and-web-browsing/
  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 default setting as off. And indeed when viewing clients local Eset GUI advanced settings it shows the screenshot I posted earlier. It shows SSL enabled and locked, and Block disabled and unlocked. The bug is that in that state, Block is actually enabled under the hood but the GUI is not reflecting it and the engine is not respecting the GUI setting regardless of flipping it on and off locally. The way I ultimately had to resolve was to go back to the ESMC policy on the server and set Block to disabled explicitly by the policy and locked/uneditable on the client. *I do understand this is not ideal security-wise, but email must flow for now until I can change them all to TLS as suggested earlier. What is most curious to me though is that we have been running in the initial configuration (SSL on and locked, Block default off and unlocked) since V7 and it worked just fine. It was only 11/2/2020 that the bug kicked in(or perhaps over the weekend, but Friday was fine). We made no change to the policy or to the local config and no new windows updates since Oct Patch Tuesday and no Eset version upgrades for a few weeks. I'm not sure why and that's what I'd be looking at as Eset developers. I'm glad though as it showed me we have plenty of email clients running SSL apparently and not TLS. So that's a new project for this month. Still have no clue on the few Firefox browsers that break when Block is enabled, but Chrome worked fine in that scenario and the users can use that instead.
  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 started for us on Monday 11/2/2020. In our Firefox cases, doing the steps mentioned above (resulting in certificate regeneration) did not solve the problem. In our Outlook cases it did not solve the problem either. https://forum.eset.com/topic/26108-ssltls-protocol-filtering-breaking-email-and-web-browsing/
  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 example on some machines, leading me back to an issue with Eset Endpoint Antivirus and its SSL protocol filtering. One thing I have considered and will attempt tonight is to update to the new Eset program release version that was released a few days ago and see if that fixes it. Will report back findings here.
  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 part of the larger SSL issue. For reference, all computers have the same exact Eset configuration policy applied including exclusions.
  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 certificate to known browsers (when I have SSL filtering enabled), but Firefox does not show Eset in Authorities or in the "Your Certificates" box. Is that expected behavior? Thanks,
  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 support and be using TLS1.2+ - Outlook 2013 fully patched has support and we are using SSL only for incoming / outgoing for GSuite imap.
  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 protocol filtering also fixed her problem. I have tried disabling, closing gui, opening gui, and re-enabling SSL/TLS, and then rebooting. But that did not fix any client. To get ahead of the call storm, I have disabled SSL/TLS filtering on all managed devices from ESMC. From the posted thread above, it seems many are having this issue and it started last week. Anyone have any info on this? Is Eset aware and working on the problem? It's all been fine up until last week so something must have changed.
×
×
  • Create New...