Author Topic: Avast causing Chrome to warn "You are using an unsupported environment variable:  (Read 9643 times)

0 Members and 1 Guest are viewing this topic.

Offline jvidal

  • Sr. Member
  • ****
  • Posts: 309
stable version shows the same warning...
« Last Edit: August 29, 2019, 08:12:51 PM by jvidal »

Offline bob3160

  • Avast √úberevangelist
  • Probably Bot
  • *****
  • Posts: 46319
  • 61 Years of Happiness
    • bob3160 Protecting Yourself, Your Computer and, Your Identity
stable version shows the same warning...
Not on the 4 computers I'm using in my home ???
Free avast! Security Seminar: http://bit.ly/2N1eaR2  -  Important: http://www.organdonor.gov/ -- My Web Site: http://bob3160.strikingly.com/ - Win 11 Pro v21H2 64bit, 16 Gig Ram, 1TB SSD, AvastOmni 21.6, How to Successfully Install Avast http://goo.gl/VLXdeRepair & Clean Install https://goo.gl/t7aJGq

Offline Patrick2

  • Poster
  • *
  • Posts: 490
Windows 10 Pro 64bit 1909 18363.476, Intel I7 7700 Nvidia Geforce 1050 16gb DDR4, WD 250GBSSD, 1tb Storage, Avast Free 19.8.2393
HP Omen Laptop Intel I7 7700HQ, 8gb Of Ram Windows 10 Home x64 1909 18363.476 128GB SSD, 1tb Storage, Avast Free 19.8.2393

Offline no face

  • Newbie
  • *
  • Posts: 16
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.

Offline lukor

  • Avast team
  • Super Poster
  • *
  • Posts: 1886
    • AVAST Software
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.
« Last Edit: August 30, 2019, 12:17:57 PM by lukor »

Offline no face

  • Newbie
  • *
  • Posts: 16
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.

Offline DavidR

  • Avast √úberevangelist
  • Certainly Bot
  • *****
  • Posts: 85966
  • No support PMs thanks
@  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.
Windows 10 Home 64bit/ Acer Aspire F15/ Intel Core i5 7200U 2.5GHz, 8GB DDR4 memory, 256GB SSD, 1TB HDD/ avast! free 21.9.2494 (build 21.9.6698.703) UI 1.0.672/ Firefox, uBlock Origin, uMatrix/ MailWasher Pro/ Avast! Mobile Security

Offline jvidal

  • Sr. Member
  • ****
  • Posts: 309
I saw this on win10, running chrome stable and AVG free 19.7, but now it doesn't appear...

Offline inactive-user

  • Beta Tester
  • Newbie
  • *
  • Posts: 16
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



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.
« Last Edit: September 01, 2019, 07:32:59 PM by radames »
they don't care to fix issues, nothing but false promises and delay tactics

Offline inactive-user

  • Beta Tester
  • Newbie
  • *
  • Posts: 16
I am so glad this will be addressed in a fix now:
https://forum.avast.com/index.php?topic=229164.msg1520789#msg1520789

Thanks igor!
« Last Edit: September 28, 2019, 10:25:00 AM by radames »
they don't care to fix issues, nothing but false promises and delay tactics