search

net4people / bbs

Forum for discussing Internet censorship circumvention
3.19k stars 75 forks source link

Firefox will ship ECH by default #280

Open mmmray opened 10 months ago

mmmray commented 10 months ago

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

wkrp commented 10 months ago

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.

RPRX commented 10 months ago

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.

nursery01 commented 10 months ago

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!

wkrp commented 10 months ago

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.

RPRX commented 10 months ago

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.

ignoramous commented 10 months ago

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.

wkrp commented 10 months ago

根据 @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?

  1. Start the browser on a new profile.
  2. Enable DNS over HTTPS in Connection Settings.
  3. Set network.dns.echconfig.enabled=true in about:config. (Per the Mozilla blog. network.dns.use_https_rr_as_altsvc was true by default.)
  4. 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]
nursery01 commented 10 months ago

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.

wkrp commented 10 months ago

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.

0x391F commented 10 months ago

回歸正題，我使用以下設定，并且開啓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.

nursery01 commented 10 months ago

你可以在 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.

0x391F commented 10 months ago

你可以在 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

RPRX commented 10 months ago

根据 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.

ghost commented 10 months ago

@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"
      ]
   }
}
rhjdvsgsgks commented 10 months ago

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

RPRX commented 10 months ago

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.

ifyz commented 10 months ago

根据 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.

ghost commented 10 months ago

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

nursery01 commented 10 months ago

根据 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

wangyifan349 commented 10 months ago

火狐浏览器设置代理的时候，将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.

wangyifan349 commented 10 months ago 
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)
wangyifan349 commented 10 months ago

哈哈哈有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.

diwenx commented 10 months ago

根据 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.

RPRX commented 10 months ago

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.

RPRX commented 10 months ago

以及如果 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.

Lanius-collaris commented 10 months ago

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.

wkrp commented 9 months ago

根据 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
wkrp commented 9 months ago

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.

RPRX commented 9 months ago

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.

RPRX commented 9 months ago

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.

RPRX commented 9 months ago

@ifyz 你那里能用 1.1.1.1 的其它端口吗？

Do you have access to other ports on 1.1.1.1?

ifyz commented 9 months ago

@ifyz 你那里能用 1.1.1.1 的其它端口吗？

cmi tcp 53 443 853都不能响应 tel uni tcp 53 443可以，853不行

我注意到itdog ping检测1.1.1.1结果，部分移动出现1ms响应时间，可能也是出现了省级移动运营商路由环路

这个环路只针对了1.1.1.1，相邻的1.1.1.0 1.1.1.2都能正常路由

Mobile tcp 53 443 853 all do not respond China Unicom tcp 53 443 respond, 853 does not

I noticed that itdog ping test 1.1.1.1 results, some mobile 1ms response time, may also be a provincial mobile operator routing loop

This loop is only for 1.1.1.1, the neighboring 1.1.1.0 1.1.1.1.2 can be routed normally.

nursery01 commented 9 months ago

省級環路不可能只有1ms，能出現1ms的情況，如果是Wi-Fi就是路由器中有審查，如果是5g就是審查系統直接部署在5g收發器上，如果是你手機內部有問題也會出現1ms

Provincial loop is not the only cause of 1ms, 1ms can also appear in the situation: if the Wi-Fi router is doing the censorship, if it is 5g and the censorship system is directly deployed in the 5g transceiver, internal problems at your phone will also appear 1ms

ifyz commented 9 months ago

省級環路不可能只有1ms，能出現1ms的情況，如果是Wi-Fi就是路由器中有審查，如果是5g就是審查系統直接部署在5g收發器上，如果是你手機內部有問題也會出現1ms

有可能是网站显示的问题，当然我是推断。

我所说的其他省的移动网络也存在环路是基于和我同一个省itdog移动监测点，延迟在网站上也表现为1ms推测的。

It's possible that it's a problem with the website display, but of course I'm speculating.

My comment about mobile networks in other provinces also having loops was speculation based on the fact that itdog mobile monitoring sites in the same province as mine, the latency also shows up as 1ms on the website.

RPRX commented 9 months ago

移动tcp 53 443 853都不能响应 电信联通 tcp 53 443可以，853不行

你指的是 tcping 吧

You mean tcping, right?

ifyz commented 9 months ago

移动tcp 53 443 853都不能响应 电信联通 tcp 53 443可以，853不行

你指的是 tcping 吧

是tcping

Yes, tcping.

RPRX commented 9 months ago

Yes, tcping.

延迟看起来是 1.1.1.1 的吗？分别通过三家运营商访问 https://1.1.1.1 具体是什么反应？最终被丢包了还是收到了 RST？https://github.com/net4people/bbs/issues/284

