Endpoint Antivirus SSL filtering problem

[Manfred123 0]

We are having problems with EEA SSL filtering with Thunderbird.

Some of our ISPs provide mailserver access names in the customer's domain: e.g. mail.customerdomain.com, and supply a TLS certificate that is shared among the domains that are managed by the ISP, e.g. *.ispdomain.com.

This raises an exception at the first access with Thunderbird, but after storing once an exception for this certificate, all works fine.

The problem arises when the ESET SSL filter adds its own signature to the certificate, which appears to be modified at every update - in practice every day or more.

This results in Thunderbird detecting that the certificate is changed, and raising an exception every time ESET changes its signature - i.e. every day or multiple times a day.

I have not been able to configure a proper exclusion in EEA. Policy mode looks interesting but it does not appear to do what is needed:

" Policy mode – All SSL/TLS protected sites are filtered, except configured exclusions. Either applications or server certificates can be excluded"

What I need is some "server certificates to be excluded", but I only see a list of "known certificates", and even if I configure the certificates I want to be excluded in this list with access "allow" and scan "ignore", still Thunderbird receives a certificate that has been modified by ESET by adding its signature.

Is there a way to configure an exclusion for some certificates (*.ispdomain.com in this example) so that this certificate is passed to the application untouched?

To me scan "ignore" should do exactly this, but it appears not to be so..

Otherwise, the only option I see right now is to exclude SSL filtering for the entire Thunderbird application, but this is not what I want, since this problem only applies to some of our ISPs

[Marcos 5,070]

What about importing the certificate and selecting the access action to allow (even if untrusted) and scan action to scan?

[Manfred123 0]

Marcos, thanks for the reply.

Unfortunately no luck with "Allow" and "Scan" either. Still Thunderbird receives a certificate that has been modified by ESET, and the exception is raised.

[Marcos 5,070]

Ok, so to avoid scanning and modification of the IMAPS or HTTPS communication, set the action to Ignore instead of Scan.

[Manfred123 0]

By the way, I had a similar problem with Dropbox, and I solved it by filtering Dropbox.exe to "ignore".

This is OK for such application, since I want /all/ of its SSL traffic to be ignored by ESET.

For Thunderbird this is different, since the problem applies to only some of our mailboxes, and I would rather keep the others fully scanned.

[Manfred123 0]

1 hour ago, Marcos said:

Ok, so to avoid scanning and modification of the IMAPS or HTTPS communication, set the action to Ignore instead of Scan.

This is the configuration I had when I first started this thread.

Edited April 4, 2019 by Manfred123

[Marcos 5,070]

Quote

For Thunderbird this is different, since the problem applies to only some of our mailboxes, and I would rather keep the others fully scanned.

It is not clear to me why the problem should affect only some mailboxes. Whether or not a particular SSL communication is scanned depends on the certificate and application so it's not possible to make some communication utilizing the certificate scanned and the other communication not (ie. when downloading from other mailboxes on the same mail server).

[Manfred123 0]

16 minutes ago, Marcos said:

It is not clear to me why the problem should affect only some mailboxes. Whether or not a particular SSL communication is scanned depends on the certificate and application so it's not possible to make some communication utilizing the certificate scanned and the other communication not (ie. when downloading from other mailboxes on the same mail server).

We have mailboxes with multiple providers, and this problem applies to some of them:

On 4/3/2019 at 5:09 PM, Manfred123 said:

Some of our ISPs provide mailserver access names in the customer's domain: e.g. mail.customerdomain.com, and supply a TLS certificate that is shared among the domains that are managed by the ISP, e.g. *.ispdomain.com. 

So, yes, all mailboxes that are managed by one such ISP are affected by the problem.

But, we also have mailboxes that are managed by providers whose certificate matches the name of the mail server, and the SSL filter works fine with them.

We would like to exclude the SSL filter only for the providers where the problem arises, and these are identified by their respective certificate.

Edited April 4, 2019 by Manfred123

[itman 1,659]

5 hours ago, Manfred123 said:

This is the configuration I had when I first started this thread.

Try removing Eset's root CA certificate from ThunderBird's root CA certificate store.  Without Eset's root certificate, no IMAPS or POPS scanning can be performed. Of course, Eset will not perform any malware scanning on incoming e-mail in regards to those protocols.

Edited April 4, 2019 by itman

[itman 1,659]

On ‎4‎/‎3‎/‎2019 at 11:09 AM, Manfred123 said:

Is there a way to configure an exclusion for some certificates (*.ispdomain.com in this example) so that this certificate is passed to the application untouched?

Refer to the below screen shot. By setting "Scan" to Ignore, Eset will not scan that URL. As far as I am aware of, "Name" must be a specific URL; wildcards would not be allowed:

