bbs Firefox will ship ECH by default

https://groups.google.com/a/mozilla.org/g/dev-platform/c/uv7PNrHUagA/m/BNA4G8fOAAAJ

this encrypts the SNI assuming DoH is working. but ECH is not stealthy and to my knowledge is blocked in many countries

it's not clear to me whether there is a fallback to plaintext SNI in situations where the site and its DNS support ECH but the network interferes with in

Aug 28 '23 13:08 mmmray

ECH is not stealthy and to my knowledge is blocked in many countries

I'm not aware of any reports of ECH being blocked yet. ESNI was blocked in China in 2020, which you can read about in #43. The ESNI block was narrowly tailored to specific TLS extension numbers. ECH uses different extension numbers.

I'm not aware of any censorship measurement platforms currently testing ECH. It looks like OONI Probe has an issue with some progress: https://github.com/ooni/probe/issues/1453.

Aug 29 '23 00:08 wkrp

it's not clear to me whether there is a fallback to plaintext SNI in situations where the site and its DNS support ECH but the network interferes with in

根据 @nursery01 的说法 https://github.com/XTLS/Xray-core/issues/2230#issuecomment-1598099945 ，标准的 ECH 会同时开两条连接，你可以用 Firefox 验证一下。

According to @nursery01's comment https://github.com/XTLS/Xray-core/issues/2230#issuecomment-1598099945, standard ECH will open two connections at the same time, you can verify this with Firefox.

I'm not aware of any reports of ECH being blocked yet. ESNI was blocked in China in 2020, which you can read about in #43. The ESNI block was narrowly tailored to specific TLS extension numbers. ECH uses different extension numbers.

ECH 可能还没有被中国 GFW 封锁，主要是因为它现在的热度、普及程度远不如 2020 年的 ESNI。当年在 ESNI 被封锁前，在浏览器内启用 ESNI 后，我可以直接从中国访问 Cloudflare 上一些原本被 GFW 封锁的网站，这样干的人多了肯定招封。

所以随着 ECH 的继续推广，不出意外的话 GFW 就会封锁它，除非 ECH 成了必选项，然而这一点很难实现，至少需要数年时间。

ECH may not be blocked by the Chinese GFW yet, mainly because it's nowhere near as popular as ESNI was in 2020, and before ESNI was blocked, enabling ESNI in my browser enabled me to access some of the GFW-blocked sites on Cloudflare from China, which is a surefire way to get blocked if you're doing that.

So as ECH continues to spread, it's no surprise that GFW will block it unless ECH becomes mandatory, which will be difficult to achieve, at least for a few years.

Aug 29 '23 13:08 RPRX

it's not clear to me whether there is a fallback to plaintext SNI in situations where the site and its DNS support ECH but the network interferes with in

Yes

所以随着 ECH 的继续推广，不出意外的话 GFW 就会封锁它，除非 ECH 成了必选项，然而这一点很难实现，至少需要数年时间。

也許中國會封鎖其它國家的DoH，並且要求中國的DoH公司配合審查，就像中國的ISP配合政府審查一樣，那麽ECH就作廢了

Maybe China will block DoH from other countries and require DoH companies in China to cooperate with censorship, just like ISPs in China cooperate with government censorship, then ECH will be rendered null and void!

Aug 29 '23 14:08 nursery01

ECH 可能还没有被中国 GFW 封锁，主要是因为它现在的热度、普及程度远不如 2020 年的 ESNI。

ECH may not be blocked by the Chinese GFW yet, mainly because it's nowhere near as popular as ESNI was in 2020

Was ESNI popular in 2020? As I recall, ESNI was never enabled by default, so people must have been enabling it manually? I always took the fact that the blocking was reported on the IETF tls mailing list and not in a user forum as evidence that use of ESNI was not yet widespread, but I could be wrong.

Aug 29 '23 14:08 wkrp

Was ESNI popular in 2020? As I recall, ESNI was never enabled by default, so people must have been enabling it manually? I always took the fact that the blocking was reported on the IETF tls mailing list and not in a user forum as evidence that use of ESNI was not yet widespread, but I could be wrong.

需要手动开启。当年 ESNI 从整个互联网上来说当然还是很小众，但是当年它已经比今天的 ECH 吸引了更多的注意力。当时 Cloudflare 出了一个测试页面，要想将四项全部点亮就需要开启 ESNI，所以很多人进行了尝试并彼此之间交流，很多人都有印象。而今天的 ECH 并未出现当年的盛况，原因可能是它并不像当年的 ESNI 是一个特别新鲜的事物，并且人们已经看到了对 ESNI 的封锁，所以不再抱有特别的期待。其次是“ECH 取代 ESNI”这件事已经被宣布了很久，但进展相对缓慢，同样会消磨人们的期待。

It needed to be turned on manually. Back then ESNI was of course still very niche in terms of the internet as a whole, but back then it already attracted a lot more attention than ECH does today. Cloudflare put out a test page where you had to turn on ESNI to get all four items to light up, so many people tried it and talked to each other about it, and many of them remember it. Today's ECH is not as popular as it was back then, probably because it's not as new as ESNI was back then, and people have already seen ESNI blocked, so they don't have the same expectations. Secondly, the fact that "ECH replaces ESNI" has been announced for a long time, but the progress has been relatively slow, which also kills people's expectations.

