Hi, we have released an update for this issue. Client side certificates should now work without problems. We would be happy if anyone could confirm this. Thanks. Lukas.
Hi,
I can confirm that this appears to be
not working still. I'm a longtime user of Avast, and so picked up 2015 on the update cycle. When I became aware of the issue with Cert confirmations being wrong in some/all cases, and the suggestion that the Avast program updater might be the cause, I found this thread and followed the advice to just totally uninstall Avast and start with a new, fresh installation of 2015.
It did not resolve the issue, unfortunately.
When using a system to confirm certificate validity, such as
the GRC's excellent HTTPS Fingerprints service, I still see that some HTTPS enabled sites have an incorrect SHA1 fingerprint. When Avast Web Shield is active, I can confirm that -- from the differing fingerprint -- it's intercepting the HTTPS connection and providing a secondary certificate. When I disable Web Shield, I then can get the correct cert fingerprint. For the record, I'm using Firefox x64 with Win7 x64. With the Web Shield active, HTTPS connections that have the EV addition get mucked up and no longer display the green lock symbol in the URL line confirming that the EV is detected. After disabling the Shield (or just turning off the HTTPS scan inside it), certs that support the EV standard correctly appear (this specific thing was what caught my attention and caused me to look into it).
I can certainly appreciate that Avast appears to be attempting to scan traffic, including traffic that's HTTPS encrypted, before it can get to my system in order to give me as many opportunities to avoid an infection as is possible. Although HTTPS does indeed reduce the likelihood of infection by securing the connection on both sides, a compromise on the other side could, no matter how unlikely it might be, present an infection vector. I get that.
I'm concerned that it appears to be using MItM (an actual attack) to subvert another legitimate security feature (HTTPS) in order to do so. That would seem to totally undermine what HTTPS provides -- my connection is no longer secured on the far side as Avast has made itself my effective far side when this is happening. Avast needs to work in concert with, not counter to, HTTPS in order to be effective. As it is, it's now difficult to initially see if my allegedly secure connection is being hijacked by Avast or an actual attack. (Do I not show an EV because there's no EV or because Avast has hijacked my HTTPS connection and broken the EV? Is someone else hijacking the HTTPS connection?) Avast represents a legitimate security source, and an apparent MItM approach isn't the sort of thing a legitimate enterprise should be doing.
While I understand the basic idea of how HTTPS and certificates work, I'm not certain how this would be resolved such that Avast can still scan before the data (file, webpage, whatever) is actually a concern on the user system but without violating the HTTPS connection. That is why, I'm assuming, Avast appears to insert itself in between the remote server and the user. Does Avast have to become part of the CA system, so that it's not on the outside intercepting the legit connection and substituting its own?
In any event, it's still broken and I've turned HTTPS scanning off in the Web Shield until y'all figure out how to resolve the conflict.
I've just wasted a good chunk of this afternoon because of this issue, having recently upgraded avast. I was in the process of purchasing a new website ssl certificate. After installing, the fact the correct certificate was not showing up was very confusing.
However, I can shed light on why people are getting errors - the certificate that web shield is re-signing with is only sha1 encrypted - chrome is showing warning for sha1 certs - they are being phased out. Should you be using an sha2 signed certificate?
DJ
That's an interesting question. Wouldn't Avast inserting itself in the middle as it appears to be doing right now break SHA-256 cert encryption as well for the same reason it breaks SHA1? My understanding is that real cert goes into the encryption, the SHA1 fingerprint pops out. Real cert info can only come from the actual remote site -- when Avast intercepts, the cert info changes -- even if only by one character -- and so you get a (radically) different fingerprint. Even if it's more advanced, doesn't it work the same way with the SHA-256 standard? If so, then we'd still get an invalid fingerprint from Avast doing a MItM insertion, right? Because the hashed fingerprint would still be based on a different number from Avast, when compared to the real remote system. Avast would still need to be admitted to be on a Cert Authority somewhere so that it didn't have to insert itself.
