Please stop sniffing Firefox TLS, SSLKEYLOGFILE aswMonFltProxy, Enterprise Roots

[inactive-user]

Why does Avast inject my Firefox processes with this?
SSLKEYLOGFILE \\.\aswMonFltProxy\[REDACTED_HEX_STRING]

I have explicitly told the Web security module to NOT interfere with HTTPS connections.
Then the module was uninstalled.

Why are you still logging my session keys to STDIO into Avast Free with only file system protection enabled?

I cannot tell you how disappointed I am && starting to lose my trust in this company.
Seriously tell me this is a BUG and patch it. If i disable a "feature", then don't secretly do spy in background.

My TLS session keys are my own, please never scan them without my okay or when I already said no.

greetings,
radames

[igor]

https://forum.avast.com/index.php?topic=229038.msg1517556#msg1517556

[inactive-user]

https://forum.avast.com/index.php?topic=229038.msg1517556#msg1517556

Thanks for the link igor!

However as stated by myself in the other thread as well now:
When the user disables it, take it as the user does NOT want their private session keys to be scanned.
Why do you continue to scan after EXPLICIT no?

To me as a user this is a breach of trust regardless. Why do you force this on unconsenting users? No means no.

Please patch the Avast Free Edition, so it cannot hook browsers when the user disagreed to MITM or logging of session keys.

[igor]

As Lukas was trying to explain, no does mean no - no scanning is happening when that option is disabled (and the key is not used for anything else either).
The inject is happening before/without consulting that option, for reasons Lukas also mentioned (if it was otherwise, then - if the scanning was enabled afterwards - the whole browser would have to be restarted; that scenario may be unlikely for you personally, but there are other cases where exactly the same applies - say WebShield is stopped, possibly temporarily for 10 minutes - where it is a bigger concern).

[inactive-user]

The inject is happening before/without consulting that option

Thanks for taking the time to reply back again! Please let me explain though why it still upsets me a lot:

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.

[igor]

