SSL/TLS Protocol filtering breaking email and web browsing

[ExcelIT2417 1]

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. 

[Marcos 5,070]

1, If you disable SSL filtering, does the ESET root certificate disappear from the trusted root CA cert. store?

If so, does it re-appear there after re-enabling SSL filtering?

2, Speaking about Firefox, I assume it's not a portable version but one which is installed.  Does the file "C:\Program Files\Mozilla Firefox\defaults\pref\eset_security_config_overlay.js" exist?

3, If you open about:config page and search for security.enterprise_roots.enabled, is the option locked and enabled?

4, If you check Authorities in the Firefox certificate manager, make sure that the ESET root certificate is not listed there:

[itman 1,659]

I am starting to believe there is a Microsoft element to this issue. They are in process to deprecate all protocols below TLS 1.2+:

Quote

For our commercial customers of Office 365, deprecation of TLS 1.0 and 1.1 will begin October 15, 2020

https://docs.microsoft.com/en-us/microsoft-365/compliance/prepare-tls-1.2-in-office-365?view=o365-worldwide

One possible scenario in play here is Eset SSL/TLS protocol processing is allowing a protocol downgrade during the e-mail server handshake to something below TLS 1.2+. When Eset re-encrypts the e-mail and passes it on to Outlook, it is rejected by Outlook.

[Marcos 5,070]

When performing SSL filtering, we use the highest version of SSL/TLS which is announced by the client.

[ExcelIT2417 1]

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.

 

Edited November 2, 2020 by ExcelIT2417

[itman 1,659]

19 minutes ago, Marcos said:

When performing SSL filtering, we use the highest version of SSL/TLS which is announced by the client.

And just what does this mean? Protocol use is app dependent.

Using Win 10 1903+ for example, all these cypher's are supported: https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-10-v1903 . And quite a few support below TLS 1.2 level.

[Marcos 5,070]

What I meant was that the protocol negotiated between the client and the server should not be downgraded due to ESET filtering SSL communication.

[itman 1,659]

1 hour ago, ExcelIT2417 said:

The 1 pc with Firefox issues was a fully patched standard install version of Firefox (82.0.2) - Win 10 Pro 1903 64bit

This one is a mystery. I also use FireFox and its ver. is 82.0.2. I have zip HTTPS issues with Eset SSL/TLS protocol scanning enabled.

Verify that FireFox's about:config parameters are configured per those highlighted in the below screen shot:

 

Edited November 2, 2020 by itman

[itman 1,659]

Another thing to verify is that only one Eset certificate exists in the Win root CA certificate store and it is identical to the one shown in the Eset GUI in the SSL/TLS section.

[ExcelIT2417 1]

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,

 

[ExcelIT2417 1]

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.

 

[itman 1,659]

Can you connect to the e-mail servers using TLS? Is there any reason you're using SSL?

[itman 1,659]

Referring to this: https://support.microsoft.com/en-us/office/pop-and-imap-email-settings-for-outlook-8361e398-8af4-4e97-b147-6c6c4ac95353 , G-mail settings should be SSL/TLS.

[ExcelIT2417 1]

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.

[ExcelIT2417 1]

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.

[ExcelIT2417 1]

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.

[jmparsons 0]

ExcelIT2417, your information above worked for me.  Thanks for your testing and clear steps provided.  I was testing on Friday and was trying Interactive mode as a work-around.  Today I tried your suggestion above and now Outlook 2013 SSL IMAP is working again.   I had previously turned off the blocking of SSL v2 in the client, but it didnt work for me until I locked it from the server policy as you recommended. Thanks.

[ExcelIT2417 1]

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.

 

[jmparsons 0]

this is off-topic but related... ESET is doing something similar now to my Dropbox sync as well.  I still have the blocking of SSL v2 turned off (locked) from the server policy so SSL IMAP is working.  But today I see that my Dropbox sync shows "can't establish secure internet connection" unless I disable Protocol filtering from the ESET client.   So when I get time tomorrow hopefully I can find what specific changes I need to make to the server policy for Dropbox.

[Peter Randziak 1,130]

Hello @jmparsons,

at first try to enable the "blocking of SSL v2" and check if the Dropbox is able to establish the connection.

If not provide us with a logs to check:

1. Stop the Dropbox service

2. ESET's Advanced settings -> Tools -> Diagnostics -> Enable Protocol filtering advanced logging ; confirm by OK

3. Start the  Dropbox service and wait for the error "can't establish secure internet connection"

4. Disable the logging from the step #2 

5. collect the logs by ESET Log Collector 

6. upload the logs to a safe location and send the download details to me and @TomasP with a reference to this post to check.

Peter

[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.

[Marcos 5,070]

I would add that Dropbox now works with either Ignore or Auto action set for dropbox.exe and no changes in default settings are needed to make Dropbox work with ESET.

[jmparsons 0]

Thanks ExcelIT2417.   I did try to add the dropbox path in the policy on the server side but I was having path issues.  Eventually we just upgraded dropbox to Beta v112 which has worked for us so far.  I agree the SSL filtering is buggy in ESET right now.  

[Marcos 5,070]

13 minutes ago, jmparsons said:

Thanks ExcelIT2417.   I did try to add the dropbox path in the policy on the server side but I was having path issues.  Eventually we just upgraded dropbox to Beta v112 which has worked for us so far.  I agree the SSL filtering is buggy in ESET right now.  

I repeat, Dropbox works alright with ESET as long as you keep the action for Dropbox.exe set to "Auto" (default) or "Ignore". Only manually setting it to "Scan" would cause issues with Dropbox:

[jmparsons 0]

Marcos, this was not true in our case.  What new version of ESET Endpoint 8.x are you saying works for Dropbox v111 with setting "Auto"?  Are you saying this was a known ESET issue which has been fixed?   Also, setting scan action to "Ignore" is not a solution.  Thanks