Aug 29 '23 15:08 RPRX

require DoH companies in China to cooperate with censorship, just like ISPs in China cooperate with government censorship, then ECH will be rendered null and void!

Preloading ECH configuration of (at least the popular) DoH servers (by browsers / DoH clients) should help overcome this scenario (sec 3.2). Frequent key rotation (as recommended by sec 10.9.2) by DoH servers may render prior ECH configuration useless, however.

Aug 29 '23 15:08 ignoramous

根据 @nursery01 的说法 XTLS/Xray-core#2230 (comment) ，标准的 ECH 会同时开两条连接，你可以用 Firefox 验证一下。

According to @nursery01's comment XTLS/Xray-core#2230 (comment), standard ECH will open two connections at the same time, you can verify this with Firefox.

https://github.com/XTLS/Xray-core/issues/2230#issuecomment-1598099945

你說的這個技術是DoH-ECH技術，然而上文我說過了，它並沒有被完全加密，我抓過包親手驗證過，並且ECH標準協定裡寫了它發了兩條，有一條是加密的，一條是沒有加密的用於退回，那條退回的請求是包含sni的

The technology you are talking about is DoH-ECH, but as I said above, it is not fully encrypted, I've captured the packets and verified it myself, and I've written in the ECH standard protocol that it sends two messages, one encrypted and one unencrypted for return, and that return request is the one that contains sni!

Maybe it's a translation issue, or I don't fully understand, but I did a test today with Firefox 102.14.0esr, and I do not see two Client Hello messages. I only see one Client Hello, which contains an outer Client Hello (with its own server_name extension and a "public name") and an encrypted_client_hello extension, which is what I expect.

However, it appears that Firefox still leaks certificate serial numbers in OCSP requests. From a serial number, you can look up the certificate, whose commonName reveals the server_name that ECH conceals. In some old documentation for meek-with-ESNI, I recommended setting security.OCSP.enabled=0 for this reason.

This is what I did. @nursery01 was your procedure different?

Start the browser on a new profile.
Enable DNS over HTTPS in Connection Settings.
Set network.dns.echconfig.enabled=true in about:config. (Per the Mozilla blog. network.dns.use_https_rr_as_altsvc was true by default.)
Browse to https://tls-ech.dev/ and see "You are using ECH."

ech-tls-dev-ff102.41.0.pcap.gz

IP address	role
192.168.2.2	local IP address
172.64.41.4	mozilla.cloudflare-dns.com (DoH resolver)
34.138.246.121	tls-ech.dev web server
184.28.41.139	OSCP server

Wireshark dissection of Client Hello

