Avast WEBforum
Consumer Products => Avast Free Antivirus / Premium Security (legacy Pro Antivirus, Internet Security, Premier) => Topic started by: REDACTED on November 06, 2014, 02:57:03 AM
-
I recently upgraded to Avast Internet 2015 and was having problems getting HTTPS scanning to work under the Web Shield active protection.
Firefox gave me security certificate errors when I went to HTTPS sites. In some cases, I could acknowledge the risks and create an exception; in other cases I couldn't and the only option was to exit the page.
I can get HTTPS scanning to work if I export the Mail Shield SSL cert and then import it into Firefox and give it the authority to "identify web sites."
Is this how HTTPS scanning is supposed to be configured?
If this is working correctly, it appears I no longer have insight into the security certs of sites I visit, as that is seen [and validated] only by the Avast HTTPS scanner, correct? I would think it would be better to have that insight.
What could/should I be doing different?
Thanks
-
There is a new version that addresses this but still in beta at the moment.
https://forum.avast.com/index.php?topic=159263.0
-
Thanks for the advance notice on the updated version.
I installed it the other day without any problems.
The HTTPS scanning error with Firefox 33.1 appears to still exist, as I still had to manually import the Avast! Web/Mail Shield Root cert into Firefox and give it the authority to identify web sites.
I'm told from another thread this is how it's supposed to work. For whatever reason, Avast Internet didn't import the cert correctly into Firefox in the upgrade.
-
Thanks for the advance notice on the updated version.
I installed it the other day without any problems.
The HTTPS scanning error with Firefox 33.1 appears to still exist, as I still had to manually import the Avast! Web/Mail Shield Root cert into Firefox and give it the authority to identify web sites.
I'm told from another thread this is how it's supposed to work. For whatever reason, Avast Internet didn't import the cert correctly into Firefox in the upgrade.
You saw this post ? {Reply #24}
https://forum.avast.com/index.php?topic=159528.msg1147632#msg1147632
-
Hi PCPhanatic1414,
before addressing your problem (why in your case the certificate is not injected into Firefox automatically), I'd like to comment on the other concern, you've mentioned:
I can get HTTPS scanning to work if I export the Mail Shield SSL cert and then import it into Firefox and give it the authority to "identify web sites."
Is this how HTTPS scanning is supposed to be configured?
If this is working correctly, it appears I no longer have insight into the security certs of sites I visit, as that is seen [and validated] only by the Avast HTTPS scanner, correct? I would think it would be better to have that insight.
Hi, WebShield only valides the parts that it really have to validate and changes - this is the signing certificate. Other things are left unchanged and it is left on the browser/user to validate it - such as common name, expiration dates, etc.
What we do in HTTP Scanner (WebShield), is obtaining the certificate from the server (say: facebook), and re-signing it with our root certificate. Originaly it might be: Issuer: Facebook, signed by: Digicert, now it will be Issuer: Facebook, signed by: Avast.
All the information from the original certificate are left intact, such as: validity dates,
Subject:
CN = *.facebook.com
O = "Facebook, Inc."
L = Menlo Park
ST = CA
C = US
All extensions, alternate names, such as:
Not Critical
DNS Name: *.facebook.com
DNS Name: facebook.com
DNS Name: *.fbsbx.com
DNS Name: *.fbcdn.net
DNS Name: *.xx.fbcdn.net
DNS Name: *.xy.fbcdn.net
DNS Name: fb.com
DNS Name: *.fb.com
Of course, since we have changed the root certificate, something is indeed lost, but many things remain for you to inspect. Such as if the name in the original certificate didn't match, you can still verify if it matches close enough so that you'll trust it or not.
If the original certificate was signed by an untrusted root, it will be signed now also by an untrusted root (here being the "avast! Web/Mail Shield Untrusted Root" certificate). It's not exactly the same as without HTTPS Scanner, but still as close as we were able to do it.
Do you have any ideas how we should improve this process so that more information will be preserved in the newly created certificate? What is the main thing that you are missing? Give me an example, we can think about the possibilities how to improve the method.
Thanks a lot,
Lukas.
-
Lukas,
Thanks for the helpful explanation on what details of a site's cert are evaluated and passed on in HTTPS scanning.
It's good to know that specific details - common name, validity dates, etc. - are passed on for the user to review. I had assumed that detail was held back by Avast. At first glance, I think the common name and issue/expiry dates are rather important; I remember focusing on those details after the Heartbleed vulnerability was announced in April 2014.
I'll keep experimenting with this new feature and compare what cert data is available with or without the HTTPS scanning on.
Thanks again.
-
Thanks,
we've considered adding the original cert authority (maybe as a string - e.g. "originaly signed by DigiCert") somewhere into the newly create certificate -- possibilities are somewhere into the Subject field. Still don't know if I should support that or not - with that we would be modifying the certificate on our side and maybe someone might not be so happy with that ... still evaluating the option.
Lukas.
-
I think this has something to do with my problem. Maybe someone has a SIMPLE answer.
Since updating to Avast 15, the Web Shield is blocking most websites in Firefox, including Avast, Google, Netflix, Amazon..... I get an Untrusted Connection message in Firefox, and despite the presence of the option to create an exception, I'm unable to store any exceptions (though that may be a Firefox problem).
I can overcome this by disabling the Avast Web Shield, which of course is not a good idea, or by adding each web site to the exclusion list in Avast. But, should I have to do that? Is there an easier way to overcome the problem?
-
A significant problem that I've found with HTTPS Scanning is that it interferes with 'token' based authentication systems and client certificate systems.
-
A significant problem that I've found with HTTPS Scanning is that it interferes with 'token' based authentication systems and client certificate systems.
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.
-
Thanks,
we've considered adding the original cert authority (maybe as a string - e.g. "originaly signed by DigiCert") somewhere into the newly create certificate -- possibilities are somewhere into the Subject field. Still don't know if I should support that or not - with that we would be modifying the certificate on our side and maybe someone might not be so happy with that ... still evaluating the option.
Lukas.
Lukas,
I would like to add my 2 cents here. Some MITM attacks occur using slightly altered certs, so wiping out any details at all about the original cert is not something I personally feel comfortable with. Is there no way you can simply add your approval to the original cert, instead of altering and reissuing it?
Thank-you,
D
-
Lukas,
I would like to add my 2 cents here. Some MITM attacks occur using slightly altered certs, so wiping out any details at all about the original cert is not something I personally feel comfortable with. Is there no way you can simply add your approval to the original cert, instead of altering and reissuing it?
Thank-you,
D
I share this concern. I don't like the fact that Avast presents me a modified certificate. It's very hard to manually verify the authenticity of a certificate (which I do) if I'm not presented the original certificate, but a modified certificate missing original information and issued by Avast.
-
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
-
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 (https://www.grc.com/fingerprints.htm), 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.
-
I tweeted at @avast_antivirus today to enquire about this issue, they got a bit mixed up and thought I was asking about disabling HTTPS scanning, but eventually when I pointed out this post (http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually-sunsetting-sha-1.html) on a Google blog they directed me to this thread.
As we've had similar problems with a new web filter at my workplace I thought I'd chime in with my 2 cents based on the research I've done related to that.
A Man-in-the-Middle attack (http://en.wikipedia.org/wiki/Man-in-the-middle_attack#Implementations) such as what Avast and other HTTPS scanning web filters perform is literally the only way you can scan the content of an HTTPS connection. This involves the web filter essentially setting itself up as a certificate authority on your local computer (in the case of Avast) or network (in the case of enterprise products like Sophos UTM for example), and then switching out the certificate of any given HTTPS web site with one it generated, so that it has the encryption keys to be able to decrypt the content for scanning. If you don't want it to do that, the only other thing available is a thing called Server Name Indication (http://en.wikipedia.org/wiki/Server_Name_Indication), which lets the web filter see the name of the server the connection is going to, but that usually isn't nearly enough information for it to decide whether it should allow or block it.
With an increasing number of web sites switching to HTTPS only (encouraged by initiatives such as this (https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure) and this (https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/)) this issue is only going to get more pronounced. The bottom line is, do you care more about your connection being encrypted or your computer being protected from viruses and malware? You already trust avast to some extent, or you wouldn't have installed it on your computer - if they wanted to steal your data they could already do that a thousand times over.
I think the least bad compromise you can come up with is to enter HTTPS sites you really don't want Avast to scan (like your online banking website for example) into the URL Exclusions list in the settings.
Note: I am not an employee of or affiliated with Avast or Sophos, I'm just an IT Technician who has encountered these similar issues at work.
-
I tweeted at @avast_antivirus today to enquire about this issue, they got a bit mixed up and thought I was asking about disabling HTTPS scanning, but eventually when I pointed out this post (http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually-sunsetting-sha-1.html) on a Google blog they directed me to this thread.
As we've had similar problems with a new web filter at my workplace I thought I'd chime in with my 2 cents based on the research I've done related to that.
A Man-in-the-Middle attack (http://en.wikipedia.org/wiki/Man-in-the-middle_attack#Implementations) such as what Avast and other HTTPS scanning web filters perform is literally the only way you can scan the content of an HTTPS connection. This involves the web filter essentially setting itself up as a certificate authority on your local computer (in the case of Avast) or network (in the case of enterprise products like Sophos UTM for example), and then switching out the certificate of any given HTTPS web site with one it generated, so that it has the encryption keys to be able to decrypt the content for scanning. If you don't want it to do that, the only other thing available is a thing called Server Name Indication (http://en.wikipedia.org/wiki/Server_Name_Indication), which lets the web filter see the name of the server the connection is going to, but that usually isn't nearly enough information for it to decide whether it should allow or block it.
With an increasing number of web sites switching to HTTPS only (encouraged by initiatives such as this (https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure) and this (https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/)) this issue is only going to get more pronounced. The bottom line is, do you care more about your connection being encrypted or your computer being protected from viruses and malware? You already trust avast to some extent, or you wouldn't have installed it on your computer - if they wanted to steal your data they could already do that a thousand times over.
I think the least bad compromise you can come up with is to enter HTTPS sites you really don't want Avast to scan (like your online banking website for example) into the URL Exclusions list in the settings.
Note: I am not an employee of or affiliated with Avast or Sophos, I'm just an IT Technician who has encountered these similar issues at work.
Thanks for an interesting and easy to understand explanation to a very complex issue. :)
-
I installed Windows 10 yesterday. Ever since then I have not been able to use gmail, google or amazon in Firefox. There is a problem with the https connection. For example when trying to connect to google, Firefox gives this error message.
'Secure Connection Failed. An error occurred during a connection to www.google.co.uk. Peer's certificate has an invalid signature. (Error code: sec_error_bad_signature). The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the web site owners to inform them of this problem.'
I was altered to this forum from a Firefox forum. And despite a history of the same problem on this forum, this is the first time I have had the problem. As a test I turned off Avast, and the error message disappeared and I was able to use those websites as usual. So Windows 10 does not seem to be an issue. Chrome does not have this problem. But I cant help thinking it's a bit of a cop out having to include URL exceptions in Avast. Is there any chance that the problem will be fixed in a next update of Avast please? Many thanks.
-
phillipp, a forum moderator over at Firefox, has cracked it! The fix has worked for me, happy with that, here's what he wrote ;)
hey, please disable https scaning within avast:
Open the Avast dashboard on the affected system.
Select Settings from the left sidebar menu.
Switch to Active Protection.
Click on Customize next to Web Shield.
Uncheck the "Enable HTTPS Scanning" option and click ok.
http://www.ghacks.net/2014/10/31/avasts-https-scanning-interferes-with-firefox-and-other-programs/
-
phillipp, a forum moderator over at Firefox, has cracked it! The fix has worked for me, happy with that, here's what he wrote ;)
hey, please disable https scaning within avast:
Open the Avast dashboard on the affected system.
Select Settings from the left sidebar menu.
Switch to Active Protection.
Click on Customize next to Web Shield.
Uncheck the "Enable HTTPS Scanning" option and click ok.
http://www.ghacks.net/2014/10/31/avasts-https-scanning-interferes-with-firefox-and-other-programs/ (http://www.ghacks.net/2014/10/31/avasts-https-scanning-interferes-with-firefox-and-other-programs/)
It certainly wasn't "cracked" by anyone at Firefox. That temporary bypass has been mentioned on this forum for quite some time. :)
-
Hi
I am having the same certificate verification problem with AVAST HTTPS scanning module with the Skype & Mclaren F1 websites...
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.
I hold the same reservations over the MITM technique employed (as quoted above), however HTTPS does not leave a true alternative. REALLY, My MAIN problem is: that Avast is sometimes using a SHA1 coding for it's certificates which is causing severe verification issues within Chrome (and Firefox?). Chrome is rightly flagging SHA1 as a security risk on Secure sites.
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????
SHA1 is a universally recognised WEAK(COMPROMISED?) coding platform that is being phased out of existence. It surprises me that a SECURITY COMPANY would choose to use this certificate format for one of it's most critical modules. (For reference: When a site works correctly, the Avast coding is the newer SHA256 - Why are Avast still using SHA1 on some sites????)
I am a relative newbie here on the forums, but consider myself above average on PC matters and fairly clued in on aspects of security etc.
Howard
-
How does Avast protect its root certificate so that it can't be used by a malicious user to sign fake certificates?
-
How does Avast protect its root certificate so that it can't be used by a malicious user to sign fake certificates?
https://www.avast.com/en-us/faq.php?article=AVKB190#artTitle
does it help?