SSL/TLS MITM/Inspection - Is Avast any better than Superfish at validating?

[REDACTED]

A couple of things, now that the Superfish debacle has been exposed for Lenovo products.

1. Does Avast do any better job at injecting its own CA and protecting its private key used to issue the "replacement" or "proxy" certificates to your browser?
2. Does Avast do any better job at validating those replacement certs?

and lastly,
3. There MUST be a better way for users to 1-click DISABLE SSL/TLS interception by Avast for explicit exception or "whitelisting" websites -- specifically, banking and e-commerce sites the user routinely visits.

Avast essentially makes SSL Observatory and other HTTPS-always-on browser plugins useless because the certs are hijacked by Avast before they are/can even be inspected.

To be honest, I trust Microsoft and Mozilla and Opera and Apple and Google to do a far, far better job of validating and authenticating certificates than I do Avast.

So how is Avast any better than Superfish/Komodia in this regard, and why should I trust Avast over the browser companies themselves?

[essexboy]

Try this and see what Avast states https://revoked.grc.com/

It is a checker created by GRC

One such site is https://revoked.grc.com. It has been set up by Gibson Research so that users can test whether their browsers and other software fail to check the revocation status of SSL certificates. If the site is loaded without a browser warning then certificate revocation is not properly verified.

Google no longer checks certificates

[REDACTED]

Wasn't referencing Avast doing basic OCSP/revocation checks. Was referencing Avast possibly notching or even using the same MITM hackware from Komodia.

https://www.eff.org/deeplinks/2015/02/dear-software-vendors-please-stop-trying-intercept-your-customers-encrypted

The Komodia library modified a PC's network stack by adding a new root Certificate Authority certificate. Poor choices in both the way the certificate and underlying code were designed caused most browsers to trust fraudulent certificates that otherwise would have generated warnings. Flagrantly fraudulent certificates got a pass as long as they (a) contained the same easily extracted private key baked into the app or (b) contained the name of the targeted website in certificate's alternate name field. Malicious hackers could exploit this failure to masquerade as secure pages for Bank of America, Google, or any other website on the Internet. As a result, attackers had an easy way to wage man-in-the-middle attacks against otherwise secure HTTPS connections.

Is Avast immune to similar attacks is my question. I sure as heck hope not.

This only applies if you're scanning SSL enabled.

[polonus]

Hi Mike808,

How can you tell that Google does a far better job here as they stripped certificate revocation from Google Chrome since 2012. Read the backgrounds here: http://www.zdnet.com/article/chrome-does-certificate-revocation-better/
Re: https://www.imperialviolet.org/2012/02/05/crlsets.html
The problem here is called the cloud and it was proven that also cloudflare could not be trusted - now we have the Komodia comedy or rather tragedy  and already some av vendors fell through like Bitdefender - although their root certificates are from Thawte - I detected junk via a JRT scan on firefox for Bitdefender, but for Chrome I could not establish it  .
SDK hijacking should not be possible and we should have a guarantee there, but we have none. How to restore trust with the end-user?
We have to thank media manipulators here when toolbars etc went and only Google approved extensions can be installed via Google in the browser, these schemes were introduced en web beacons were being hacked, all for some to sit on an even higher pile of cheap money gained.  Now there is all sort of software to please the ad-marketeers that started to rule all over the Interwebs: http://stl-manipulation.software.informer.com/pages/45/
I think we will have a hard time to stop mixing the sheep and the goats.
As far as I am aware Avast has not reported problems here.

polonus

[polonus]

Testing here almost seems a parody now: http://url.komodia.com/test-a-site/

polonus

[lukor]

Hi Mike808,

thanks for the question. We are just preparing more detailed page about all the internals of how Avast's HTTPS scanning works - so I'll post the link here as soon as it is published later this week.

In short:
There is a huge difference between Avast a Superfish.

Mainly because Superfish reportedly used the same private key in all their issued certificates. This allows an attacker to create a web page, pretending to be any domain, such as fake google.com, signed by fake certificate and yet trusted by any user with Lenovo's Superfish. Pages like this test can exist for Superfish: https://filippo.io/Badfish/

None of the above is possible with WebShield's HTTPs scanner - the certificate used by webshield is unique for every installation and even gets regenerated when avast is reinstalled. No two users use and trust the same certificate.

Also, most of the certificate attributes, such as validity dates, common name, subject etc. are preserved and verified by the browser no matter if HTTPS scanning in avast is turned ON or OFF. The issuer is verified
in WebShield using Windows native functions from CryptoAPI, against the Windows Certificate Store - the same certificate store that Internet Explorer and others (Chrome) use as well. The certificate that we use to certify the page for the browser never leaves your pc, nor is transfered on the wire. Yes, it is accessible to apps running on the same machine with the Administrator rights, but it is worth noting, that such apps can also create and add any number of their own trusted certificates into the certificate store.

Moreover, we have a list of banking sites, that are automatically ignored. WebShield does not scan your bank! If your bank is not in this list, please write to me, we'll add it to the list.

We also try hard to ignore sites with EV certificates. The detection here is done live based on the certificate seen previously from the same domain/host. As soon as we see the site using an EV certificate we stop scanning anything more from that same site -- all future connections are automatically ignored. The motivation here is the same - if the company (the server) took all the efforts to obtain EV certificate, it's probably their job to keep their site clean.

We are working on a more detailed FAQ page, I'll update you here with link in a few days. Please feel free to post any concerns about the security of the whole scanning process - we really want this to be trustworthy service, and in case any problem is found, we'll do our best to quickly fix it.

Just wanted to say, that there is nothing safe in the mere fact, that the connection is encrypted by one of the cyphers negotiated during HTTPS connect. Anyone can create a HTTPS page and host anything he/she wants on that page. In case the malware distributor also owns the domain (something like www.malwaredistributionisfun.com) the certificate can be obtained for free.

Lukas

[REDACTED]

Thanks for the insights. Things I'd like to explore are the corner cases - those are the ones exploited by the "bad guys".

Things like the access protections around your CA's private key. Cross-site interactions with SAN certs, preventing negotiation of weak ciphers (or worse, the NULL cipher), "safe" data from a secure connection leaking to an insecure one (Although that's more of a browser/DOM issue).

Things like I should be able to use SSL observatory plug-ins in my browser and have them handle the original remote cert, not validating the avast-ized version.

Agree that the EV issue is thorny. In the end, we decided to allow EV certs through, given their increased assertions.

Avast might consider features like removing/disabling CA trust from unlikely issuers, and 1-click whitelisting.

And you don't white list my bank, and I won't name them here in a public forum. Admins/Avast can reach out to my profile email for a less public discussion. Thanks!