Can HTTPS scanning be problematic/exploitable?

[RejZoR]

LINK:
https://blog.hboeck.de/archives/869-How-Kaspersky-makes-you-vulnerable-to-the-FREAK-attack-and-other-ways-Antivirus-software-lowers-your-HTTPS-security.html

I've found this on Wilders, any comment on this? I've been a bit concerned regarding this myself before, considering the AV intercepts the connection and then passes it over to browser through its own encrypted connection. Does it affect avast! in any similar way as they mention Kaspersky there?

[Asyn]

Hi RejZor, see: https://forum.avast.com/index.php?topic=166999.0

Everyone else, see: https://www.avast.com/faq.php?article=AVKB190

[Be Secure]

LINK:
https://blog.hboeck.de/archives/869-How-Kaspersky-makes-you-vulnerable-to-the-FREAK-attack-and-other-ways-Antivirus-software-lowers-your-HTTPS-security.html

I've found this on Wilders, any comment on this? I've been a bit concerned regarding this myself before, considering the AV intercepts the connection and then passes it over to browser through its own encrypted connection. Does it affect avast! in any similar way as they mention Kaspersky there?

Is there any Problem with avast!?@Asyn

[DavidR]

Have you read the HTTPS FAQ link that Asyn gave you https://www.avast.com/FAQ/AVKB190 ?

[1234ava]

What about the specific Avast concerns in hboecks's article?

"I also found a number of other issues. ESET doesn't support TLS 1.2 and therefore uses a less secure encryption algorithm. Avast and ESET don't support OCSP stapling. Kaspersky enables the insecure TLS compression feature that will make a user vulnerable to the CRIME attack. Both Avast and Kaspersky accept nonsensical parameters for Diffie Hellman key exchanges with a size of 8 bit. Avast is especially interesting because it bundles the Google Chrome browser. It installs a browser with advanced HTTPS features and lowers its security right away."

[polonus]

