User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

Enable DNS over HTTPS using Cloudflare. Confirmed DoH enabled using https://1.1.1.1/help. Visited mondoweiss.net.

Actual results:

"An error occurred during a connection to mondoweiss.net. Cannot communicate securely with peer: no common encryption algorithm(s). Error code: SSL_ERROR_NO_CYPHER_OVERLAP "

May be intermittent, but I haven't been able to get the error to not appear again.

Expected results:

No error

Can you take a look at about:networking DNS page while trying, to see if IP for mondoweiss is resolved correctly? What does trr column say? This sounds like a site TLS issue but just want to be sure.

Andy, about:networking#dns lists the same IP's for mondoweiss whether or not DoH is enabled, except TRR is false when DoH is enabled, true when it's not.

Also, on another site with DoH to Cloudflare enabled: "An error occurred during a connection to theintercept.com. SSL_ERROR_MISSING_ESNI_EXTENSION"

In addition, after selecting "Custom" and entering 8.8.8.8, https://1.1.1.1/help gives "Using DNS over HTTPS (DoH) = No," so no obvious way for me to know whether these are Firefox or Cloudflare issues.

Andy, about:networking#dns lists the same IP's for mondoweiss whether or not DoH is enabled, except TRR is false when DoH is enabled, true when it's not.

Huh? This should be the opposite, trr should be true when doh is enabled.

I don't think 8.8.8.8 works, you need to give the URL https://dns.google/dns-query . Using that, trr shows as "true" but DoH is still listed as false when visiting https://1.1.1.1/help . Maybe that site only says yes if using Cloudflare for doh?