Handshake Protocol: Client Hello
    Handshake Type: Client Hello (1)
    Length: 615
    Version: TLS 1.2 (0x0303)
    Random: a84fa598f9e6922f66dfa573ff79fcced89d636b5f3967b96af0521f2cc55008
    Session ID Length: 32
    Session ID: 0251f68e876dff2e9473188b8a03ffcda542a5106fa80fc832227493bf84d4dc
    Cipher Suites Length: 34
    Cipher Suites (17 suites)
        Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
        Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
        Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
        Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
        Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
        Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
        Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
        Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
        Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
        Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
        Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
        Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
        Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
        Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
        Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
        Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
        Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
    Compression Methods Length: 1
    Compression Methods (1 method)
        Compression Method: null (0)
    Extensions Length: 508
    Extension: server_name (len=23)
        Type: server_name (0)
        Length: 23
        Server Name Indication extension
            Server Name list length: 21
            Server Name Type: host_name (0)
            Server Name length: 18
            Server Name: public.tls-ech.dev
    Extension: extended_master_secret (len=0)
        Type: extended_master_secret (23)
        Length: 0
    Extension: renegotiation_info (len=1)
        Type: renegotiation_info (65281)
        Length: 1
        Renegotiation Info extension
            Renegotiation info extension length: 0
    Extension: supported_groups (len=14)
        Type: supported_groups (10)
        Length: 14
        Supported Groups List Length: 12
        Supported Groups (6 groups)
            Supported Group: x25519 (0x001d)
            Supported Group: secp256r1 (0x0017)
            Supported Group: secp384r1 (0x0018)
            Supported Group: secp521r1 (0x0019)
            Supported Group: ffdhe2048 (0x0100)
            Supported Group: ffdhe3072 (0x0101)
    Extension: ec_point_formats (len=2)
        Type: ec_point_formats (11)
        Length: 2
        EC point formats Length: 1
        Elliptic curves point formats (1)
            EC point format: uncompressed (0)
    Extension: application_layer_protocol_negotiation (len=14)
        Type: application_layer_protocol_negotiation (16)
        Length: 14
        ALPN Extension Length: 12
        ALPN Protocol
            ALPN string length: 2
            ALPN Next Protocol: h2
            ALPN string length: 8
            ALPN Next Protocol: http/1.1
    Extension: status_request (len=5)
        Type: status_request (5)
        Length: 5
        Certificate Status Type: OCSP (1)
        Responder ID list Length: 0
        Request Extensions Length: 0
    Extension: delegated_credentials (len=10)
        Type: delegated_credentials (34)
        Length: 10
        Signature Hash Algorithms Length: 8
        Signature Hash Algorithms (4 algorithms)
            Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
                Signature Hash Algorithm Hash: SHA256 (4)
                Signature Hash Algorithm Signature: ECDSA (3)
            Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
                Signature Hash Algorithm Hash: SHA384 (5)
                Signature Hash Algorithm Signature: ECDSA (3)
            Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
                Signature Hash Algorithm Hash: SHA512 (6)
                Signature Hash Algorithm Signature: ECDSA (3)
            Signature Algorithm: ecdsa_sha1 (0x0203)
                Signature Hash Algorithm Hash: SHA1 (2)
                Signature Hash Algorithm Signature: ECDSA (3)
    Extension: key_share (len=107)
        Type: key_share (51)
        Length: 107
        Key Share extension
            Client Key Share Length: 105
            Key Share Entry: Group: x25519, Key Exchange length: 32
                Group: x25519 (29)
                Key Exchange Length: 32
                Key Exchange: 78fb72df38380d58f2e24afb7bb936656950d3114aab57d70b55493f6385cf0a
            Key Share Entry: Group: secp256r1, Key Exchange length: 65
                Group: secp256r1 (23)
                Key Exchange Length: 65
                Key Exchange: 049bc2c3f28b0571cb387ff2d65da1cec27ac8279376eb1ab4fd2232a18562d71eba2c82…
    Extension: supported_versions (len=5)
        Type: supported_versions (43)
        Length: 5
        Supported Versions length: 4
        Supported Version: TLS 1.3 (0x0304)
        Supported Version: TLS 1.2 (0x0303)
    Extension: signature_algorithms (len=24)
        Type: signature_algorithms (13)
        Length: 24
        Signature Hash Algorithms Length: 22
        Signature Hash Algorithms (11 algorithms)
            Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
                Signature Hash Algorithm Hash: SHA256 (4)
                Signature Hash Algorithm Signature: ECDSA (3)
            Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
                Signature Hash Algorithm Hash: SHA384 (5)
                Signature Hash Algorithm Signature: ECDSA (3)
            Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
                Signature Hash Algorithm Hash: SHA512 (6)
                Signature Hash Algorithm Signature: ECDSA (3)
            Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)
                Signature Hash Algorithm Hash: Unknown (8)
                Signature Hash Algorithm Signature: SM2 (4)
            Signature Algorithm: rsa_pss_rsae_sha384 (0x0805)
                Signature Hash Algorithm Hash: Unknown (8)
                Signature Hash Algorithm Signature: Unknown (5)
            Signature Algorithm: rsa_pss_rsae_sha512 (0x0806)
                Signature Hash Algorithm Hash: Unknown (8)
                Signature Hash Algorithm Signature: Unknown (6)
            Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
                Signature Hash Algorithm Hash: SHA256 (4)
                Signature Hash Algorithm Signature: RSA (1)
            Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
                Signature Hash Algorithm Hash: SHA384 (5)
                Signature Hash Algorithm Signature: RSA (1)
            Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
                Signature Hash Algorithm Hash: SHA512 (6)
                Signature Hash Algorithm Signature: RSA (1)
            Signature Algorithm: ecdsa_sha1 (0x0203)
                Signature Hash Algorithm Hash: SHA1 (2)
                Signature Hash Algorithm Signature: ECDSA (3)
            Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
                Signature Hash Algorithm Hash: SHA1 (2)
                Signature Hash Algorithm Signature: RSA (1)
    Extension: record_size_limit (len=2)
        Type: record_size_limit (28)
        Length: 2
        Record Size Limit: 16385
    Extension: Unknown type 65037 (len=249)
        Type: Unknown (65037)
        Length: 249
        Data: 00000100012b0020511d0e49d11cf65378383be7a05609d9f039f0f3f2e409e4faca60ba…
    [JA3 Fullstring: 771,4865-4867-4866-49195-49199-52393-52392-49196-49200-49162-49161-49171-49172-156-157-47-53,0-23-65281-10-11-16-5-34-51-43-13-28-65037,29-23-24-25-256-257,0]
    [JA3: ed3d2cb3d86125377f5a4d48e431af48]

Aug 29 '23 15:08 wkrp

Maybe it's a translation issue, or I don't fully understand, but I did a test today with Firefox 102.14.0esr, and I do not see two Client Hello messages. I only see one Client Hello, which contains an outer Client Hello (with its own server_name extension and a "public name") and an encrypted_client_hello extension, which is what I expect.

不是你的翻譯問題，而是我的描述可能會造成誤解，我的錯

也許我應該用圖像解釋

68747470733a2f2f626c6f672e636c6f7564666c6172652e636f6d2f636f6e74656e742f696d616765732f323032302f31322f696d616765332d31372e706e67

This is what I did. @nursery01 was your procedure different?

爲了保證科學嚴謹性，我再做一次測試，但是我使用的是最新版的firefox 117.0 (這裏指的是正式版本，不是開發者版本)

在這之前，我先插入一個插曲，我發現以下描述

摺叠1

Users that have previously enabled ESNI in Firefox may notice that the about:config option for ESNI is no longer present. Though we recommend that users wait for ECH to be enabled by default, some may want to enable this functionality earlier. This can be done in about:config by setting network.dns.echconfig.enabled and network.dns.use_https_rr_as_altsvc to true, which will allow Firefox to use ECH with servers that support it. While ECH is under active development, its availability may be intermittent as it requires both the client and server to support the same version. As always, settings exposed only under about:config are considered experimental and subject to change. For now, Firefox ESR will continue to support the previous ESNI functionality.

