Protocol filtering stops access to emails

[itman 1,659]

1 hour ago, Marco5342 said:

Hmmm, but if Thunderbird works how it's configured, it shouldn't use SSL v2. So the setting shouldn't matter for me. In Thunderbird I have deprecated  TSL versions disabled and the value of security.tls.version.min is 3 (which should mean: TLS 1.2 is the minimum required encryption protocol.).

It is becoming apparent that for some unknown reason, Eset ver. 14 is not respecting local e-mail server SSL/TLS settings in an e-mail client.

However, it appears that you are using Dovecot as your local e-mail server: https://www.dovecot.org/ .

On 10/28/2020 at 6:07 AM, Marco5342 said:

My mailserver responds:

Oct 28 11:02:39 srv212 dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=..., lip=..., TLS handshaking: Connection closed, session=<RIV2Q7iyL/AgAQmCLKoAAbkEkhRHCuES>
Oct 28 11:02:39 srv212 dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=..., TLS: read(size=637) failed: Connection reset by peer, session=<7Px4Q7iyK/AgAQmCLKoAAbkEkhRHCuES>

 

This is Linux/Unix based. Are you accessing this via the Win 10 Linux interface?

 

Edited November 8, 2020 by itman

[Marco5342 3]

30 minutes ago, itman said:

This is Linux/Unix based. Are you accessing this via the Win 10 Linux interface?

It is not a local e-mail server, this is a remote (public) server on CentOS.

[itman 1,659]

4 hours ago, Marco5342 said:

Hmmm, but if Thunderbird works how it's configured, it shouldn't use SSL v2. So the setting shouldn't matter for me. In Thunderbird I have deprecated  TSL versions disabled and the value of security.tls.version.min is 3 (which should mean: TLS 1.2 is the minimum required encryption protocol.).

This posting is a bit dated but I believe still applicable: https://serverfault.com/questions/656488/imap-tls-connection-to-dovecot-fails .

This gist of the posting is if Dovecot e-mail server you're connecting to in Thunderbird does a TLS downgrade for some reason, it will fail resulting in the server connection failing.

[itman 1,659]

Another thing to note in regards to SSL protocol use in Thunderbird.

Below is a screen shot of all the SSL v3 ciphers that Thunderbird supports.

I am starting to believe that Eset in ver. 14 is deferring to existing Win ciphers when it re-encrypts e-mail traffic and that is the issue. Eset's root cert. uses sha256RSA.

 

 

Edited November 9, 2020 by itman

[ExcelIT2417 1]

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.

Edited November 9, 2020 by ExcelIT2417

[itman 1,659]

I really don't believe the issue with SSL v3 is an Eset issue; at least as far as Gmail is concerned.

I found a web site that will check any e-mail server SSL status: https://ssl-tools.net/mailservers

According to this site's tests, Gmail servers flat out do not support SSL v3:

-EDIT- I just checked rodgers.com. Same thing - no SSL v3 support.

Note this comment from the test web site:

Quote

To establish a secure connection a mail server has to offer STARTTLS (SSL), a trustworthy SSL certificate, support for the Diffie-Hellman-Algorithm to guarantee Perfect Forward Secrecy and must not be vulnerable against the Heartbleed attack.

I believe all DH ciphers have been removed from recent Win 10 versions. However, I do recollect removing DH1024 cipher manual so I could pass badssl.com test:

Per badssl.com web site test:

Edited November 10, 2020 by itman

[ExcelIT2417 1]

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.

[ExcelIT2417 1]

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.

 

[itman 1,659]

1 hour ago, ExcelIT2417 said:

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.

This makes at least partial sense.

However, it appears to only manifest if the e-mail client is using the SSL versus SSL/TLS setting. It is starting to appear that Eset is now keying off of the type of encryption used from the e-mail client. During the connection handshake, e-mail server says it is using TLS. Eset sees the client will only except SSL. So Eset in turn, blocks the connection. It really has nothing to do with the block SSL 2.0 communication setting per se.

It really looks like in the past, Eset only blocked SSL 2.0 communication and the excused itself from any other communication monitoring.

Then there is the question of the e-mail client accepting TLS communication which it appears it does, when you have specifically instructed it to only use SSL? I believe the answer here is cipher based. SSL 3.0 will accept most TLS ciphers. So in reality, all the e-mail client cares about is the cipher being used in the handshake. As long as the client Win OS installation has the cypher presented by the e-mail server installed, all proceeds w/o issue.

 

Edited November 10, 2020 by itman

[ExcelIT2417 1]

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.

[itman 1,659]

7 minutes ago, ExcelIT2417 said:

Maybe Eset is pulling from the GUI setting of the email client somehow as you had suggested itman?

