As already mentioned here on the avast! forum, we have redesigned the handling
of TLS/SSL connections in the mail/web shield for the next program update. Under the
following link you can find a beta version of avast! for mac with this changes. It will
specially suit those people, who have problems with the current solution.
To use the beta version, simple uninstall the current version using the menu entry in
the avast! GUI and install the beta from the downloaded archive. Note, that this
will not keep any configuration from the old version like a “standard” program
update.
SSL should be NOT disabled in the mail server settings of your mail client anymore,
when using the beta (and any later version). Please check the mail account configuration
and alternatively switch SSL back to “enabled”.
This beta seems to solve the email conflict, but still causes Chrome to spike its activity when accessing websites with resulting slowness. Looking forward to official release
The “slowness” problem is a fileshield issue (you can “prove” this by disabling the fileshield temporary), not a webshield issue. We are aware of this issue and are working on fileshield speed improvements, but this beta (37943) does not contain any fileshield changes.
I understand that from many other posts. Question is, why are Safari and Firefox not so affected by fileshield? They both run faster, and do not seem to choke on some urls?
Thanks for the report. The webRep plug-ins are kind of “under construction” in the beta, so there may be some issues with them. However, this will be fixed in the final release.
Regarding the outgoing email scan - avast! for mac has never checked outgoing mail traffic and will not do so, at least not in the nearest future. The purpose of the product is to protect you from the bad world out there, not the other way, so this should be not a such big issue…
This is still under examination here, but the most probable explanation is that Chrome simple accesses more/bigger files (cache) than the other browsers.
After reading the technical info, I’m a bit concerned about the security implications. Thru the installation of the SSL CA Certificate in the Keychain the user is giving Avast! and any other program that manages to reverse engineer/hack this process complete control over the encryption trust chain, since technically Avast e resigning the connections with this certificate, if this process is somewhat hacked it could validate any otherwise untrusted connection.
I’m also giving quite a lot of trust to Avast!. The process detailed would be a quite perfect trojan horse and a smart way to circumvent the trust chain of SSL certificates.
We are creating, thru this process, a single point of failure in the trust chain, I would like to know what measures does Avast implement to make sure we aren’t in fact being more vulnerable by creating a single point of failure, by exchanging the trust in secure connections and things like prevention of identity theft, for the ability to virus scan the contents of secure connections. Because if I have to pick between the two I rather have my trust chain intact as there are other ways to control viruses (File scan).
Another question is: Is the certificate that is inserted into System Root generated locally and different for every installation or it’s the same cert for everyone?
Having briefly commented a few times, with amazingly quick, to the point responses, after more extensive testing the beta I have the following comments:
-regarding the mailshield, the ssl/tls flag does not appear as before with the release version. However my email response was almost totally blocked with access to my mail server timing out, until I set the fileshield to exclude my email client AND its associated support directories. I am guessing that this probably negates the AV scan on my mail. Based on the technical info, my keychain does indeed have the avast! trusted CA inserted, so that part works
-regarding installation, this beta still leaves the avast Application Support directory locked and not accessible from my account (which is an administrative account). Adding and admin r/w permission allows me to see the otherwise nonaccesible directory. I don’t know if this is a “bug” or “feature”, but it makes avast! free for mac less transparent to me.
-Do appreciate the substantial investment by avast for the Mac platform. I realize that the Mac OSX is by far still a small blip compared to the various Microsoft OSes.
I just tried this beta and Mail.app immediately failed to connect to a private mail server, once I changed it back to use SSL, that uses a self signed cert that is already added to the keychain (and was working on the previous version of Avast!).
Thanks for examining and testing the beta specimen9999.
We do not deny, that the process we are now using is a significant intervention into the SSL handling on the machine, but if done correct, it should not bring any security issues. After all, it is the mechanism that all antivirus software capable of scanning secured connections is using.
Also note, that to hack the process, you would need root rights. And a malware, that has managed it to run with root rights on your machine has already won and can use a plenty of other ways to affect SSL handling (e.g. install its own certificate into the system keychain).
The problem is, that a “traditional” file scan will not protect you from a big group of malware attacking the web browsers/web content. That’s why the web shield is there.
As described in the technical info, the certificate is generated on install/update and is “uniq” for every installation.
Poor fileshield performance on some mailbox files is a known issue and we are working on a fix. However I can not guarantee that this will be solved in the next release. The only think you can currently do is to exclude the folders from the fileshield scan as you did.
The Application Support directory is not user readable by design. The reason is, that there are stored some files, that may not be accessible for user processes, e.g. the private keys for the CA certificates.
Still one little question remains, the situation with self signed certs:
Mail.app immediately failed to connect to a private mail server using a self signed cert, already on the Keychain, once I changed it back to use SSL (this was working on the previous version of Avast!).
This is a bug, thanks for reporting. Connections with self signed certificates were dropped, instead of resigning with the “avast! untrusted CA” certificate. The issue was fixed in build 37968 which is available now under the download link. Please try the new beta and see if it works.
Ok, testing it now.
Mail.app now asked if I wanted to trust this certificate, “avast! untrusted CA”, for connecting to this server, I checked “always trust…” and now it works.
One concern thou, this means that ANY self-signed certificate will be accepted for connecting to this particular server? Since I trusted the "“avast! untrusted CA” any untrusted certificate can now be used and not only the certificate I had downloaded to my keychain?
Can’t avast sign with the trusted CA if the self-signed certificate is present on the keychain?
I’m wondering about the possibility of a middle man attack going unnoticed if any self-signed certificate is used by the attacker and not the specific one I downloaded from my private mail server.
I have one idea, maybe this is what avast! is already doing but here it goes:
When signing with the avast untrusted CA, generate a new cert for each singular self-signed cert for each specific domain, this way, when connecting to a specific domain that has had its cert changed the user will be prompt again for trusting/untrusting the new avast untrusted CA generated cert.
Another problem, this, the SSL scanning, apparently does not work well with virtual machines running under OS X.
Probably means the same certificate has to be installed in the Guest OS (Windows in this case).