文中描述Users that have previously enabled ESNI in Firefox may notice that the about:config option for ESNI is no longer present.我在最新版的firefox裏發現還是有ESNI相關設定，我不知道爲什麽

回歸正題，我使用以下設定，并且開啓DoH，并且設定為最大保護(這裏指的是always DoH)，我不知道Firefox ESR有沒有這個always功能，如果沒有的話在DoH不可用的情況下會不會回落到普通DNS上？

    network.dns.echconfig.enabled = true

    network.dns.http3_echconfig.enabled = true

    network.dns.use_https_rr_as_altsvc = true

    network.security.esni.enabled = true

我訪問的是crypto.cloudflare.com，并且我還是看到了sni，crypto.cloudflare.com，等下，我實際在使用它的時候發現sni會有小概率變爲未加密，它看上去產生了破損，我再次清空cookie并且關掉瀏覽器，然後訪問，得到的結果是cloudflare-ech.com，這個應該是outer sni

我之前的測試可能也是產生破損導致我看到了crypto.cloudflare.com，也就是說我之前的測試結果是有問題的

我不知道爲什麽ECH會產生這種破損，DoH問題？網路問題？瀏覽器問題？

@RPRX 我又翻船了，我以後説話應該謹慎點

It's not your translation that's the problem, it's the fact that my description could be misleading, my fault.

Maybe I should have explained it with a picture.

For the sake of scientific rigor, I'm going to do the test again, but I'm using the latest version of firefox 117.0 (this is the official version, not the developer version).

Before that, let me insert an aside. I found the following text:

Fold 1

Users that have previously enabled ESNI in Firefox may notice that the about:config option for ESNI is no longer present. Though we recommend that users wait for ECH to be enabled by default, some may want to enable this functionality earlier. This can be done in about:config by setting network.dns.echconfig.enabled and network.dns.use_https_rr_as_altsvc to true, which will allow Firefox to use ECH with servers that support it. While ECH is under active development, its availability may be intermittent as it requires both the client and server to support the same version. As always, settings exposed only under about:config are considered experimental and subject to change. For now, Firefox ESR will continue to support the previous ESNI functionality.

The text says "Users that have previously enabled ESNI in Firefox may notice that the about:config option for ESNI is no longer present." I found in the latest version of firefox that there is still an ESNI setting, I don't know why.

Back to the topic, I'm using the following settings and have DoH enabled and set to maximum protection (this means "always DoH"), I don't know if Firefox ESR has this "always" feature, if not will it fall back to normal DNS if DoH is not available?

    network.dns.echconfig.enabled = true
    network.dns.http3_echconfig.enabled = true
    network.dns.use_https_rr_as_altsvc = true
    network.security.esni.enabled = true

I'm accessing crypto.cloudflare.com and I'm still seeing the sni, crypto.cloudflare.com, hold on, I'm actually using it and I'm finding that there's a small chance that the sni will become unencrypted, it looks like it's broken, so I'm clearing out the cookie again and closing the browser, and then accessing, and I'm getting the result cloudflare-ech.com, which is supposed to be an outer sni.

My previous test may have also produced a failure that caused me to see crypto.cloudflare.com, which means that my previous test results were faulty.

I don't know why the ECH is breaking, DoH problem? Network problems? Browser issues?

@RPRX I've done it again, I should be more careful with what I say in the future.

Aug 29 '23 22:08 nursery01

Thank you for running the test. I appreciate it very much.

文中描述Users that have previously enabled ESNI in Firefox may notice that the about:config option for ESNI is no longer present.我在最新版的firefox裏發現還是有ESNI相關設定，我不知道爲什麽

The text says "Users that have previously enabled ESNI in Firefox may notice that the about:config option for ESNI is no longer present." I found in the latest version of firefox that there is still an ESNI setting, I don't know why.

That's a good question. Maybe the setting persists, only if you changed it from the default in the past? Maybe if you open a new profile with firefox -P, the option will not be present in the new profile?

我使用以下設定，并且開啓DoH，并且設定為最大保護(這裏指的是always DoH)，我不知道Firefox ESR有沒有這個always功能，如果沒有的話在DoH不可用的情況下會不會回落到普通DNS上？

Back to the topic, I'm using the following settings and have DoH enabled and set to maximum protection (this means "always DoH"), I don't know if Firefox ESR has this "always" feature, if not will it fall back to normal DNS if DoH is not available?

Here is the documentation: Configure DNS over HTTPS protection levels in Firefox. Indeed I do not have such options in 102; the page says it's only in 114 and above. I do have network.trr.mode etc. in about:config; maybe it's effectively the same.

I am not very sure about the conditions that might make Firefox fall back to unencrypted DNS. I notice that the documentation for the canary domain use-application-dns.net (which can be configured to disable DoH) says:

The canary domain only applies to users who have DoH enabled as the default option. It does not apply for users who have made the choice to turn on DoH by themselves.

It looks like that text was added between February and March 2020.

我不知道爲什麽ECH會產生這種破損，DoH問題？網路問題？瀏覽器問題？

I don't know why the ECH is breaking, DoH problem? Network problems? Browser issues?

I know what you mean. I don't have enough experience with ECH to be confident about the circumstances that might cause ECH to fail. It is good, overall, that it is meant to work "automatically," but that also makes me wary of the potential for silent failures.

