Avast WEBforum
Consumer Products => Avast Free Antivirus / Premium Security (legacy Pro Antivirus, Internet Security, Premier) => Topic started by: Amgeek on August 24, 2019, 07:42:28 PM
-
You are using an unsupported environment variable: sslkeylogfile. Stability and security will suffer
Uninstall Avast - it goes away
Reinstall Avast it comes back.
Latest versions of Chrome and Avast.
-
Not enough information:
What version of chrome?
What version of avast?
what version of sslkeylogfile? Did you set this to automatically run?
-
Not anything I can confirm?
-
I can indeed confirm this. Having the same issue. This post explains the issue: https://techdows.com/2019/08/chrome-you-are-using-an-unsupported-environment-variable-sslkeylogfile.html
-
I can indeed confirm this. Having the same issue. This post explains the issue: https://techdows.com/2019/08/chrome-you-are-using-an-unsupported-environment-variable-sslkeylogfile.html (https://techdows.com/2019/08/chrome-you-are-using-an-unsupported-environment-variable-sslkeylogfile.html)
When you use canary builds, it's quite possible to run into problems. No program grantees comparability with canary builds.
-
Avast 19.7.2388 See photo attached for sslkey file location
Chrome
Google Chrome is up to date
Version 78.0.3887.7 (Official Build) dev (64-bit)
-
I've reported this to Avast. Let's see if that helps.
-
Are you using chrome stable or a canary build?
-
Official? (see above)
-
Does that (dev) in the about line indicate DEVELOPER? Is that Canary?
The machine's owner is no techie. No need for any but standard issue browser. Would be a mystery how they got it. If they have it how do I get rid of it?
-
It seems that the latest version of Chrome is 76.
If the machine owner is running Chrome 78, it would be canary, since 77 is still in beta. Also, see:
https://chromereleases.googleblog.com
or
https://www.whatismybrowser.com/guides/the-latest-version/chrome
-
Thanks, will give that a try when the machine next passes this way. Will post back. Could be a week or so.
-
It seems that the latest version of Chrome is 76.
If the machine owner is running Chrome 78, it would be canary, since 77 is still in beta. Also, see:
https://chromereleases.googleblog.com
or
https://www.whatismybrowser.com/guides/the-latest-version/chrome
what a shame, dev is not canary - it is beta; basically insight in what is waiting for you in 3 months. Same happens with TLS 1.1 and a lot of bank sites were warned about problem before it hits them on DAY X.
I would like, as a subscriber - to make sure that Avast team will care about this annoying banner without forcing users to install current version of browser and be "surprised" with same message over 3 months
-
I can confirm this issue, using Chrome Dev.
-
I can confirm this issue, using Chrome Dev.
As already stated, there aren't any guarantees that anything will work if you're using a Developers version of a program.
Developers versions are Beta versions. If it works, great if not, wait for the final release. Or, use a released final version.
-
stable version shows the same warning...
-
stable version shows the same warning...
Not on the 4 computers I'm using in my home ???
-
Reported on The Following site as well, regarding Avast & Avg
https://techdows.com/2019/08/chrome-you-are-using-an-unsupported-environment-variable-sslkeylogfile.html
-
Yeah, i would very much appreciate some honesty on this and whether they are still scanning and transmitting https traffic against the express wishes of the user.
-
Hi guys,
Avast indeed scans HTTPS traffic and we strongly believe it is a total must-have for any AV. We currently block ~42% of all infections over HTTPS, and with phishing, it is even more, 73%. Please, consider this before disabling HTTPS scanning in WebShield.
As to the SSLKEYLOGFILE variable, yes, we do use it to do the scanning for Chrome, I don't really understand why Chrome itself says it is unsupported - it's been part of the browser for many years. However, we also support MITM. If chrome will continue to propagate this warning to stable, and from our current discussions with chrome developers, it seems that they do not have such intention right now, we will, of course, disable this method in favor of MITM. However, MITM is the worse of these two, from the user experience and performance-wise. I don't see any reason why any user would prefer MITM over this method.
Yeah, i would very much appreciate some honesty on this and whether they are still scanning and transmitting https traffic against the express wishes of the user.
No face, we do not scan nor transmit https traffic against the wishes of the user. Once https scanning is disabled (or the whole webshield) we don't scan it. Period.
We might change the code and stop injecting the variable into browser's process, once HTTPS scanning is disabled - however, this would be mean, that enabling HTTPS scanning would require chrome process to be restarted -- which on many machines means the whole system restart. I find this to be a big disadvantage to this approach.
stable version shows the same warning...
Based on our communication with devs from google, there is currently no plan to have this in stable. Jvidal, your finding is disturbing - I am sure you wouldn't write it here if it weren't true - could you, please, post a screenshot with the version visible? Thanks a lot!
Lukas
Update: it seems that the warning is no longer in chrome canary builds.
-
Yeah, i would very much appreciate some honesty on this and whether they are still scanning and transmitting https traffic against the express wishes of the user.
No face, we do not scan nor transmit https traffic against the wishes of the user. Once https scanning is disabled (or the whole webshield) we don't scan it. Period.
We might change the code and stop injecting the variable into browser's process, once HTTPS scanning is disabled - however, this would be mean, that enabling HTTPS scanning would require chrome process to be restarted -- which on many machines means the whole system restart. I find this to be a big disadvantage to this approach.
Lukas
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:
1) Injecting at all when the WebShield is not even installed is, pardon my French, just lazy.
2) Installing modules like Webshield or removing them requires a restart.
3) 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!