Well the linked post was about the "SSL scanning" checkbox - which can be changed at any time (though yes, most people don't do that). If WebShield isn't installed at all, then indeed it's completely useless.

Now I'm not saying that the behavior shouldn't be improved to avoid some concerns (plus when dealing with sensitive stuff, it's better to avoid stuff that's not needed - e.g. for the case there was a bug). But honestly, from a developer's (i.e. mine) perspective - not seeing that environment variable in the list doesn't suddenly guarantee that nobody else is watching. Technically, most low-level programs (such as those having its own drivers) can find other ways to interfere with other processes.

[inactive-user]

It doesn't guarantee that someone else is watching, but it helps everyone trust that Avast is not watching

Thanks for you immense patience and being so friendly. A little bit of me hopes that your colleagues will fix it in a next update.
I'll reduce my activity for now. High praise for reaching out to users on a Sunday though!

[inactive-user]

I see you people still don't care, injecting forced settings into my browser when only file system protection is installed??



This behaviour is outrageous! Uninstalling Avast immediately removed the setting of your MITM certificates. Can you guys seriously stop injecting and sniffing browser traffic when the module is NOT installed? Ffs...

[igor]

The change has been implemented internally, but simply hasn't made it into 19.8.
It's not such a tiny tweak as you seem to imagine - so it must be properly tested.
Will be included in the next update.

[inactive-user]

Thank you Sir, I didn't know this, thought it was not going to happen anymore.
Sorry for all the trouble & hard word and thanks for taking our concerns about it seriously

[inactive-user]

And today more bad news that having AVAST in your browser, in any way at all, is a very bad thing:
https://forum.avast.com/index.php?topic=230901.0
https://forum.avast.com/index.php?topic=230913.0

@igor
Will 19.9.x finally address these issues? It's been 3 Months and I am still EXTREMELY interested in this Problem being resolved. I do not want anything to touch my TLS/SSL settings, at all.

Thanks for listening, but I really need that change

[lukor]

Hi Radames,
we have it ready for 19.9. When you disable SSL scanning or uninstall WebShield, the SSLKEYLOGFILE variable is no longer inserted into your environment. When re-enabled, the user needs to restart all browsers. Hopefully, this is something a standard user can understand and will not expect Avast to protect him in the meantime.

Not sure if you are aware that setting an environment variable is something any user can do, modifying your chrome .lnk file is straightforward, no additional rights are needed, just user. Anything that runs on your machine can do it and make the browser run with SSL logging enabled (no admin rights required). When Avast is running, you are protected from that; avast overrides the variable with a virtual file that is unreadable to all processes.

Last note: is there a reason this thread has a title "Please stop spying on my Firefox (SSLKEYLOGFILE aswMonFltProxy)"?  With WebShield turned off or SSL scanning disabled, we don't touch the SSLKEYLOGFILE entries, and therefore, Avast can not be spying on you. I find such a subject quite misleading and damaging. If, on the other hand, you would think that Avast is reading your data in this scenario when not instructed to do so, please contact me, and we will address it as well.

[inactive-user]

Hi Radames,
we have it ready for 19.9. When you disable SSL scanning or uninstall WebShield, the SSLKEYLOGFILE variable is no longer inserted into your environment. When re-enabled, the user needs to restart all browsers. Hopefully, this is something a standard user can understand and will not expect Avast to protect him in the meantime.

Hello @lukor
Thank you, this is amazing that you really fixed it 

Not sure if you are aware that setting an environment variable is something any user can do, modifying your chrome .lnk file is straightforward, no additional rights are needed, just user. Anything that runs on your machine can do it and make the browser run with SSL logging enabled (no admin rights required). When Avast is running, you are protected from that; avast overrides the variable with a virtual file that is unreadable to all processes.

You are correct of course, but I check my system regularly and no one else has access to it. It is just nice to know that good software doesn't show such behaviour when these features are disabled.
The average user probably doesn't run GMER, process explorer and the like either. It all started when I saw that settings in Firefox were active that I never enabled. And the memory hook does more than just add the SSL logging, it also enables security.enterprise_roots.enabled;true which allows any certificate in the Windows DB to be trusted, but I only want Firefox internal NSS libraries to be used.

Last note: is there a reason this thread has a title "Please stop spying on my Firefox (SSLKEYLOGFILE aswMonFltProxy)"?  With WebShield turned off or SSL scanning disabled, we don't touch the SSLKEYLOGFILE entries, and therefore, Avast can not be spying on you. I find such a subject quite misleading and damaging. If, on the other hand, you would think that Avast is reading your data in this scenario when not instructed to do so, please contact me, and we will address it as well.

I have to quote @igor on that:

If WebShield isn't installed at all, then indeed it's completely useless.

You see @lukor that I simply found it very suspicious why my disabled webshield still actively changes Firefox SSL logging and on top of that enables security.enterprise_roots.enabled;true when I want it to simply be off.

I changed the title to: (BUG) Stop SSL logging & EnterpriseRoots in Firefox when WebShield is DISABLED

Addendum: Has the change of Firefox about:config settings (security.enterprise_roots.enabled;true) made it into 19.9 as well, sir? (referring to https://forum.avast.com/index.php?topic=229164.msg1520769#msg1520769 )

[inactive-user]

we have it ready for 19.9. When you disable SSL scanning or uninstall WebShield, the SSLKEYLOGFILE variable is no longer inserted into your environment. When re-enabled, the user needs to restart all browsers. Hopefully, this is something a standard user can understand and will not expect Avast to protect him in the meantime.

You have fixed absolutely NOTHING:





URL bar: about:policies

This variable is still being forcibly hooked by AVAST and the implications are BAD.

STOP CHANGING my CA-Certificates from Firefox' built in NSS library to the disgusting Windows CA-certs. Because that is what Enterprise Roots mean!
Firefox loads windows built in certificates because of your settings.
There is a reason why NSS is more trusted, as it is not maintained by Microsoft and not every Windows program can add their own certificate to the OS like AVAST does.

Can you stop lying and FULLY disable your awful memhooks on my browser?

Has been reverted again by myself. Sorry, hooking into Firefox and manipulating the way TLS connections are made and what Certificates are trusted is the absolute NO-GO after the privacy disaster with your browser extension last year.

If you cannot be trusted I will uninstall. You stalled me already nearly 6 months and nothing has changed for the better, at all.

Feel free patch it in, I highly doubt it, but please ban my account and change the email to anything but mine.

I am leaving on my own terms, peacefully and disappointed.

C. Radames

[lukor]

Are you sure you are running the latest version? SSLKEYLOGFILE is not inserted into neither firefox nor chrome when WebShield is turned off (or when HTTPS Scanning is disabled)