Aug 30 '23 03:08 wkrp

回歸正題，我使用以下設定，并且開啓DoH，并且設定為最大保護(這裏指的是always DoH)，我不知道Firefox ESR有沒有這個always功能，如果沒有的話在DoH不可用的情況下會不會回落到普通DNS上？

你可以在 about:config 中设置 network.trr.mode = 3 来强制启用 DoH

You can set network.trr.mode = 3 in about:config to enforce DoH

    network.dns.echconfig.enabled = true

    network.dns.http3_echconfig.enabled = true

    network.dns.use_https_rr_as_altsvc = true

    network.security.esni.enabled = true
我訪問的是crypto.cloudflare.com，并且我還是看到了sni，crypto.cloudflare.com，等下，我實際在使用它的時候發現sni會有小概率變爲未加密，它看上去產生了破損，我再次清空cookie并且關掉瀏覽器，然後訪問，得到的結果是cloudflare-ech.com，這個應該是outer sni

我之前的測試可能也是產生破損導致我看到了crypto.cloudflare.com，也就是說我之前的測試結果是有問題的

我不知道爲什麽ECH會產生這種破損，DoH問題？網路問題？瀏覽器問題？

@RPRX 我又翻船了，我以後説話應該謹慎點

It's not your translation that's the problem, it's the fact that my description could be misleading, my fault.

Maybe I should have explained it with a picture.

For the sake of scientific rigor, I'm going to do the test again, but I'm using the latest version of firefox 117.0 (this is the official version, not the developer version).

Before that, let me insert an aside. I found the following text: Fold 1 Users that have previously enabled ESNI in Firefox may notice that the about:config option for ESNI is no longer present. Though we recommend that users wait for ECH to be enabled by default, some may want to enable this functionality earlier. This can be done in about:config by setting network.dns.echconfig.enabled and network.dns.use_https_rr_as_altsvc to true, which will allow Firefox to use ECH with servers that support it. While ECH is under active development, its availability may be intermittent as it requires both the client and server to support the same version. As always, settings exposed only under about:config are considered experimental and subject to change. For now, Firefox ESR will continue to support the previous ESNI functionality.

The text says "Users that have previously enabled ESNI in Firefox may notice that the about:config option for ESNI is no longer present." I found in the latest version of firefox that there is still an ESNI setting, I don't know why.

Back to the topic, I'm using the following settings and have DoH enabled and set to maximum protection (this means "always DoH"), I don't know if Firefox ESR has this "always" feature, if not will it fall back to normal DNS if DoH is not available?
    network.dns.echconfig.enabled = true
    network.dns.http3_echconfig.enabled = true
    network.dns.use_https_rr_as_altsvc = true
    network.security.esni.enabled = true
I'm accessing crypto.cloudflare.com and I'm still seeing the sni, crypto.cloudflare.com, hold on, I'm actually using it and I'm finding that there's a small chance that the sni will become unencrypted, it looks like it's broken, so I'm clearing out the cookie again and closing the browser, and then accessing, and I'm getting the result cloudflare-ech.com, which is supposed to be an outer sni.

My previous test may have also produced a failure that caused me to see crypto.cloudflare.com, which means that my previous test results were faulty.

I don't know why the ECH is breaking, DoH problem? Network problems? Browser issues?

@RPRX I've done it again, I should be more careful with what I say in the future.

你可能需要设置 network.dns.echconfig.fallback_to_origin_when_all_failed = false 来避免回退到未加密的 Client Hello

You may need to set network.dns.echconfig.fallback_to_origin_when_all_failed = false to prevent fallback to unencrypted Client Hello.

Aug 30 '23 04:08 0x391F

你可以在 about:config 中设置 network.trr.mode = 3 来强制启用 DoH

謝謝，我一直是設定為3，我沒有記錯的話，如果啟用ECH這個值默認是2 network.trr.mode = 3

Thank you, I've always set it to 3. If I remember correctly, if ECH is enabled the value is 2 by default.

Aug 30 '23 04:08 nursery01

你可以在 about:config 中设置 network.trr.mode = 3 来强制启用 DoH

謝謝，我一直是設定為3，我沒有記錯的話，如果啟用ECH這個值默認是2 network.trr.mode = 3

Thank you, I've always set it to 3. If I remember correctly, if ECH is enabled the value is 2 by default.

