1847589 - ESET Internet Security disables ECH

Status: RESOLVED WONTFIX

(Core :: Security: PSM, defect)

Description

[John Doe]

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

Comment 1

[John Doe]

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

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 3

[John Doe]

tested on 116.0.2, 117.0b4, 118.0a1, does not work in any.

Comment 4

[John Doe]

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

[Kershaw Chang [:kershaw]]

Hi Reporter,

Could you try to record a http log?
Please also send the log to [e-mail].

Thanks.

Comment 6

[John Doe]

Attachment: firefox logs.7z

http logs, inside sandboxie (works), vmware (works), host (does not work)

Comment 7

[John Doe]

(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 [e-mail].

Thanks.

I have attached the logs. and i will also be sending the email as you requested.

Comment 8

[Valentin Gosu [:valentin] (he/him) {{ FYI: OOO 14 June - 4 August }}]

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

[Valentin Gosu [:valentin] (he/him) {{ FYI: OOO 14 June - 4 August }}]

Could you maybe post the contents of about:support (on the host machine here) ? Thanks!

Comment 10

[Dennis Jackson]

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

[bbhtt]

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

[Dennis Jackson]

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

[bbhtt]

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!

Comment 14

[John Doe]

(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.

Comment 15

[John Doe]

Attachment: about support host nightly.txt

about support

Comment 16

[John Doe]

(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

[Ed Guloien [:edgul]]

Not quite sure about the component here, moving to PSM.

Comment 18

[Dana Keeler (she/her) (use needinfo) [:keeler]]

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

[Dennis Jackson]

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.

Comment 20

[John Doe]

Eset has an option to disable the ssl/tls interception, and it seems to have fixed it.