Thanks for the reply, i appreciate it. I think the concern stems from the fact that from appearances avast gives the impression it is scanning HTTPS traffic despite that setting being switched off, you say it’s not but the evidence still points to the contrary. Whether that be the web/mail shield root certificate imported from certmgr or this newer SSLKEYLOGFILE injection method. Many of us, myself included, cannot quite fathom why these things are there when we don’t have HTTPS scanning enabled and have never had it enabled. By the way, that SSLKEYLOGFILE also shows up for firefox when viewed through process explorer under the environment tab.
@ no face
As Lukas stated Avast has to be prepared to scan https traffic should the user have it enabled or re-enables https scanning be that web or email secure traffic.
He also stated that they might change this to disable the option if https scanning is disabled and as he said it could require a system restart on some machines to do that. Plus he didn’t think this advisable.
He also said in his EDIT that this “You are using an unsupported environment variable:” notice is no longer flagged in the chrome canary builds. So it shouldn’t be seen on the regular builds after canary other builds after that.
I saw this on win10, running chrome stable and AVG free 19.7, but now it doesn’t appear…
Avast indeed scans HTTPS traffic and we strongly believe it is a total must-have for any AV.
Please, consider this before disabling HTTPS scanning in WebShield.
When the user disables it, you really should take it serious that they do NOT want their private session keys to be scanned.
It is sad to see this being done. Why do you continue to scan after a polite EXPLICIT no?
This happens on Firefox as well, and personally, to me as a user this is a breach of trust:
https://forum.avast.com/?topic=229164.0
https://i.imgur.com/LLIGs2Y.png
Why do you force this on unconsenting users? A polite no means exactly no.
Please patch the Avast Free Edition, so it cannot hook browsers when the user disagreed to MITM or logging of session keys.
Any other excuse than this being a bug unacceptable.
HTTPS, especially in browsers is exactly the one thing on my PC where I don’t want ANY anti-virus vendor inside.
Edit:
- Injecting at all when the WebShield is not even installed is, pardon my French, just lazy.
- Installing modules like Webshield or removing them requires a restart.
- When a module is missing, inject should never happen (check settings/what is installed).
So explaining from a point of view where WebShield is installed doesn’t do any justice.
The explanation is like: “Yes I opened your letters, but I didn’t read them.”
I don’t like it, it destroys trust, no matter how hard someone promises not to read.
Being unable to tell what listens on that output, it completely destroys the idea of ephemeral ECDH and forward secrecy.Yes I understand that you promise it is not reading any data when WebShield is off, but adding 10 lines of code to the injector binary is this hard that you rather have the program behave suspiciously?
People’s trust in AV vendors is at a new low, especially after the green “K” from Russia was caught recently injecting JS in every website with a trackable user ID.
I know Avast is not like that, so please don’t take programming shortcuts in your code. I know for granted that your developers can implement a function to the injector binary that checks if WebShield is installed.What is less than 1 hour of work worth, compared to having users not trust your software?
Please fix it soon! Yes I am serious, it creates exposure, especially when it’s not used and needlessly runs. “Trust me, user.” Is the worst PR approach.
I am so glad this will be addressed in a fix now:
https://forum.avast.com/index.php?topic=229164.msg1520789#msg1520789
Thanks igor!