Does the latency appear to be correct for 1.1.1.1? What exactly is the response to accessing https://1.1.1.1 through three separate carriers? Did it end up dropping packets or receiving an RST? https://github.com/net4people/bbs/issues/284

flowerinsnowdh commented 9 months ago

Yes, tcping.

延迟看起来是 1.1.1.1 的吗？分别通过三家运营商访问 https://1.1.1.1 具体是什么反应？最终被丢包了还是收到了 RST？#284

Does the latency appear to be correct for 1.1.1.1? What exactly is the response to accessing https://1.1.1.1 through three separate carriers? Did it end up dropping packets or receiving an RST? #284

根据 tcpdump 监测，在 TCP 发送 SYN 报文到 1.1.1.1:443 但不发送任何后续内容后，10毫秒后就收到了来自 1.1.1.1:443 的连续3次 RST 报文

其中 seq 值有概率都是0，有概率都是1；ack 值（第一次有概率是 SYN 时的 seq+1，有概率是1），其余两次都是1；win值是三个不确定的数，每次+1；第三次 RST 报文中有一些额外选项，例如mss

According to tcpdump monitoring, after TCP sends a SYN message to 1.1.1.1:443 but doesn't send any followups, three consecutive RST messages from 1.1.1.1:443 are received 10 milliseconds later

Where the seq value has a probability of all being 0 and a probability of all being 1; the ack value (the first time has a probability of being seq+1 at SYN and a probability of being 1), and the remaining two times are 1; the win value is three indeterminate numbers, +1 each time; and the third RST message has a few extra options, such as mss

wkrp commented 9 months ago

其中 seq 值有概率都是0，有概率都是1；ack 值（第一次有概率是 SYN 时的 seq+1，有概率是1），其余两次都是1；win值是三个不确定的数，每次+1；第三次 RST 报文中有一些额外选项，例如mss

Where the seq value has a probability of all being 0 and a probability of all being 1; the ack value (the first time has a probability of being seq+1 at SYN and a probability of being 1), and the remaining two times are 1; the win value is three indeterminate numbers, +1 each time; and the third RST message has a few extra options, such as mss

I am going to start a new thread to collect information about this kind of RST injection against 1.1.1.1:443. But I will note here that what you have described (and what I have seen also) matches what the "Your State is Not Mine" paper calls a "type-2 reset", except in one detail. They document incremental +1 window sizes as well, but the difference is that they saw different sequence numbers in each of the 3 injected packets (which has also been documented as far back as 2006), whereas now we see the same sequence number in all 3 injected packets.

https://censorbib.nymity.ch/pdf/Wang2017a.pdf#page=2

According to previous work [ 3 , 25 ] and our measurements, RST (type-1) and RST/ACK (type-2) are likely from two types of GFW instances that usually exist together. We have encountered some occurences where a type-1 or a type-2 reset occurs individually; thus, we are able to measure their features separately. Type-1 reset has only the RST flag set, and random TTL value and window sizes, while type-2 reset has the RST and ACK flags set, and cyclically increasing TTL value and window sizes.

Once a sensitive keyword detected, the GFW sends one type-1 RST and three type-2 RST/ACK with sequence numbers X, X+1460 and X+4380 (X is the current server-side sequence number).

wkrp commented 9 months ago

其中 seq 值有概率都是0，有概率都是1；ack 值（第一次有概率是 SYN 时的 seq+1，有概率是1），其余两次都是1

By the way, try running tcpdump with the --absolute-tcp-sequence-numbers option. By default, tcpdump shows relative sequence numbers, not absolute. seq=1 and ack=1 is not really literally 1; in fact it may actually be the same as the previous value.

relative sequence numbers absolute sequence numbers 
seq 0, ack X
seq 0, ack 1
seq 0, ack 1
 
seq 0, ack X
seq 0, ack X
seq 0, ack X

seq 1, ack 1
seq 1, ack 1
seq 1, ack 1

seq Y, ack Z
seq Y, ack Z
seq Y, ack Z
wkrp commented 9 months ago

I am going to start a new thread to collect information about this kind of RST injection against 1.1.1.1:443.

285 is where I have tried to collect all the information in one place.

RPRX commented 9 months ago

@flowerinsnowdh 谢谢你的反馈，@ifyz 你那边呢

@flowerinsnowdh Thanks for the feedback, @ifyz How about you?

ifyz commented 9 months ago

延迟看起来是 1.1.1.1 的吗？