The general situation with HTTPS is far from ideal, a lot of HTTPS site have mixed content (secure and unsecure), a lot of sites still have log-in data going unencrypted over the wires. Safer Chrome Security extension will alert you for these unsecure log-ins.
Security Header Implementations are overall missing in a lot of instances (check here: http://cyh.herokuapp.com/cyh )
or we see warnings where not best practices are followed, see the Recx Security Analyzer extension results. For Heartbleed (yes issues still around), Poodle and weak encryption via SHA-1 check here at: https://shaaaaaaaaaaaaa.com/check/
Sitereports can be had via Netcraft reports: http://toolbar.netcraft.com/site_report?url=
An online poodlescan: https://www.poodlescan.com/
Sometime the encryption keys are served from the weak side up, which makes the danger of websites being compromised even more outstanding    (so we will see still a lot of unsecure website server configurations and incompetence or cases of  bulk hosting where money comes first and security is often a last resort issue).
Online test: https://sni.velox.ch/

I do these scans every day and all of the day, I can assure you that especially the enforced HTTPS Everywhere sites may come rather insecure. What about encrypted ad malware, it becomes so much harder to detect. Another example why one needs a decent adblocker.

Also extensions like NoScript and RequestPolicy in firefox and ScriptSafe and uMatrix in Google Chrome are no longer just a protective luxury. Whenever you have learned how to toggle them rightly you have a tremendous weapon against your browser being infested with malware all sorts.

polonus (volunteer website security analyst and website error-hunter)

P.S.
Test ocsp: http://security.stackexchange.com/questions/12735/what-web-browsers-support-ocsp-stapling-are-the-privacy-and-performance-feature
Read: https://www.grc.com/revocation/ocsp-must-staple.htm

D

[polonus]

In the light of this and Avast replacing certificates with its own on HTTPS scanning - this discussion is also being again to resurge:
http://www.thesafemac.com/avasts-man-in-the-middle/
It all comes back to one issue: can you trust what you installed. I personally say yes I know what I agreed to install or know why I have to trust what I trust.
When an AV like Kaspersky's is using Open SSL libraries, when you use it for checking you have to make sure you have these fully updated (it is not done automatically!), the private key is also easilty detected without rocket technology required - unobfuscated and unprotected by NTFS permisions. Check your revokes: http://www.wilderssecurity.com/threads/revoked-certs-browsers-test.364438/ - check:  "certsrv.msc /e"  in the command prompt (minus "").

polonus

[Be Secure]

In the light of this and Avast replacing certificates with its own on HTTPS scanning - this discussion is also being again to resurge:
http://www.thesafemac.com/avasts-man-in-the-middle/
It all comes back to one issue: can you trust what you installed. I personally say yes I know what I agreed to install or know why I have to trust what I trust.
When an AV like Kaspersky's is using Open SSL libraries, when you use it for checking you have to make sure you have these fully updated (it is not done automatically!), the private key is also easilty detected without rocket technology required - unobfuscated and unprotected by NTFS permisions. Check your revokes: http://www.wilderssecurity.com/threads/revoked-certs-browsers-test.364438/ - check:  "certsrv.msc /e"  in the command prompt (minus "").

polonus

My Question is Avast! safe to use or not?do you trust it?@polonus

[CraigB]

My Question is Avast! safe to use or not?do you trust it?@polonus

Do you think he would be using it if he did not trust it

[lucD]

@BeSecure I've followed some of the various posts around this on the internet as well as the threads here and Avast's response. My technical knowledge is limited so I've had to make a judgement based on the credibility of the posters and what they say, and how I perceive it. My sense is that the protection from malware transmitted over HTTPS is more consequential than the mostly theoretical risks, most of which have anyway been addressed by Avast's representatives. Of course Avast has laid itself open to the charge of being untrustworthy by the inclusion of Safeprice in the browser extension and other dubious behaviours by the software updater and browser cleanup modules. My conclusion is that the core Avast AV is and always has been trustworthy and I choose not to install the bloat modules. Ultimately you can always switch off HTTPS scanning but, on balance, that's not a course of action I've thought fit to take.

[polonus]

@Be Secure,

Yes this discussion has been going on and through various reactions from Avast team members we know what Avast does here.
OK they have learned while implementing this.
More imp[ortant discussion is why we need https scanning now more than ever. While there will be a growing malvertising threat via https as the promotion of https is a pre-text for Google to bring in ads that cannot be blocked by adblockers anymore.
About the upcoming malvertising threat, read here: https://threatpost.com/ad-networks-ripe-for-abuse-via-malvertising/111840

And what I also stressed here: http://www.pcworld.com/article/2912092/googles-push-to-encrypt-ads-will-improve-security-but-wont-kill-malvertising.html  link article author = Lucian Constantin.

You now understand that an obscure extension like Request Policy in firefox and uMatrix in Google Chrome will gain so much weight as it will be utmost important to be able to pinpoint exactly what (3rd party) content to block.

I started to check on HTTPS Everywhere Atlas addresses  and was startled by the security issues I stumbled upon.
Misconfigurations and security header misconfigurations or the lack thereof will also produce more and more problems.
Well weakened encryption has also plaid into the hands of the global surveillance schemes, noth those led by governments as by big commercial entities,

polonus

[Dwarden]

I bet everyone here read the
https://blog.hboeck.de/archives/869-How-Kaspersky-makes-you-vulnerable-to-the-FREAK-attack-and-other-ways-Antivirus-software-lowers-your-HTTPS-security.html

so from the simple summary
* Avast breaks HTTP Public Key Pinning (HPKP) http://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
(what's the progress on this ?)
* Avast don't support OCSP stapling http://en.wikipedia.org/wiki/OCSP_stapling
(what's status on this?)
* Avast don't intercept traffic when Extended Validation (EV) certificates are used http://en.wikipedia.org/wiki/Extended_Validation_Certificate
(I know EVC can be easily fooled but at least passed as informative value for use/view in browser?)

I would like how Avast! is going to address those ?
(or if it's already resolved) because I can't find anything on those subjects
there is nothing in FAQ either https://www.avast.com/faq.php?article=AVKB190

[lukor]

Hi Dwarden,
comments in-line.

so from the simple summary
* Avast breaks HTTP Public Key Pinning (HPKP) http://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
(what's the progress on this ?)

Yes, don't currently support HPKP. We are still investigating the best way to support that. I was also trying to find a good source of information about the adoption of HPKP at present? Would you guys have any resource about the percentage of pages supporting HPKP?

* Avast don't support OCSP stapling http://en.wikipedia.org/wiki/OCSP_stapling
(what's status on this?)

We intend to add OCSP stapling support, the implementation is already finished in the internal version and will be released with the next avast version (probably Avast 2015 R3). Please note that we do support OCSP and CRL checks.

* Avast don't intercept traffic when Extended Validation (EV) certificates are used http://en.wikipedia.org/wiki/Extended_Validation_Certificate
(I know EVC can be easily fooled but at least passed as informative value for use/view in browser?)

This is surprising to me that this is considered as a negative by some. We don't scan EV certificates, the fact that a certificate is evaluated as EV is a trigger for us to trust the connection and do not interfere with it. It is by design and disabling this is very easy. There is a INI option for that. Detecting an EV cert and correctly ignore such connections from the scan is fairly difficult, yet we though users would value this effort. If the bank (or other company) on the other side of the connection has already verified its identity enough for the CA to issue an EV certificate to it, we wanted to keep the connection private.

Truth is that even EV signed connection can lead to hacked pages, but it is always about balance and for us this was the limit we chose.

Would you like to have every connection to go via WebShield's scanning? Even EV ones?

Lukas.