1862650 - Cloudflare rejects ECH if WARP is in use.

Status: NEW

(Web Compatibility :: Site Reports, defect, P3)

Description

[bugdiscovery]

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

Steps to reproduce:

I configured and enabled a SOCKS proxy in Firefox for personal use.

Actual results:

Encrypted Client Hello (ECH) is not working.

Expected results:

Encrypted Client Hello (ECH) working.

In FAQ I see that in some cases is disabled as example in enterprise network/proxy. But I'm trying to use a proxy myself that is unrelated with such scenario so I expect it to be enabled.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Sunil Mayya]

Hello,

Thank you for reporting the bug.
ECH relies on the DNS records fetched over DoH.
And we do not support DoH over SOCKS proxy.
Hence, ECH over SOCKS proxy wont work.

I will close this bug as we do not support such configuration.

Comment 3

[bugdiscovery]

Thanks for the feedback.

But I wonder, DNS over proxy is not default, it's an option you have to enable. Since by default DNS is not done through SOCKS, I'm not sure to follow the argument.

Comment 4

[bugdiscovery]

Sorry for the quick add up to this, but now I'm wondering if then there isn't another bug going on?

Based on what it has been stated DoH is not working if SOCKS proxy is enabled right? But the UI under settings of DoH says that actually DoH is active. If it's not working at all that status is wrong.

Comment 5

[Sunil Mayya]

I am re-opening the bug as we still have some unaddressed questions.

Based on what it has been stated DoH is not working if SOCKS proxy is enabled right? But the UI under settings of DoH says that actually DoH is active. If it's not working at all that status is wrong.

You are right. Could you please share http logs for the above scenario. We will check it. Thanks

Comment 6

[bugdiscovery]

Attachment: Firefox 2023-11-03 13.35 profile.json.7z

I hope the default profile for collecting is fine. Otherwise please point me to the right one.

I had to re-compress to 7z since as gz it was too big to attach the file.

Comment 7

[bugdiscovery]

Attachment: Firefox 2023-11-03 13.42 profile.json.gz

Here I used HTTP/3 profile just in case.

Comment 8

[bugdiscovery]

I want also to report that DoH is actually working. Since if I try to a non existent domain, I get an error suggesting that DoH is being used. It's only ECH that is not working.

Comment 9

[bugdiscovery]

Any update on this?

Comment 10

[Kershaw Chang [:kershaw]]

Hi,

Thanks for the log. From that, I can see this line, so I assume ECH is configured. Unfortunately, I cannot tell why ECH was not used from the log.
Note that I've tested my Firefox locally with a SOCKS proxy (I used tor) and I can see ECH was working by visiting this website (https://crypto.cloudflare.com/cdn-cgi/trace).

May I ask how do you know ECH is not working at your side?
Can you try to record a http log again? Please set MOZ_LOG to timestamp,nsHttp:5,nsHostResolver:5,pipnss:5,SOCKS:5,nsSocketTransport:5 and also select Logging to a file instead of Logging to the Firefox Profiler. Thanks.

Comment 11

[bugdiscovery]

Attachment: log.txt-main.14520.moz_log.zip

Hello, I've been using https://www.cloudflare.com/it-it/ssl/encrypted-sni/ and now I used https://crypto.cloudflare.com/cdn-cgi/trace

In the output I have "sni=plaintext". And on the other link I had the check failed red.

I hope I recorded correctly with the new settings.

Comment 12

[Manuel Bucher [:manuel]]

I am re-opening the bug as we still have some unaddressed questions.

seems like this bug is intended to be in the open state

Comment 13

[Kershaw Chang [:kershaw]]

Thanks for the log.
It shows that we got this error SSL_ERROR_ECH_RETRY_WITHOUT_ECH.

2023-11-22 09:25:35.718000 UTC - [Parent 14520: Socket Thread]: D/nsHttp  Got SSL_ERROR_ECH_RETRY_WITHOUT_ECH, use empty echConfig to retry

I was using the same website to test, but I was not able to reproduce this.
Does ech work for you when connecting to the site directly?

Comment 14

[bugdiscovery]

Yup, it's working without the proxy. I get "sni=encrypted" and a positive test on the other.

Comment 15

[Kershaw Chang [:kershaw]]

Hi Dennis,

Please have a look at comment #13. Do you maybe have an idea why ech doesn't work with the reporter's SOCKS proxy?
FWIW, I've tested this with tor proxy, but I cannot reproduce.

Thanks.

Comment 16

[BMO Automation]

Moving bug to Core/Networking: Proxy.

Comment 17

[Dennis Jackson]

I have tested this as well by using SSH as a SOCKS proxy, I can't reproduce the issue either, ECH works correctly for me with the proxy enabled.

SSL_ERROR_ECH_RETRY_WITHOUT_ECH indicates that we had an ECHConfig and successfully connected to the public name indicated in it, with a valid TLS certificate. I can't imagine any kind of interaction with a proxy that would trigger this, unless the proxy was being used to intercept TLS connections. This is possible with some kinds of security / internet safety software which typically disable any TLS features they don't support like ECH through use of a root certificate installed on the user's device.

Comment 18

[bugdiscovery]

(In reply to Dennis Jackson from comment #17)

I have tested this as well by using SSH as a SOCKS proxy, I can't reproduce the issue either, ECH works correctly for me with the proxy enabled.

SSL_ERROR_ECH_RETRY_WITHOUT_ECH indicates that we had an ECHConfig and successfully connected to the public name indicated in it, with a valid TLS certificate. I can't imagine any kind of interaction with a proxy that would trigger this, unless the proxy was being used to intercept TLS connections. This is possible with some kinds of security / internet safety software which typically disable any TLS features they don't support like ECH through use of a root certificate installed on the user's device.

The proxy used is WARP by Cloudflare in socks mode.

Comment 19

[Dennis Jackson]

Thanks for the information!

I downloaded and tested with WARP running in regular (non-socks) mode. Cloudflare's output indicates no use of ECH but they detect use of WARP. Testing with a different ECH site (https://defo.ie/ech-check.php) indicates ECH succeeds. Testing with Chrome confirms the same behaviour as Firefox with Cloudflare disabling ECH when WARP is used but ECH with other sites working through WARP.

This looks like a deliberate policy decision by Cloudflare, everything is working correctly in Firefox and Chrome. Thank you for taking the time to file the bug report and provide the detailed steps! I'll reach out to Cloudflare through our contacts for compatibility there in case this is an accident on their part. In terms of impact, this shouldn't have any privacy consequences since you're already using a VPN to wrap your TLS traffic, but it might be making things marginally slower than they should be since we'll need to make an ECH handshake followed by a non-ECH handshake over WARP.

Comment 20

[Dennis Schubert [:denschub]]

This is a bit hard to triage from our point of view. For now, we'll treat this as a minor performance issue (it adds lag) that's affecting a rare configuration (only users with WARP set up), and correctly tagging this as waiting for Cloudflare to act.