@RPRX @wkrp 对于 TEL UNI Ping大于200，应该是1.1.1.1的。 对于CMI有些奇怪的现象如下。 正在 Ping 1.1.1.1 具有 32 字节的数据: 来自 117.191.*.* 的回复: TTL 传输中过期。 来自 117.191.*.* 的回复: TTL 传输中过期。 来自 117.191.*.* 的回复: TTL 传输中过期。 来自 117.191.*.* 的回复: TTL 传输中过期。 里面的ip是当地省级运营商的ip

For TEL UNI Ping greater than 200, it should be 1.1.1.1. For CMI some strange phenomenon as below. Pinging 1.1.1.1 with 32 bytes of data. Reply from 117.191.*.*: TTL expired in transit. Reply from 117.191.*.*: TTL expired in transit. Reply from 117.191.*.*: TTL expired in transit. Reply from 117.191.*.*: TTL expired in transit. The ip inside is the ip of the local provincial operator.

@flowerinsnowdh 谢谢你的反馈，@ifyz 你那边呢

@flowerinsnowdh Thanks for the feedback, @ifyz How about you?

抱歉才看到，我对tcp握手只停留在计网课的水平，不懂分析，就稍微抓了一下包。

Sorry just saw it, I'm only at the online classes level for tcp handshakes, I don't know how to analyze them, so I just captured a few packets.

(removed time for privacy) TEL： tcpdump -i ens33 host 1.1.1.1 -v tcpdump: listening on ens33, link-type EN10MB (Ethernet), snapshot length 262144 bytes IP (tos 0x0, ttl 64, id 34769, offset 0, flags [DF], proto TCP (6), length 60) 192.168.8.3.40230 > 1.1.1.1.https: Flags [S], cksum 0xcadb (incorrect -> 0x3694), seq 1837107700, win 64240, options [mss 1460,sackOK,TS val 3221976428 ecr 0,nop,wscale 7], length 0 IP (tos 0x0, ttl 128, id 65343, offset 0, flags [none], proto TCP (6), length 44) 1.1.1.1.https > 192.168.8.3.40230: Flags [S.], cksum 0x3343 (correct), seq 983387713, ack 1837107701, win 64240, options [mss 1460], length 0 IP (tos 0x0, ttl 128, id 65344, offset 0, flags [none], proto TCP (6), length 40) 1.1.1.1.https > 192.168.8.3.40230: Flags [R.], cksum 0x4afc (correct), seq 1, ack 1, win 64240, length 0 IP (tos 0x0, ttl 64, id 34770, offset 0, flags [DF], proto TCP (6), length 40) 192.168.8.3.40230 > 1.1.1.1.https: Flags [.], cksum 0xcac7 (incorrect -> 0x4b00), ack 1, win 64240, length 0 IP (tos 0x0, ttl 128, id 65345, offset 0, flags [none], proto TCP (6), length 40) 1.1.1.1.https > 192.168.8.3.40230: Flags [R], cksum 0x3d73 (correct), seq 983387714, win 32767, length 0 IP (tos 0x0, ttl 64, id 60726, offset 0, flags [DF], proto TCP (6), length 60) 192.168.8.3.40246 > 1.1.1.1.https: Flags [S], cksum 0xcadb (incorrect -> 0x1f6c), seq 1145718140, win 64240, options [mss 1460,sackOK,TS val 3221977650 ecr 0,nop,wscale 7], length 0 IP (tos 0x0, ttl 128, id 65346, offset 0, flags [none], proto TCP (6), length 44) 1.1.1.1.https > 192.168.8.3.40246: Flags [S.], cksum 0xe0b3 (correct), seq 1438217042, ack 1145718141, win 64240, options [mss 1460], length 0 IP (tos 0x0, ttl 64, id 60727, offset 0, flags [DF], proto TCP (6), length 40) 192.168.8.3.40246 > 1.1.1.1.https: Flags [.], cksum 0xcac7 (incorrect -> 0xf870), ack 1, win 64240, length 0 IP (tos 0x0, ttl 64, id 60728, offset 0, flags [DF], proto TCP (6), length 425) 192.168.8.3.40246 > 1.1.1.1.https: Flags [P.], cksum 0xcc48 (incorrect -> 0xfac7), seq 1:386, ack 1, win 64240, length 385 IP (tos 0x0, ttl 128, id 65347, offset 0, flags [none], proto TCP (6), length 40) 1.1.1.1.https > 192.168.8.3.40246: Flags [.], cksum 0xf6ef (correct), ack 386, win 64240, length 0 IP (tos 0x0, ttl 128, id 65348, offset 0, flags [none], proto TCP (6), length 40) 1.1.1.1.https > 192.168.8.3.40246: Flags [R.], cksum 0xf6eb (correct), seq 1, ack 386, win 64240, length 0

