Help! avast with Thunderbird error

[ellison64]

Originally Posted by hamlet

I am asking this because I really don't know. What is the benefit of allowing Avast! to check the email as it flows in (i.e., disabling SSL) versus the option of leaving SSL on and just having the av check the mail when it is opened? Is that even the point of contention in the discussion above? What about sending email? Is there a difference in the merits when it comes to sending?

Theres always been a bone of contention whether email scanners are necessary anyway as resident shield will hopefully catch anything.Its just reasssuring to see that scanned with avast tag and hope for the best
As for letting avast handle the SSL rather than the mail client (you will probably have to set thunderbird pop server to 110 rather than 995 (or turn off secure).Personally if i had avast installed i would make use of its ssl feature just because its there.

[Vladimyr]

Originally Posted by TheWindBringeth

Then what was Marcos referring to when he said:

The bold part makes it sound as though ESET uses the certificate trick to MITM the SSL connection between client and server.

He probably didn't intend it that way but yes, it does look a tiny bit like it's some "spooky" technique only ESET can achieve when it's just standard SSL/TLS handshake negotiation.

[jna99]

No matter what av you have running, SSL connections can not be scanned directly. SSL data needs to be decrypted first. Maybe Eset does it faster because it uses certificates to allow SSL data to be intercepted, decrypted and scanned automatically by Eset AV. If the certificate is accepted.

In light of the first post by OP about the error message. It is not a error message, it is stating that the SSL data over the SSL connection can not be scanned. Which makes perfect sense. If SSL data over an SSL connection could be scanned or read without a certificate technique then there is something seriously wrong or very unsecure.

[jadinolf]

Originally Posted by Vladimyr

If I may make a suggestion. Read before you rave.

Yep.

[TheWindBringeth]

Originally Posted by Vladimyr

He probably didn't intend it that way but yes, it does look a tiny bit like it's some "spooky" technique only ESET can achieve when it's just standard SSL/TLS handshake negotiation.

FWIW, I wasn't trying to make it sound spooky or ESET unique. You started out by saying "The ESET method is exactly the same as AVAST. There are differences only in the way interception & scanning of SSL traffic is invoked.". Given what Marcos said it sounds as though the methods are somewhat fundamentally different with ESET actually intercepting/scanning the SSL connection (SSL turned on in email client) and Avast not intercepting/scanning the SSL connection (SSL turned off in email client, which you mentioned).

However, that ESET knowledge base article doesn't mention having to make sure the client trusts ESET's certificate. Which I would expect it to if ESET were actually intercepting/scanning the SSL connection via the certificate trick technique.

I'm not familiar with ESET so I was/am in part trying to clarify and confirm what is really going on under the hood for myself.

[0strodamus]

@Vladimyr: Thanks for the clarification. I guess I wasn't confused after all.

@berryracer: IMHO, if you decide to ditch Avast in favor of ESET, it should be for reasons other than the concern you started this thread with.

[Vladimyr]

Originally Posted by TheWindBringeth

FWIW, I wasn't trying to make it sound spooky or ESET unique. You started out by saying "The ESET method is exactly the same as AVAST. There are differences only in the way interception & scanning of SSL traffic is invoked.". Given what Marcos said it sounds as though the methods are somewhat fundamentally different with ESET actually intercepting/scanning the SSL connection (SSL turned on in email client) and Avast not intercepting/scanning the SSL connection (SSL turned off in email client, which you mentioned).

However, that ESET knowledge base article doesn't mention having to make sure the client trusts ESET's certificate. Which I would expect it to if ESET were actually intercepting/scanning the SSL connection via the certificate trick technique.

I'm not familiar with ESET so I was/am in part trying to clarify and confirm what is really going on under the hood for myself.

Avast versions 5,6,7 have incorporated Open SSL to negotiate, share certificates, etc.

Being inadequately familiar with the inner workings of ESET's 'SSL Filtering' myself, I probably should avoid making statements like, "The ESET method is exactly the same as AVAST."

It's also unclear to me also from the ESET KB just exactly how their 'POP3S Scanner' intercepts, scans and delivers to the unadjusted email client. I wonder if they have a specific plug-in for each of the popular clients?

[TheWindBringeth]

From:

Which email clients are compatible with Windows ESET security products?
http://kb.eset.com/esetkb/index?page...LN2138&ref=wsf

"* ESET Smart Security version 5 will scan POP3/POP3S and IMAP/IMAPS email for the presence of malicious code while using Mozilla Thunderbird 6 and later or other email clients not listed above. Email will not be scanned for spam, however"

That ESET KB article previous linked to is for 4.x. In this KB article about disabling email protection in 5.x: http://kb.eset.com/esetkb/index?page...nt&id=SOLN2780 you can see a newer dialog which lists IMAP/IMAPS. It doesn't that I see tell us anything more about how it is implemented.

To me the "will scan... while using... other email clients not listed above" implies that it doesn't require client side cooperation but rather relies upon network level interception and proxying. To me the wording of the dialogs seems more consistent with "intercept/analyze the secure traffic on these ports" than "intercept/analyze unsecured traffic and forward it in secured fashion to this port".

So I'm leaning towards ESET doing a MITM of the SSL connection (vs Avast being an SSL endpoint).