This week, someone mentioned quickly that there were certificate issues on the Koumbit mail server and brushed it off with a quick remark of the type "oh but it's ok, if I accept then it's working fine". There were two of the sysadmins in the room at that moment: the response was "Wow, wait a sec.. please open an issue ticket about this and include a screenshot of the error you're seeing. Certificate errors are not supposed to happen."

The actual error

Here's the error that was popping up in Thunderbird, saying that there was an issue with the certificate:

When you view the certificate details, you can then find the actual problem. It would seem as though avast! is conducting a Man in the Middle attack on its users!

Here, you can see the fake certificate that's presented to the user. I've circled in red the parts that sounded the MitM alarm:

Now, compare the circled parts with values from the real cert that I retrieved by connecting to port 993:

$ openssl x509 -noout -in koumbit.pem -fingerprint -issuer
SHA1 Fingerprint=8E:B9:67:9A:6D:6C:E6:E4:5B:8C:27:59:4D:E7:07:5D:86:92:E0:1F
issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA

As you can see, the issuer differs from the real cert's issuer. The certificate presented to the user says it was issued by avast! Mail Scanner Root, whereas the certificate from the server was issued by RapidSSL CA.

Also, the certificate's fingerprint is completely different from the real certificate's fingerprint.

Why is avast! conducting MitM on users?

The reason that avast! gives for doing this is that this way they can scan mail before they reach the mail user agent (abbreviated MUA, the mail client application, in this case Thunderbird).

If I were to interpret this, I'd say that it was done for two reasons:

• users were complaining that, since anti-virus software used to scan mail only when you opened them, their MUA would be painfully slow because of the anti-virus software.
• implementing mail scanning at opening time in the MUA was complicated since it required them to implement it as a plugin to each and every popular mail client, and to support different versions of those clients.

By intercepting traffic before it gets to the MUA, they don't need to actually modify the MUA's behaviour. Also, they can now magically offer support to every MUA on Windows.

Why is this bad?

SSL connections exist so that, if done in the right way, you as a user can have a certain confidence in that the communication you established with a server is encrypting data that you are sending and that it gets decrypted only by the server you're connected to.

That way, you're trusting that only the server to which you're sending information gets access to that information, and that nobody listening on the network gets access to it.

Once it safely reaches its destination the information can actually get sent elsewhere: for example Google sends all your mail to other servers that parse and index the contents in order to build profiles that get sold to marketting firms.

In other words, you're trusting that the organization managing the server that receives the information is doing the right thing with it (I don't trust Google), but then since nobody other than that organization is theorectically getting access to the information you can blame that organization if something bad happens.

By presenting users with a fake certificate and hiding the real one, avast! is preventing users to have confidence in the security of the SSL connection that gets established to the actual server.

Also, it's encouraging users to blindly accept certificate errors as though it was normal. On a server that has a certificate issued by a trusted Certificate Authority (abbreviated CA -- or what some call the CArtel), there should be no errors and users should not accept certificates that the program says are problematic.

Finally, this MitM attack means that the data gets decrypted before it actually reaches you. Who knows what avast! is doing with the data once it's decrypted? After all, it's a proprietary software for which you cannot get access to the source code, so you cannot scrutinize what it's actually doing.

Arguably, the program is running on the machine under an administrator role, so it has access to that information anyway.

However, I'm most certain that they have implemented some sort of way to send home the mail that gets flagged as problematic so that they can analyze it and identify new viruses and phishing scams. What if a false positive is triggered: then it means a legitimate email potentially containing sensitive information is sent to an unknown place and viewed by unknown people from the organization behind avast!.

Do you trust that they will never make any mistake in handling your sensitive information? Did you intend to send that sensitive information to them in the first place?

Is avast! the only anti-virus software doing this kind of attack on users?

No it's not the only one. For now, I've found hints on user forums about ESET's NOD32 doing exactly the same thing. There are possibly other software like that out there.

I would encourage users of such software to either change software to one that does not attack it's own users or to complain to software vendors, and to threaten them of legal issues if they don't stop using this aweful practice.