UNI： tcpdump -i ens33 host 1.1.1.1 -v tcpdump: listening on ens33, link-type EN10MB (Ethernet), snapshot length 262144 bytes IP (tos 0x0, ttl 64, id 19491, offset 0, flags [DF], proto TCP (6), length 60) 192.168.8.3.60212 > 1.1.1.1.https: Flags [S], cksum 0xcadb (incorrect -> 0xd2d9), seq 2493099326, win 64240, options [mss 1460,sackOK,TS val 3221078210 ecr 0,nop,wscale 7], length 0 IP (tos 0x0, ttl 128, id 65306, offset 0, flags [none], proto TCP (6), length 44) 1.1.1.1.https > 192.168.8.3.60212: Flags [S.], cksum 0x4d58 (correct), seq 43275203, ack 2493099327, win 64240, options [mss 1460], length 0 IP (tos 0x0, ttl 64, id 19492, offset 0, flags [DF], proto TCP (6), length 40) 192.168.8.3.60212 > 1.1.1.1.https: Flags [.], cksum 0xcac7 (incorrect -> 0x6515), ack 43275204, win 64240, length 0 IP (tos 0x0, ttl 64, id 19493, offset 0, flags [DF], proto TCP (6), length 425) 192.168.8.3.60212 > 1.1.1.1.https: Flags [P.], cksum 0xcc48 (incorrect -> 0xef20), seq 2493099327:2493099712, ack 43275204, win 64240, length 385 IP (tos 0x0, ttl 128, id 65307, offset 0, flags [none], proto TCP (6), length 40) 1.1.1.1.https > 192.168.8.3.60212: Flags [.], cksum 0x6394 (correct), ack 2493099712, win 64240, length 0 IP (tos 0x0, ttl 128, id 65308, offset 0, flags [none], proto TCP (6), length 40) 1.1.1.1.https > 192.168.8.3.60212: Flags [R.], cksum 0x6390 (correct), seq 43275204, ack 2493099712, win 64240, length 0

CMI： tcpdump -i ens33 host 1.1.1.1 -v tcpdump: listening on ens33, link-type EN10MB (Ethernet), snapshot length 262144 bytes IP (tos 0x0, ttl 64, id 55060, offset 0, flags [DF], proto TCP (6), length 60) 192.168.8.3.44126 > one.one.one.one.https: Flags [S], cksum 0xcadb (incorrect -> 0x8654), seq 805859481, win 64240, options [mss 1460,sackOK,TS val 1598377485 ecr 0,nop,wscale 7], length 0 IP (tos 0x0, ttl 64, id 55061, offset 0, flags [DF], proto TCP (6), length 60) 192.168.8.3.44126 > one.one.one.one.https: Flags [S], cksum 0xcadb (incorrect -> 0x8260), seq 805859481, win 64240, options [mss 1460,sackOK,TS val 1598378497 ecr 0,nop,wscale 7], length 0 IP (tos 0x0, ttl 64, id 55062, offset 0, flags [DF], proto TCP (6), length 60) 192.168.8.3.44126 > one.one.one.one.https: Flags [S], cksum 0xcadb (incorrect -> 0x7a7c), seq 805859481, win 64240, options [mss 1460,sackOK,TS val 1598380517 ecr 0,nop,wscale 7], length 0

nursery01 commented 9 months ago

目前 GFW 仅针对了 1.1.1.1 的 TCP/443，而 TCP/853、UDP/443 仍能使用

对于 TEL UNI Ping大于200，应该是1.1.1.1的。 对于CMI有些奇怪的现象如下。 正在 Ping 1.1.1.1 具有 32 字节的数据: 来自 117.191.. 的回复: TTL 传输中过期。

CMI可能封的更徹底，你試試CMI上能不能用QUIC，看這樣子可能是不行

CMI may be more thoroughly blocked, try to use QUIC on CMI, it may not work like this.

ifyz commented 9 months ago

目前 GFW 仅针对了 1.1.1.1 的 TCP/443，而 TCP/853、UDP/443 仍能使用

对于 TEL UNI Ping大于200，应该是1.1.1.1的。

对于CMI有些奇怪的现象如下。

正在 Ping 1.1.1.1 具有 32 字节的数据:

来自 117.191.. 的回复: TTL 传输中过期。

CMI可能封的更徹底，你試試CMI上能不能用QUIC，看這樣子可能是不行

CMI may be more thoroughly blocked, try to use QUIC on CMI, it may not work like this.

@nursery01 cmi那个是省运营商特意破坏了到1.1.1.1路由，我觉得没什么参考意义