漏了一个：如果还是不行，设置强制等待 HTTPS Resource Record (HTTPS RR） network.dns.force_waiting_https_rr = true

Missing one: If it still doesn't work, set force waiting HTTPS Resource Record (HTTPS RR) network.dns.force_waiting_https_rr = true

Aug 30 '23 05:08 0x391F

根据 https://t.me/xhqcankao/6131 ，刚刚 https://1.1.1.1 已被中国 GFW 全面封锁，所有省份均不可访问。

前几天我用 Chrome 116 测试 ECH 时，它预设的那几个安全 DNS 只有 1.1.1.1 能直接在中国使用，ECH 测试成功，但显然这一过程和结果在今天已无法复现。虽然仅封锁一个 DoH 并不能完全封锁 ECH，但对于 GFW 的目标而言，它已经迈出了第一步。

根据更多的反馈，目前 GFW 仅针对了 1.1.1.1 的 TCP/443，而 TCP/853、UDP/443 仍能使用，1.0.0.1 的 TCP/443 等仍能使用。

According to https://t.me/xhqcankao/6131 (archive), just now https://1.1.1.1 has been completely blocked by China's GFW, all provinces are inaccessible.

When I tested ECH with Chrome 116 a few days ago, only 1.1.1.1 of its preset secure DNSs worked directly in China, and the ECH test was successful, but apparently the process and results are not reproducible today. While blocking just one DoH does not completely block ECH, it is a first step for GFW's target.

According to more feedback, GFW is currently only targeting TCP/443 on 1.1.1.1, while TCP/853, UDP/443 are still working, and TCP/443 on 1.0.0.1, etc. are still working.

Sep 05 '23 09:09 RPRX

@RPRX

Blocking "Cloudflare - DoH" requires blocking all of Cloudflare reverse proxy IPs since both of its domains are proxied. Currently, I use Xray's built-in DNS option with DoH. However, I have always wondered if it is possible to apply Xray's Fragment option on DoH.

{
   "dns":{
      "tag":"dns",
      "hosts":{
         "cloudflare-dns.com":[
            "104.16.248.249",
            "104.16.249.249"
         ]
      },
      "servers":[
         "https://cloudflare-dns.com/dns-query"
      ]
   }
}

Sep 05 '23 10:09 ghost

Blocking "Cloudflare - DoH" requires blocking all of Cloudflare reverse proxy IPs since both of its domains are proxied. Currently, I use Xray's built-in DNS option with DoH. However, I have always wondered if it is possible to apply Xray's Fragment option on DoH.
{
   "dns":{
      "tag":"dns",
      "hosts":{
         "cloudflare-dns.com":[
            "104.16.248.249",
            "104.16.249.249"
         ]
      },
      "servers":[
         "https://cloudflare-dns.com/dns-query"
      ]
   }
}

this doh config will been blocked by sni due to cloudflare-dns.com this domain

Sep 05 '23 10:09 rhjdvsgsgks

However, I have always wondered if it is possible to apply Xray's Fragment option on DoH.

查看文档，若非 https+local 的写法，DNS 请求也会走路由，所以你可以把它导至 Freedom 出站并进行分片，注意不要造成回环

Looking at the docs, the DNS request would have been routed if it wasn't written in https+local, so you can direct it to the Freedom outbound and shard it, being careful not to cause a loop.

Sep 05 '23 10:09 RPRX

根据 https://t.me/xhqcankao/6131 ，刚刚 https://1.1.1.1 已被中国 GFW 全面封锁，所有省份均不可访问。

前几天我用 Chrome 116 测试 ECH 时，它预设的那几个安全 DNS 只有 1.1.1.1 能直接在中国使用，ECH 测试成功，但显然这一过程和结果在今天已无法复现。虽然仅封锁一个 DoH 并不能完全封锁 ECH，但对于 GFW 的目标而言，它已经迈出了第一步。

根据更多的反馈，目前 GFW 仅针对了 1.1.1.1 的 TCP/443，而 TCP/853、UDP/443 仍能使用，1.0.0.1 的 TCP/443 等仍能使用。

似乎ICMP部分地区也被ban了，部分地区会出现： Pinging 1.1.1.1 with 32 bytes of data: Reply : TTL expired in transit.

It seems that ICMP was also banned in some areas, in some areas you get: Pinging 1.1.1.1 with 32 bytes of data: Reply : TTL expired in transit.

Sep 05 '23 10:09 ifyz

@rhjdvsgsgks

Thats right. Currently, this works in Iran and ISPs don't care about this SNI. However, SNI problem can get solved by fragmenting since Cloudflare CDN accepts fragmenting.

There could be another option. There are websites that really do not require any SNI. For example, you can visit google.com with any SNI. Of course, the only tool I have came across with this option is PowerTunnel. It requires installing a certificate in order to MITM the traffic and change the SNI which isn't very suitable. Also, as it is indicated, changing SNI will break most of websites performance. For example, youtube.com gets loaded with any SNI and even search option works but no video gets played. But in the case of DoH we don't need to visit website. I believe we can use https://dns.google/dns-query with google.com SNI.

Sep 05 '23 10:09 ghost

根据 https://t.me/xhqcankao/6131 ，刚刚 https://1.1.1.1 已被中国 GFW 全面封锁，所有省份均不可访问。

它也許只是想測試損害範圍，所以才封了一個，並且還是最有名最廣泛的cf

It probably just wanted to test the extent of the damage, that's why it blocked just one, and cf's most well-known and widespread one

Sep 05 '23 12:09 nursery01

火狐浏览器设置代理的时候，将dns也代理 network.trr.uri设置成https://1.1.1.1/dns-query 或者其他安全dns network.trr.mode设置为3表示强制使用，2表示优先使用,另外设置dns也要走代理哦。还有就是. 有趣的是，我前几天帮同学安装了一个cloudflare-warp之后，这就发生了，估计又要给她改别的代理软件了。

When Firefox is set up to use a proxy, it proxies the dns as well. network.trr.uri set to https://1.1.1.1/dns-query Or any other secure dns network.trr.mode set to 3 for mandatory use, 2 for priority use, in addition dns must be set to go through the proxy. And then there's this. Interestingly, this happened after I installed cloudflare-warp for a classmate the other day, so I guess I'll have to change her to another proxy software again.

Sep 05 '23 13:09 wangyifan349

network.dns.echconfig.fallback_to_origin_when_all_failed = false：
当所有的 DNS-over-HTTPS (DoH) 服务器都无法连接时，不会回退到传统的非加密 DNS 查询。

network.dns.echconfig.enabled = true：
启用 DNS-over-HTTPS (DoH) 的 ECH (Encrypted Client Hello) 配置，提升 DNS 查询的隐私和安全性。

network.dns.http3_echconfig.enabled = true：
启用使用 ECH 配置的 HTTP/3 连接，为网络通信引入更好的性能和隐私。

network.dns.use_https_rr_as_altsvc = true：
允许使用 HTTPS 的 Resource Record (RR) 作为 Alternative Service (Alt-Svc)，提供资源的替代服务器位置，可能带来更快的连接和增强的安全性。

network.security.esni.enabled = true：
启用 Encrypted Server Name Indication (ESNI)

network.dns.echconfig.fallback_to_origin_when_all_failed = false:
When all DNS-over-HTTPS (DoH) servers are unreachable, there is no fallback to traditional non-encrypted DNS queries.

network.dns.echconfig.enabled = true:
Enable ECH (Encrypted Client Hello) configuration for DNS-over-HTTPS (DoH) to enhance the privacy and security of DNS queries.

network.dns.http3_echconfig.enabled = true:
Enable HTTP/3 connections configured with ECH to introduce better performance and privacy for network communications.

network.dns.use_https_rr_as_altsvc = true:
Allow Resource Record (RR) with HTTPS to act as an Alternative Service (Alt-Svc), providing an alternative server location for resources. May result in faster connections and enhanced security.

network.security.esni.enabled = true:
Enable Encrypted Server Name Indication (ESNI)

Sep 05 '23 13:09 wangyifan349

哈哈哈有cloudflare的ip我们就用户能连的上我们的服务器怕什么。加固火狐需要很多配置的。

Hahaha with cloudflare's ip we have users that can connect to our servers fear nothing. Hardening Firefox requires a lot of configuration.

Sep 05 '23 13:09 wangyifan349

根据 https://t.me/xhqcankao/6131 ，刚刚 https://1.1.1.1 已被中国 GFW 全面封锁，所有省份均不可访问。

前几天我用 Chrome 116 测试 ECH 时，它预设的那几个安全 DNS 只有 1.1.1.1 能直接在中国使用，ECH 测试成功，但显然这一过程和结果在今天已无法复现。虽然仅封锁一个 DoH 并不能完全封锁 ECH，但对于 GFW 的目标而言，它已经迈出了第一步。

根据更多的反馈，目前 GFW 仅针对了 1.1.1.1 的 TCP/443，而 TCP/853、UDP/443 仍能使用，1.0.0.1 的 TCP/443 等仍能使用。

I might be missing something here, but to me blocking 1.1.1.1 on TCP/443 seems more like an attempt to block the WARP website and DoH on 1.1.1.1 than a move against ECH. If the goal is specifically to target ECH, wouldn't blocking the outer SNI, as mentioned by you here, be a more direct and effective approach? However, it's noteworthy that this blocking aligns with the roll out of ECH support, which does seem interesting.

Sep 05 '23 16:09 diwenx

I might be missing something here, but to me blocking 1.1.1.1 on TCP/443 seems more like an attempt to block the WARP website and DoH on 1.1.1.1 than a move against ECH. If the goal is specifically to target ECH, wouldn't blocking the outer SNI, as mentioned by you here, be a more direct and effective approach? However, it's noteworthy that this blocking aligns with the roll out of ECH support, which does seem interesting.

封锁 https://1.1.1.1 只是 相对简单的第一步，就像以前 GFW 从 DNS 污染开始，到后来的 SNI 阻断等。Chrome 116 开了 ECH 后，对于没有 ECH 的域名也会有那个 extension 并有一些数据，但在 GFW 看来 outer SNI 换域名了也说不定，所以若想精准封锁所有真 ECH 还需要一些研究。话说回来，目前还没有人测试 cloudflare-ech.com 有没有随这件事一起被阻断，可能是没有。

此外值得一提的是，封锁 https://1.1.1.1 并没有导致 WARP 无法使用（根据那个讨论区），却会给依赖于 DoH 的 ECH 带来切实的麻烦。如果 GFW 先把境外公开的 DoH 全封了，致使人们没有代理就获取不到 ECH 依赖的数据，也算是初步实现了它的目标。

Blocking https://1.1.1.1 is just a relatively simple first step, just like GFW started with DNS pollution, and later SNI blocking, etc. After Chrome 116 enables ECH, domains that don't have ECH will also have that extension and some data, but in GFW's view outer SNI changed domain names, so it might be possible. So if you want to accurately block all real ECHs, you'll need to do some research. That said, no one has tested whether cloudflare-ech.com is blocked with this, probably not.

It's also worth noting that blocking https://1.1.1.1 doesn't make WARP unusable (according to that discussion forum), but it does cause real problems for DoH-dependent ECHs. If GFW blocks all DoH that is publicly available outside of the country first, so that people can't get ECH-dependent data without proxies, it will have achieved its goal in the first place.

Sep 05 '23 20:09 RPRX

以及如果 GFW 做不到精准封锁所有真 ECH，不能排除的是它很有可能干脆封了那个 extension，就像 ESNI 的遭遇。即使有一天像 Chrome 这样的浏览器默认启用了 ECH，人们也只能进入 chrome://flags 把 ECH 关掉，以换取对境外“正常”网站的直接访问。

And if GFW can't accurately block all true ECHs, it can't be ruled out that it might simply block the extension, like what happened to ESNI. Even if ECH is enabled by default in browsers like Chrome one day, people will have to go to chrome://flags and turn off ECH in order to get direct access to "normal" sites outside the country.

Sep 05 '23 21:09 RPRX

I might be missing something here, but to me blocking 1.1.1.1 on TCP/443 seems more like an attempt to block the WARP website and DoH on 1.1.1.1 than a move against ECH. If the goal is specifically to target ECH, wouldn't blocking the outer SNI, as mentioned by you here, be a more direct and effective approach? However, it's noteworthy that this blocking aligns with the roll out of ECH support, which does seem interesting.

I don't think blocking 1.1.1.1 is a noteworthy signal, many DNS over HTTPS servers have been blocked in China. See also: https://blog.cloudflare.com/fixing-reachability-to-1-1-1-1-globally/

The SNI of ClientHelloOuter can be changed. https://www.ietf.org/archive/id/draft-ietf-tls-esni-16.html#name-offering-ech

The value of ECHConfig.contents.public_name MUST be placed in the "server_name" extension.

Sep 05 '23 22:09 Lanius-collaris

根据 https://t.me/xhqcankao/6131 ，刚刚 https://1.1.1.1 已被中国 GFW 全面封锁，所有省份均不可访问。

According to https://t.me/xhqcankao/6131, just now https://1.1.1.1/ has been completely blocked by China's GFW, all provinces are inaccessible.

There are only 1 or 2 OONI measurements of 1.1.1.1 per day from China. Even before today, most of them presented as anomalous, timeout making a TCP connection.

https://explorer.ooni.org/chart/mat?test_name=web_connectivity&axis_x=measurement_start_day&since=2023-08-06&until=2023-09-15&time_grain=day&probe_cc=CN&input=https%3A%2F%2F1.1.1.1%2Fdns-query%3Fdns%3Dq80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB

Some examples:

date	AS	result
2023-08-20	9808	generic_timeout_error
2023-08-20	56040	generic_timeout_error
2023-09-04	4134	ok
2023-09-04	56040	generic_timeout_error

Sep 06 '23 04:09 wkrp

Pinging 1.1.1.1 with 32 bytes of data: Reply : TTL expired in transit.

@ifyz: "TTL expired in transit" – that's interesting. It means the packet was not dropped or null-routed, but some middlebox sent back an ICMP error packet. I could be wrong, but I don't remember past reports of the GFW using "TTL exceeded" ICMP messages.

Sep 06 '23 04:09 wkrp

There are only 1 or 2 OONI measurements of 1.1.1.1 per day from China. Even before today, most of them presented as anomalous, timeout making a TCP connection.

中国 GFW 有一个介于放行与封锁之间的模糊干扰机制，有一些大站从中国访问会不稳定，但不是完全打不开，比如 github.com

几天前测试时，我试了 https://1.1.1.1 是可以浏览的（实际上很多人都知道它以前没被封），但我确实重启了几次 Chrome 才使得 Cloudflare ECH 测试成功。在昨天的新闻后，也有很多人针对 1.1.1.1 进行了各种测试，结论是 TCP/443 再也无法使用，其它端口的服务却可以，这说明底层路由实际上没有问题，GFW 是封锁且专门封锁了 1.1.1.1 的 TCP/443，与它此前的行为不同。

The Chinese GFW has an obscure interference mechanism between allowing and blocking, and there are some big sites that are unstable from China, but not completely unavailable, like github.com.

When I tested it a few days ago, I tried https://1.1.1.1 and it was viewable (actually many people know it wasn't blocked before), but I did have to restart Chrome a few times to make the Cloudflare ECH test work. After yesterday's news, a lot of people have also run various tests against 1.1.1.1, and the conclusion is that TCP/443 no longer works, while services on other ports do, which suggests that there is in fact no problem with the underlying routing, and that GFW is blocking and exclusively blocking TCP/443 on 1.1.1.1, in a different way than it has previously behaved.

Sep 06 '23 06:09 RPRX

I don't think blocking 1.1.1.1 is a noteworthy signal, many DNS over HTTPS servers have been blocked in China.

是的，很多 DoH 早就被封了，还有些一直没被封的可以说是个奇迹，比如 https://1.1.1.1 ，但 GFW 已经不得不补上这种“漏洞”。

它在这个时间点开始封锁剩下的 DoH，主要会给刚开始推广的 ECH 造成麻烦，因为如果不封的话，这种操作就会被大规模复现。

Yes, many DoHs have been blocked for a long time, and it's a miracle that some haven't been blocked, such as https://1.1.1.1, but GFW has had to close this "loophole".

By blocking the remaining DoHs at this point in time, it will mainly cause problems for ECH, which is just starting to be popularized, because if it is not blocked, this operation will be reproduced on a large scale.

Sep 06 '23 07:09 RPRX

bbs bbs copied to clipboard

Firefox will ship ECH by default

bbs
bbs copied to clipboard