ESET Internet Security disables ECH
Categories
(Core :: Security: PSM, defect)
Tracking
()
People
(Reporter: safsadafrsf43f, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/117.0
Steps to reproduce:
Clean install of firefox release/beta/dev/nightly (happens on all)
enable secure dns from settings or about:config (works)
enable ech following these steps
https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox/
Actual results:
does not work
https://crypto.cloudflare.com/cdn-cgi/trace
shows sni=plaintext
it works perfectly on all firefox derivatives (waterfox, librewolf)
Expected results:
should have showed sni=encrypted
strangely enough, in nightly, where its enabled by default in about:config, it still does not work as intended, just like the rest of the firefox releases.
Comment 2•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Networking: DNS' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
it worked when i tried it on release (116.0.2) on a guest vm running windows 10, but did not work with nightly on the same vm. host is running windows 11.
Comment 5•1 year ago
|
||
Hi Reporter,
Could you try to record a http log?
Please also send the log to necko@mozilla.com.
Thanks.
http logs, inside sandboxie (works), vmware (works), host (does not work)
(In reply to Kershaw Chang [:kershaw] from comment #5)
Hi Reporter,
Could you try to record a http log?
Please also send the log to necko@mozilla.com.Thanks.
I have attached the logs. and i will also be sending the email as you requested.
Comment 8•1 year ago
|
||
I see several nsSocketTransport::InitiateSocket set echconfig
lines in host-release-log.txt-main.19620.moz_log
, so it seems we are at least trying to use ECH, but maybe it doesn't work for some reason.
Dennis, how could we determine why ECH might be failing?
Comment 9•1 year ago
|
||
Could you maybe post the contents of about:support
(on the host machine here) ? Thanks!
Comment 10•1 year ago
|
||
Hi,
Thank you for providing the logs. I looked through them all.
As far as I can tell, on your host machine your Nightly attempted ECH and the outcome was SSL_ERROR_ECH_RETRY_WITHOUT_ECH
. This indicates the TLS server you were speaking to, authenticated by a certificate your machine trusts, disabled or otherwise ignored ECH. Is it possible your host machine is configured to use a proxy / antivirus software / some similar kind of connection interception device? Your Release Firefox on Host did not attempt ECH at all, are you sure the right prefs and DNS over HTTPS was configured correctly?
Comment 11•1 year ago
|
||
are you sure the right prefs and DNS over HTTPS was configured correctly?
Hi,
Is having DoH in Firefox a prerequisite for ECH? Because I can reproduce the same issue on current Nightly without Firefox DoH. I run DoH on a system level through dnscrypt-proxy. It works only when I enable DoH in Firefox.
In my HTTP logs (about:logging > Network preset) I do not see any lines regarding ECH even though the two prefs from the blog post are default enabled.
Thanks!
Comment 12•1 year ago
|
||
Is having DoH in Firefox a prerequisite for ECH?
Right now, yes, because ECH relies on HTTPS RR DNS entries which Firefox can currently only fetch over DoH. It's filed as bug 1500289 and there's an explanation in my comment here.
Comment 13•1 year ago
|
||
Apologies, it is indeed working with a local doh server (https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Local-DoH#creating-your-own-certification) running at https://127.0.0.1:3000/dns-query. Firefox wasn't trying that because I had a certificate issue. I fixed it by properly creating a root cert with mkcert and adding it to Firefox CA store. Now the above page works.
Thanks!
It's filed as bug 1500289 and there's an explanation in my comment here.
Thanks!
Reporter | ||
Comment 14•1 year ago
|
||
(In reply to Dennis Jackson from comment #10)
Hi,
Thank you for providing the logs. I looked through them all.
As far as I can tell, on your host machine your Nightly attempted ECH and the outcome was
SSL_ERROR_ECH_RETRY_WITHOUT_ECH
. This indicates the TLS server you were speaking to, authenticated by a certificate your machine trusts, disabled or otherwise ignored ECH. Is it possible your host machine is configured to use a proxy / antivirus software / some similar kind of connection interception device? Your Release Firefox on Host did not attempt ECH at all, are you sure the right prefs and DNS over HTTPS was configured correctly?
i am using eset internet security, and it seems to be what is causing all this to happen. which is why in a vm it worked (because i didnt have it installed, and only windows defender).
it seems to happen weather or not i have the eset firewall on. or if i have the real time protection on. just having it installed makes ech stop working in firefox. happens with other versions of the eset antivirus (eset nod32).
the firefox release on host is configured properly, with both 'network.dns.echconfig.enabled' and 'network.dns.http3_echconfig.enabled' turned on, also dns over https set to max protection.
Reporter | ||
Comment 15•1 year ago
|
||
about support
Reporter | ||
Comment 16•1 year ago
|
||
(In reply to Valentin Gosu [:valentin] (he/him) from comment #9)
Could you maybe post the contents of
about:support
(on the host machine here) ? Thanks!
i have attached it. as i mentioned in my previous comment. it seems to be caused by eset av being installed. and happens inside/outside of vm.
Comment 17•1 year ago
|
||
Not quite sure about the component here, moving to PSM.
Dennis - my reading of this bug is that AV acting as an intercepting proxy means ECH doesn't work, as expected, so this isn't a bug. Is that right, or is there something we can do here?
Comment 19•1 year ago
|
||
It seems ESET Internet Security you've installed is intercepting your TLS connections and disabling ECH.
Unfortunately we can't do anything about this - either ESET needs to implement support for ECH themselves or you will have to disable ESET in order to benefit from ECH. This kind of connection interception is quite common in antivirus products and from our perspective often problematic because anti virus software is slow to adopt new networking security features.
Reporter | ||
Comment 20•1 year ago
|
||
Eset has an option to disable the ssl/tls interception, and it seems to have fixed it.
Description
•