(In reply to Andy Grover [:grover] from comment #3)

Andy, about:networking#dns lists the same IP's for mondoweiss whether or not DoH is enabled, except TRR is false when DoH is enabled, true when it's not.

Huh? This should be the opposite, trr should be true when doh is enabled:
No, I checked again. trr is false when doh is enabled:

Enabled:
mondoweiss.net ipv4 true 104.28.0.84
104.28.1.84.42

Disabled:
mondoweiss.net ipv4 false 104.28.1.84
104.28.0.84.74

I don't think 8.8.8.8 works, you need to give the URL https://dns.google/dns-query . Using that, trr shows as "true" but DoH is still listed as false when visiting https://1.1.1.1/help . Maybe that site only says yes if using Cloudflare for doh?

Using that (https://dns.google/dns-query), trr shows as "true"...
Yes, which for 1.1.1.1 means doh is enabled, per about:networking#dns.

Maybe that site only says yes if using Cloudflare for doh?
I expect so, but can't find another site to check whether doh is working on other dns servers.

CORRECTION: Corrected spacing, and therefore quotes:

(In reply to Andy Grover [:grover] from comment #3)

Andy, about:networking#dns lists the same IP's for mondoweiss whether or not DoH is enabled, except TRR is false when DoH is enabled, true when it's not.

Huh? This should be the opposite, trr should be true when doh is enabled:

No, I checked again. trr is false when doh is enabled:

Enabled:
mondoweiss.net ipv4 true 104.28.0.84
104.28.1.84.42

Disabled:
mondoweiss.net ipv4 false 104.28.1.84
104.28.0.84.74

Using that (https://dns.google/dns-query), trr shows as "true"...

Yes, which for 1.1.1.1 means doh is enabled, per about:networking#dns.

Maybe that site only says yes if using Cloudflare for doh?

I expect so, but can't find another site to check whether doh is working on other dns servers.

If FF is getting the same and correct in both cases, I don't think it's a DNS issue.

Can you open the network console (ctrl-shift-E) and see what that shows when you get the error?

What could be causing various security errors on various sites in one profile that don't occur in a second profile?

The network console doesn't show anything when I get the error. However, when I tried opening a second profile from about:profiles, the pages open in that profile with no errors, with DoH enabled on Cloudflare. I tried restarting the first profile with all addons disabled (safe mode), and the errors still appear. I then tried installing all the plugins from the first profile in the second profile, and the pages still open in the second profile with no errors. I changed one option setting in the 2nd profile to match the 1st, with the same result. I can't quickly see any remaining differences between the options setting in the two profiles.

To be clear, the errors only appear in the first profile when DoH is enabled.

Could you open your first profile, go to about:support and send us what you have there?

You mean "copy text to clipboard," save it, and "Attach New File" here?

(In reply to cattledogit from comment #10)

You mean "copy text to clipboard," save it, and "Attach New File" here?

If possible, yes. Or you can send it to me or Andy via email.

Can you check network.security.esni.enabled?
Also can you make http logs, with and without DoH:
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

network.security.esni.enabled is true. I emailed the http logs.

I see that esni is enabled on this profile.
Also, I see an addon called easyDoH in the installed extensions. I've found some info link1 link2 about it... it seems to just change some user prefs, but I didn't look through all the code to make sure it doesn't break anything else.

(In reply to Valentin Gosu [:valentin] (he/him) from comment #14)

I see that esni is enabled on this profile.

Should esni not be enabled? I enabled it months ago and haven't had any problems.

Also, I see an addon called easyDoH in the installed extensions. I've found some info link1 link2 about it... it seems to just change some user prefs, but I didn't look through all the code to make sure it doesn't break anything else.

I disabled easyDoH right after installing it recently, before installing the separate script I was told was needed to make it work per https://github.com/ElevenPaths/EasyDoH/. The errors still appear after removing easyDoH just now without restarting.

There are no errors on the second profile even with easyDoH enabled (and DoH option enabled to Cloudflare).

(In reply to cattledogit from comment #15)

(In reply to Valentin Gosu [:valentin] (he/him) from comment #14)

I see that esni is enabled on this profile.

Should esni not be enabled? I enabled it months ago and haven't had any problems.

Hmm. https://www.cloudflare.com/ssl/encrypted-sni/ says "Your browser did not encrypt the SNI when visiting this page."

(In reply to cattledogit from comment #16)

Should esni not be enabled? I enabled it months ago and haven't had any problems.

Enabling esni and doh on the second profile I now get:

At mondoweiss.net: "An error occurred during a connection to mondoweiss.net. Cannot communicate securely with peer: no common encryption algorithm(s). Error code: SSL_ERROR_NO_CYPHER_OVERLAP"

At https://www.cloudflare.com/ssl/encrypted-sni/#: "An error occurred during a connection to www.cloudflare.com. SSL_ERROR_MISSING_ESNI_EXTENSION"

With esni enabled and doh disabled on the second profile I still get (router is set to use 1.1.1.1 as primary dns server):

https://www.cloudflare.com/ssl/encrypted-sni/ says "Your browser did not encrypt the SNI when visiting this page."

So esni doesn't work anyway, and should be disabled to prevent errors when using doh??

What happens next?

Is confirming this apparent bug the next step, and if so, who will do that? Since both DNS and SNI can leak domains, if ESNI and DoH can't be used together then leakage can't be prevented. I updated the title/subject. Thanks.

Turn off ESNI, it's not ready for widespread use yet. (Sorry.)

I can confirm this bug visiting jgc.org, which is hosted by Cloudflare. Disabling ESNI solved it.

I was coming to report this exact issue. My message is a little different, but I think we're talking about the same bug so I'll add it here.

For me there's a limited number of websites which, roughly once a week, will stop loading and display a SSL_ERROR_MISSING_ESNI_EXTENSION error, which was previously called SSL_ERROR_NO_CYPHER_OVERLAP for me as well. When this happens, I need to open the about:config page and temporarily disable network.security.esni.enabled then refresh the page, after which the setting can be re-enabled and the site will work again until the next occurrence.

This is rather annoying and I hope it can be fixed in the next release. I'm now using Firefox 70.0.1 for Linux (openSUSE Tumbleweed x64). I attached an example screenshot of the new error message I'm getting on a website that triggers the issue periodically.

I cannot visit any website today with ESNI enabled, this is error is occuring on all CloudFlare hosted websites.

This bug is moot. Encrypted Client Hello will replace ESNI, and ESNI about:config option has been removed per https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox/.