Avast! Version 8.x “Invalid SSL Certificate” Issue Summary Part 1

I am posting this in two parts. Although the entire post is less than 10,000 characters, including spaces, the Forum software insists it exceeds the 10,000 character limit.

After dealing with this issue for nearly a month, and finding an interim work-around with much effort, I’m summarizing the issue here.

ENVIRONMENT: Workstations running 32-bit Windows XP Pro or Windows 7 Ultimate (with and without SP1), using any of these email clients: Outlook Express 6; Eudora 5.x, 6.x, 7.x; Thunderbird 2.x. Three different sets of POP/SMTP servers are used. All email clients are set to connect to these servers WITHOUT SSL or TLS. The servers do not require or support SSL/TLS connections. Avast! was administered on a network using an “administration console” (type/version is irrelevant) that was set up to push EndPoint client Program updates automatically.

OBSERVED BEHAVIOR: After workstation EndPoint clients were updated from version 7.x to version 8.x, some users began seeing Avast! “Mail Shield Security Exclusion” windows, which displayed a message that “Avast! has identified a problem with [the] site certificate [for the email POP or SMTP server].” The window also says, “This site attempts to identify itself with invalid information,” and “The certificate is not trusted.” This window contains a button whose label indicates that pressing it will permanently record an “exclusion” for the certificate. However, pressing this button does not always permanently stop these messages from appearing.

If that button is pressed, another Avast! window appears saying that Avast! has a “new way” to scan SSL emails, and advising the user to turn on SSL email connections in the email client.

When the actual certificate is viewed using the option available in the “Mail Shield Security Exclusion” window, it is always UNexpired. I do not know what criteria Avast! uses to assess certificate validity, but the certificates of three different sets of POP/SMTP servers were reported as “invalid” and “not trusted” within seconds of each other, so I strongly suspect that those criteria are bogus. One server was internal and hosted on my LAN. A second was external and hosted by a fairly small, but reputable, email service provider. The third was hosted by Time Warner Cable (“RoadRunner”), a widely-recognized major ISP. Even if the LAN server certificate was questionable, the other two could not be. I believe that all of the certificates were in fact valid.

For Thunderbird clients, these messages always caused a Windows Program Error, and in one case, a C5 crash error.

I emphasize that this problem occurred only for SOME, not all, workstations that were updated to EndPoint version 8.x. Also, the problem did not always occur on first use of an email client after the EndPoint update. And finally, pressing the button to record the exclusion worked permanently on some workstations but not others. When it did not work, the Avast! “Mail Shield Security Exclusion” window would reappear when a user tried to download or send email using one or more of the three possible POP/SMTP servers, as soon as on the next attempt, or as late as 2-3 days later, after several successful attempts.

There is no consistency in terms of which OS or email clients were used. The problem was seen on workstations with either of the OSes listed, and any of the email clients listed, when connecting to any of the three POP/SMTP servers. There are many other identically-configured machines on which the problem never occurred during a 15-day period while Version 8.x EndPoint clients became available and before I turned off automatic program updates on the console.

This problem seriously disrupted access to email in my organization. I have 93 EndPoint clients installed for staff, and most of them use email many times a day as a critical job function. The problem occurred on 24 of these workstations (26%). I had to visit several of them more than once to address the problem, and the only reliable solution for some of them was to uninstall the 8.x EndPoint client and reinstall the 7.x EndPoint.

EXPECTED BEHAVIOR: All email clients that functioned properly with EndPoint version 7.x should function properly with EndPoint version 8.x. That is, when those clients are not configured to use SSL/TLS, Avast! should not display messages regarding email server SSL certificates at all. IF an email client, such as Thunderbird, IS configured to use SSL/TLS, and IF the server’s certificate is genuinely invalid, then displaying a message about it should not cause an error in the email client.