Really believe this was the case in ver. 14. Appears someone forgot that it's the ciphers being used that count and the protocol specification is irrelevant.

An how did Eset determine if SSL 2.0 protocol was being used in the past? By the cypher's only applicable to it.

Edited November 10, 2020 by itman

[itman 1,659]

Also of note is since Win 10 1607/Server 2016, SSL 3.0 is disabled by default. Likewise, SSL 2.0 has been completely removed.

I find it a "strech" that current versions of Outlook would be actually allowing a SSL 3.0 connection from any commercial  e-mail server. Or, the commercial e-mail server actually trying to connect to the client via SSL 3.0.

Quote

SSL support

Beginning with Windows 10, version 1607 and Windows Server 2016, the TLS client and server SSL 3.0 is disabled by default. This means that unless the application or service specifically requests SSL 3.0 via the SSPI, the client will never offer or accept SSL 3.0 and the server will never select SSL 3.0.

Beginning with Windows 10 version 1607 and Windows Server 2016, SSL 2.0 has been removed and is no longer supported.

https://docs.microsoft.com/en-us/windows-server/security/tls/tls-schannel-ssp-changes-in-windows-10-and-windows-server

Additionally, the only way SSL 2.0 or 3.0 can be used at the app level is if this registry override modification was performed:

Quote

When an application specifies WINHTTP_OPTION_SECURE_PROTOCOLS, the system will check for the DefaultSecureProtocols registry entry and if present override the default protocols specified by WINHTTP_OPTION_SECURE_PROTOCOLS with the protocols specified in the registry entry. If the registry entry is not present, WinHTTP will use the existing operating system defaults for Win WINHTTP_OPTION_SECURE_PROTOCOLS HTTP. These WinHTTP defaults follow the existing precedence rules and are overruled by SCHANNEL disabled protocols and protocols set per application by WinHttpSetOption.

Note The hotfix installer doesn't add the DefaultSecureProtocols value. The administrator must manually add the entry after determining the override protocols. Or, you can install the "Easy fix" to add the entry automatically.

The DefaultSecureProtocols registry entry can be added in the following path:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp

On x64-based computers, DefaultSecureProtocols must also be added to the Wow6432Node path:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp

https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi

Edited November 10, 2020 by itman

[itman 1,659]

Since I previously created a screen shot of this, the following are particulars into TLS cipher's for SSL 3.0 in regards to Win 10 1903+.

The only default cipher installed for SSL 3.0 is TLS_RSA_WITH_NULL_SHA.

The following TLS ciphers are compatible w/SSL 3.0 but must be manually installed:

 

 

Edited November 11, 2020 by itman

[inkydolphin 0]

On 10/29/2020 at 3:57 PM, JeffJ said:

I have several dozens of clients that are all reporting this issue as well, they all get a error stating the server does not support the encryption method all of the sudden, This is affecting Rogers emails as well as other ISP's using ssl but not gmail. It does not affect TLS, only SSL 

this is all since 14.0.21.0  

A work around is to either disable ssl/tls filtering or changing it from automatic mode to interactive mode and when you send an receive Eset AV prompts you if you want to scan the protocol and choose yes remember for this application then resolves the issue and you can change it back to Automatic  