根据我科学上网的体验，我当地三个省运营商并没什么独特的封锁机制，甚至比内地的省还要宽松。

自建quic协议是可以使用的，数裸vmess+tcp也可以用。

除了遇到过使用wss协议导致端口背墙了一个月，还没遇到过整个ip都被墙的情况

The cmi one is deliberately corrupted by provincial carriers to 1.1.1.1 routing, which I don't think is much of a reference point

Based on my systematic experience with internet access, my three local provincial carriers don't have any unique blocking mechanisms, even more lenient than the mainland provinces.

Self-built quic protocols are usable, as are several bare vmess+tcp.

Except for the fact that I've had a port walled for a month due to the use of the wss protocol, I haven't encountered a situation where the entire ip is walled off

nursery01 commented 9 months ago

也許我應該退出審查和反審查的研究

Maybe I should quit scrutinizing and counter-scrutinizing research

wkrp commented 8 months ago

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.

The bugzilla bug has been closed. The developers don't plan to do anything immediately to prevent OSCP leaks with ECH, other than improve the documentation and continue working towards integrating CRLite (which will make OCSP unnecessary).

These are Mozilla's recommendations for preventing OCSP leaks with ECH:

https://wiki.mozilla.org/index.php?title=Security/Encrypted_Client_Hello&oldid=1248531#Interaction_with_Revocation_Checking

Interaction with Revocation Checking

Firefox supports various methods for checking whether certificates have been revoked including OCSP, OCSP Stapling and (experimentally) CRLite. OCSP requires querying the certificate's revocation status with the issuing CA and so leaks information about the site a user is visiting. Consequently, sites deploying ECH should also use OCSP Stapling or short lived certificates which don't involve any network communication and so improves user privacy (Cloudflare deploy OCSP Stapling universally). If sites do not use OCSP Stapling, then ECH still provides a substantial privacy benefit as OCSP responses are cached for multiple days and so the majority of site visits will be protected. In the longer term, CRLite will allow for privacy preserving revocation checking without requiring action by site operators.

Users who prefer improved privacy over the security of revocation checking can disable revocation via the browser UX in about:preferences (or in about:config by preference).

wkrp commented 8 months ago

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

OONI's September 2023 monthly report links to a post by Divyank Katira of CIS India about adding an ECH experiment to OONI Probe.

https://cis-india.org/internet-governance/blog/detecting-encrypted-client-hello-ech-blocking

We have been tracking the development of this privacy enhancement. To assist the successful deployment of the ECH protocol, we contributed a new censorship test to the Open Observatory for Network Interference (OONI) late last year. The new test attempts to connect to websites using the ECH protocol and records any interference from censors to the connection. As censors in some countries were found blocking a previous version of the protocol entirely, this test gives important early feedback to the protocol developers on whether censors are able to detect and block the protocol.

We conducted ECH tests during the first week of September 2023 from four popular Indian ISPs, namely Airtel, Atria Convergence Technologies (ACT), Reliance Jio, and Vodafone Idea, which account for around 95% of the Indian internet subscriber base. The results indicated that ECH connections to a popular website were successful and are not currently being blocked. This was the expected result, as the protocol is still under development. We will continue to monitor for interference from censors closer to the time of completion of the protocol to ensure that this privacy enhancing protocol is successfully deployed.

wkrp commented 8 months ago

Firefox 119.0, released yesterday (2023-10-24) has ECH support.

https://www.mozilla.org/en-US/firefox/119.0/releasenotes/#note-789800

Encrypted Client Hello (ECH) is now available to Firefox users, delivering a more private browsing experience. ECH extends the encryption used in TLS connections to cover more of the handshake and better protect sensitive fields. Read more about the launch of ECH on Mozilla Distilled.

It doesn't say directly whether it's enabled by default, but the linked blog post seems to suggest so.

Privacy as a default.

While Mozilla believes that privacy and security technologies should be available by default for all users, we also recognize that in certain circumstances, users may have alternative preferences, for example, if they are relying on family safety software at home, are using network-based ad blocking or are in an enterprise environment. ECH is designed to interoperate with these practices and respect the existing DoH opt-outs in Firefox, so these users won’t need to make any changes to continue enjoying a smooth and safe Firefox experience. Similarly, if users or administrators have opted-in to the increased or maximum levels of DoH protection, their decision will likewise be respected.

ghost commented 8 months ago

@wkrp

Why famous service providers like Google and Cloudflare don't provide their DoH addresses using PATH and they specify another domain? Currently blocking DoH is too easy and therefore, blocking ECH is also easy.

https://google.com/dns/dns-query
https://cloudflare.com/dns/dns-query