[Manfred123 0]

11 hours ago, itman said:

Refer to the below screen shot. By setting "Scan" to Ignore, Eset will not scan that URL. As far as I am aware of, "Name" must be a specific URL; wildcards would not be allowed:

I would love this, but even if I set "Scan" to Ignore, still ESET modifies the certificate - specifically it adds its signature to it.

The problem is that ESET takes "Name" from the CN of the certificate, and it is not editable by the user.

Since the server provides a certificate with CN= *.ispdomain.com, I get the wildcard in the name, and I cannot remove or modify it.

Maybe the presence of the wildcard is why the channel gets scanned anyway?

[Marcos 5,070]

If Ignore is set for a particular certificate, the communication that utilizes the certificate is not intercepted, ie. it remains untouched by ESET and therefore the original certificate remains used.

[Manfred123 0]

On 4/5/2019 at 1:36 PM, Marcos said:

If Ignore is set for a particular certificate, the communication that utilizes the certificate is not intercepted, ie. it remains untouched by ESET and therefore the original certificate remains used.

This is what I would expect too.

But I see that the first time I start Thunderbird after system startup, it still gets a certificate signed by ESET. If I ignore the exception (and don't store the modified cert), subsequent accesses get the original certificate. This happens both if I re-access one of the mailboxes involved, and if I close Thunderbird and re-open it.

Snapshots follow:

I have the following configuration (actual CN renamed):

In Thunderbird, I have an exception for the following certificate:

After system startup, the first time I open Thunderbird it shows an exception for the following certificate:

If I ignore this exception, at subsequent accesses and/or after restarting Thunderbird no exception is raised, and I verified that the exception stored in Thunderbird still uses the AplhaSSL-signed certificate.

However, as an additional note, I have seen that if I re-configure the list of known certificates in ESET EEA by deleting and re-adding the certificate as above, after re-configuration the first access by Thunderbird again got the certificate modified by ESET. I have done this last part once, and seen it happen in that case.

Edited April 9, 2019 by Manfred123

[itman 1,659]

-EDIT- Thinking a bit more about what I posted below, don't believe this will help.

The problem is Eset doesn't support Thunderbird as an e-mail client. As such, it doesn't scan incoming e-mail at the network packet level. Eset will scan Thunderbird e-mail only after it has been received on the device. And since this e-mail is encrypted, Eset is using its root CA store certificate to decrypt the e-mail prior to scanning it. 

The certificate exclusion mechanism that exists in Eset only applies to web and e-mail traffic being scanned at the network level. In other words, it will only work for an Eset supported e-mail client.

Appears the only solution available to you is to use an Eset supported e-mail client to receive e-mail originating from *.ispdomain.com.

-End EDIT-

The problem here is not Eset nor Windows for that matter, but Thunderbird and for that matter - FireFox. Neither use the Windows CA certificate store mechanism but rather use their own. When you add a new certificate like you did in Thunderbird, the only entity aware of that certificate is Thunderbird. Thankfully it appears this will be changing in the near future and both Thunderbird and FireFox will have options to use the Window certificate store mechanism versus their own.

Try the following as a resolution:

1. Export from Thunderbird the *.ispdomain.com certificate. This will create a file of your naming with a .crt extension.

2. This certificate must be imported into the Window certificate store; probably the "Trusted People" store using certmgr.msc. Before this can be done, the .crt certificate file must be converted into a .cer  extension file since this is the only format certmgr.msc will accept. Here's a guide on how to perform the conversion: https://support.comodo.com/index.php?/Knowledgebase/Article/View/361/17/how-do-i-convert-crt-file-into-the-microsoft-cer-format .

3. Once the .cer file has been created, open certmgr.msc in Windows. Navigate to the "Trusted People" store and open it. Select "Import" entering the name of the previously created .cer file containing the *.ispdomain.com certificate.

At this point, we now have a trusted certificate in the Win CA store. Also, your previously created Eset GUI List of  known certificate SSL scanning ignore exemption for the *.ispdomain.com certificate should work.

Scratch the following. I just checked Windows Intermediate CA store and the Alpha certificate is there.

-EDIT- Another thing that might have to be done is to install the Alpha SSL CA certificate in the Windows Intermediate CA store. This is because the  *.ispdomain.com certificate chains to it. Normally the Alpha SSL CA certificate only is installed on web servers. See this for reference: https://www.alphassl.com/support/install-root-certificate.html.

Actual the ISPs in question here should be the ones advising you how to get the "fix" you need in regards to getting what your are trying to do to work via the Windows certificate store.

Edited April 6, 2019 by itman