ADDITIONAL REPORTS:

  1. I have seen one other report on the Avast Forum that seems to describe the same problem: see “SMTP Emails remain in queue after update to Avast 8” (http://forum.avast.com/index.php?topic=129733.0). This person reported seeing a message about an invalid SSL certificate when a POP/SMTP email client tried to connect to an Exchange server.

  2. During testing I installed SOA version 1.2.2.28 on two different machines. Part of the installation involves setting up an email account that the SOA will use to send notifications. In both cases the SOA was installed on Windows 7 Ultimate, though one was a 32 bit OS and the other was 64 bit. For both I used our internal email server, hosted on our LAN, for the account. During one of these installations, the Avast! “Mail Shield Security Exclusion” window appeared as soon as I entered the server address. During the other installation, it never appeared, even when I sent a test email.

See part 2 for more information.

This is Part 2 of my post:

ADDITIONAL INFORMATION:

This problem involves at least one design bug and three code bugs, as follows:

  1. Design Bug: Avast! promotes Version 8 as having a “new way” to scan email messages transported over SSL connections. That’s fine. However, Version 8 also apparently expects that EVERYBODY who uses POP/SMTP email has their email clients set to use SSL/TLS. Therefore, Version 8 EndPoint client software is installed with the “Scan SSL Connections” checkbox checked (ON) in Mail Shield>Settings>SSL Scanning.

That is an invalid assumption. Perhaps SSL/TLS is becoming more common for POP/SMTP email, but it is not universal. Therefore this feature should PROBABLY be turned OFF by default. It’s hard to be sure, though, because the implementation is so buggy that I can’t determine what the Avast! developers really intended the proper behavior to be. See below:

  1. Code Bug 1: Whatever EndPoint version 8 is supposed to do with SSL email connections, it does it inconsistently. The “Mail Shield Security Exclusion” message window does not always appear on the first attempt to access email on a newly updated Version 8 EndPoint client; indeed, on some clients it never appears at all.

In my opinion, even when the “Scan SSL Connections” box is checked, this message should only appear IF the email client is ACTUALLY USING SSL, and then only if the server’s certificate is genuinely “invalid”.

None of my email clients was configured to use SSL/TLS. None of the POP/SMTP servers require or support SSL/TLS. So I think there are really three bugs here:

A. When “Scan SSL Connections” is checked, the Mail Shield should only scan ACTUAL SSL CONNECTIONS. Instead, it seems to treat ANY connection to a POP or SMTP server as an SSL connection.

B. If the conditions are correct for the Mail Shield to scan SSL connections, then Avast! should only report certificates that are genuinely either expired or not reliable as “invalid” and “not trusted”. Instead, it appears to indiscriminately label ALL POP/SMTP server certificates as invalid and requiring “exclusion”.

C. Whatever it does, the Mail Shield should do consistently. If the described message was both appropriate the type of email connection, and valid with regard to the analyzed certificates, then it should have appeared on the FIRST USE of EVERY email client on EVERY workstation after the EndPoint client was updated to Version 8.x. Instead, the problem appears to have occurred randomly on some machines but not others, without regard to the environment in which it occurred.

  1. Code Bug 2: Pressing the button in the “Mail Shield Security Exclusion” window to record a permanent “exception” for the certificate worked on some machines, for some email accounts, but not for others. This also appears to have been random.

  2. Code Bug 3: The SOA has a setting that could affect this issue: Group Settings>Shields Settings>Mail Shield>SSL Settings>“Automatically detect and warn about unprotected SSL connections”. This checkbox is checked by default in the SOA.

It’s not clear what the purpose of this checkbox actually is. However, when I uncheck it, it doesn’t change the only relevant Version 8.x EndPoint client setting that I can find: Mail Shield>Settings>SSL Scanning>“Scan SSL Connections”. That box remains checked in the EndPoint Client. Yet it appears that this client setting is SUPPOSED to be controlled by the SOA, because if I uncheck it in a managed client, it gets rechecked almost immediately–usually.

But this also is inconsistent. On one workstation I unchecked this box in the client and it stopped the “Mail Shield Security Exclusion” windows from appearing. On several other workstations, however, this had no effect.

CONCLUSION:

I don’t understand why more people have not reported this problem. It seems possible that use of POP/SMTP email without an SSL/TLS connection is no longer common. Nevertheless, it is still an option that some people use. I urge anyone who has had a similar problem to report it here.

As mentioned above, the only reliable work-around for this is to uninstall the EndPoint Version 8 client and reinstall the Version 7 client. This is acceptable for now.

However, there will eventually come a time when Version 7 clients won’t work on newer machines. Avast! needs to fix this problem before then. My organization’s license expires in 2015. If Avast! has acknowledged and fixed this problem by then, I will seriously consider renewing our use of Avast!. If the problem is not both acknowledged and fixed, then I will resort to another network antivirus system.

Wish I could help on this one. We aren’t using POP/SMTP for our mail clients, so no valid test case. :frowning:

I’m curious if you uninstall Avast! v8 from a machine experiencing the problems, and then use the AWSClear.exe and then reinstall a new v8 client (via by a newly generated installer from your SOA console), if it starts acting more consistantly?

Thanks.

I don’t have any clients currently acting up anymore, since I substituted version 7 for them. :slight_smile: Since I can’t predict where or when the problem will crop up, it doesn’t seem worth the time to try uninstalling a 7 somewhere and reinstalling an 8 to see what happens. However, I am going to canvass the network to see if anybody is still getting the pop-up windows and is just closing them. If I find any, I’ll try this.