This is certainly worth a go as doing similar sorted out my Thunderbird issue (no emails at all were being received and when sending emails it wouldn't save a copy to the sent folder due to a 'file permissions' issue). I did slightly differently in that I set ssl/tsl filtering to 'Ignore' then set it back to 'Auto' (clicking OK in between of course) but same principle. Thanks JeffJ!

Edited November 15, 2020 by inkydolphin

[itman 1,659]

For anyone using Thunderbird e-mail, I just noticed something.

By default:

security.tls.version.min

is set to a value of 3. This means the minimum protocol used in the handshake process to your e-mail server is TLS 1.2.

If you truly need to use SSL 3.0 to connect to your e-mail server, the above setting via about:config needs to be set to a value of 0.

Ref.: http://kb.mozillazine.org/Security.tls.version.*

Edited November 18, 2020 by itman

[Marco5342 3]

The last few days/weeks I've been in contact with Peter and he consulted the ESET dev team to solve my issue. We tried several things, I sent several logs and tried a patched version of the filtering part but it didn't help. Finally my issue disappeared after I removed some certificates from the 'Manage Certificates' config box in Thunderbird. This were certificates I (long ago) accepted due to self-signed certificates or test servers. Some servers I connect to now (which have now a valid certificate) had an certificate in that box (but not all). It looks like somehow something got confused by those certificates.

After deleting my own accepted certificates, I could enable the IMAPS check in ESET again and everything works fine. It doesn't explain where and why things went wrong and unfortunately I cannot reproduce it any more. You could try this too (and make a backup of the certificates first for debugging purposes).

[jonwatson 0]

Today my Win 10/Thunderbird 78.5.0 stopped working, specifically unable to log on to my ISP or Google because the User Name wasn't being transmitted on logon. Works fine restarting in Safe Mode but that's a diagnostic rather than a work around. Eventually after 1/2 day pottering around forums I switched off SSL filtering and then switched it back on. All is now well.

My question is why should I have to? ESET is a fine AV but most of your customers aren't either interested or competent to mess around with SSL filtering. It's a bug. Say so and fix it.

[Marcos 5,070]

42 minutes ago, jonwatson said:

Today my Win 10/Thunderbird 78.5.0 stopped working, specifically unable to log on to my ISP or Google because the User Name wasn't being transmitted on logon. Works fine restarting in Safe Mode but that's a diagnostic rather than a work around. Eventually after 1/2 day pottering around forums I switched off SSL filtering and then switched it back on. All is now well.

My question is why should I have to? ESET is a fine AV but most of your customers aren't either interested or competent to mess around with SSL filtering. It's a bug. Say so and fix it.

SSL inspection requires a root certificate to be imported into the trusted root CA certificate store in order for the browser or email client to trust the communication. If the correct root certificate is not present for whatever reason, the browser or email client will report an error. That's not unique for ESET, it's typical for any AV or software that performs SSL inspection.  You can keep SSL filtering disabled if you don't mind the risk of SSL communication not being scanned for threats.

[itman 1,659]

I will also add that unlike Firefox which has set preference to Win root CA certificate use by enabling this option:

security.enterprise_roots.enable true

Thunderbird has not done so.

If the AV certificate used by Thunderbird gets corrupted or whatever, the result is what @Marcosdescribed. Disabling SSL/TLS protocol scanning and re-enabling it, repopulates the Eset certificate in Thunderbird's Authorities certificate store.

Edited November 30, 2020 by itman

[DolphinZak 1]

Today using Thunderbird 78.5.0 with gmail.com and q.com accounts, email stopped being received from either source.  Disabling and re-enabling SSL/TLS protocol scanning immediately resolved the issue with both gmail.com and q.com.   May I suggest a prominent posting of this issue as it was difficult to find my way to this forum to resolve the problem temporarily.  I assume eSet will permanently resolve the issue.  However, if the issue requires coordination with Thunderbird, please inform, so that the necessary changes can be encouraged by Thunderbird users.

[jonwatson 0]

14 hours ago, Marcos said:

SSL inspection requires a root certificate to be imported into the trusted root CA certificate store in order for the browser or email client to trust the communication. If the correct root certificate is not present for whatever reason, the browser or email client will report an error. That's not unique for ESET, it's typical for any AV or software that performs SSL inspection.  You can keep SSL filtering disabled if you don't mind the risk of SSL communication not being scanned for threats.

You miss my point. I fixed my issue by turning filtering off. And then immediately turning it on again. That's a bug.

[Marcos 5,070]

Regeneration of the root certificate requires re-import of the root certificate to Thundebird's trusted root CA cert. store. We suspect that Thunderbird might have changed the TLS alert sent in case of an unknown root cert. which prevented re-import of the root certificate after the next user's logon or computer restart. The cause of the issue is being investigated though.

[TGA 0]

We're having the exact same problem here since yesterday : using Thunderbird 78.5, and ESET NOD 32 version 14.0.22.0, we can't get any message from our external MAPI accounts (at 1and1/Ionos in France). The sent messages can't be copied in the Sent emails folder either.
Note this is hapening with Windows 10 Pro 64 bits only : the same Thunderbird with the same ESET NOD 32 work fine under Windows 7 Pro 64 bits.
I had to disable temporarly the TLS/SSL certificate checking as a work around, expecting a fix from ESET or Mozilla. The suggestion about switching the checking ON and OFF again, or to use the interactive mode didn't work for me (or only for a few minutes, but I'm not sure I did it right...).

PS : kindly note your captcha bellow doesn't seem to be compatible with Chrome... ;)

[Marcos 5,070]

2 hours ago, TGA said:

The suggestion about switching the checking ON and OFF again, or to use the interactive mode didn't work for me (or only for a few minutes, but I'm not sure I did it right...).

Did you switch SSL filtering off after rebooting the machine without launching Thundebird? Did you click OK to save the settings and re-opened the advanced setup to re-enable SSL filtering then?

https://support.eset.com/en/kb7728

[instantflorian 0]

Hi. I did exactly what was described (switch off filtering, reboot, switch on filtering, launch TB). It did not solve the issue.

I still receive only mails if I switch of the SSL filtering.

(I'm using ESET Internet Security 14.0.22.0, Windows 10 Home 20H2)