Firefox will ship ECH by default #280
Comments
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: ooni/probe#1453. |
根据 @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.
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. |
Yes
也許中國會封鎖其它國家的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! |
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. |
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. |
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?
ech-tls-dev-ff102.41.0.pcap.gz
Wireshark dissection of Client HelloHandshake 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]
|
不是你的翻譯問題，而是我的描述可能會造成誤解，我的錯 也許我應該用圖像解釋
爲了保證科學嚴謹性，我再做一次測試，但是我使用的是最新版的firefox 117.0 (這裏指的是正式版本，不是開發者版本) 在這之前，我先插入一個插曲，我發現以下描述 摺叠1Users 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.文中描述 回歸正題，我使用以下設定，并且開啓DoH，并且設定為最大保護(這裏指的是always DoH)，我不知道Firefox ESR有沒有這個always功能，如果沒有的話在DoH不可用的情況下會不會回落到普通DNS上？ 我訪問的是 我之前的測試可能也是產生破損導致我看到了 我不知道爲什麽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 1Users 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? I'm accessing My previous test may have also produced a failure that caused me to see 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. |
|
Thank you for running the test. I appreciate it very much.
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
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:
It looks like that text was added between February and March 2020.
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. |
你可以在 You can set
你可能需要设置 You may need to set |
謝謝，我一直是設定為3，我沒有記錯的話，如果啟用ECH這個值默認是2 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） Missing one: If it still doesn't work, set force waiting HTTPS Resource Record (HTTPS RR) |
|
根据 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. |
|
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. |
this doh config will been blocked by sni due to |
查看文档，若非 Looking at the docs, the DNS request would have been routed if it wasn't written in |
似乎ICMP部分地区也被ban了，部分地区会出现： It seems that ICMP was also banned in some areas, in some areas you get: |
|
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 |
它也許只是想測試損害範圍，所以才封了一個，並且還是最有名最廣泛的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 |
|
火狐浏览器设置代理的时候，将dns也代理 When Firefox is set up to use a proxy, it proxies the dns as well. |
|
|
哈哈哈有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. |
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? |
封锁 https://1.1.1.1 只是 相对简单的第一步，就像以前 GFW 从 DNS 污染开始，到后来的 SNI 阻断等。Chrome 116 开了 ECH 后，对于没有 ECH 的域名也会有那个 extension 并有一些数据，但在 GFW 看来 outer SNI 换域名了也说不定，所以若想精准封锁所有真 ECH 还需要一些研究。话说回来，目前还没有人测试 此外值得一提的是，封锁 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 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. |
|
以及如果 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. |
I don't think blocking 1.1.1.1 is a noteworthy signal, many DNS over HTTPS servers have been blocked in China. The SNI of ClientHelloOuter can be changed.
|
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. Some examples:
|
@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. |
中国 GFW 有一个介于放行与封锁之间的模糊干扰机制，有一些大站从中国访问会不稳定，但不是完全打不开，比如 几天前测试时，我试了 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 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. |
是的，很多 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. |
|
@ifyz 你那里能用 1.1.1.1 的其它端口吗？ Do you have access to other ports on 1.1.1.1? |
cmi 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 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. |
|
省級環路不可能只有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 |
有可能是网站显示的问题，当然我是推断。 我所说的其他省的移动网络也存在环路是基于和我同一个省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. |
你指的是 tcping 吧 You mean tcping, right? |
是tcping 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 |
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
|
By the way, try running tcpdump with the
|
#285 is where I have tried to collect all the information in one place. |
|
@flowerinsnowdh 谢谢你的反馈，@ifyz 你那边呢 @flowerinsnowdh Thanks for the feedback, @ifyz How about you? |
@RPRX @wkrp For TEL UNI Ping greater than 200, it should be 1.1.1.1.
抱歉才看到，我对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) UNI： CMI： |
CMI可能封的更徹底，你試試CMI上能不能用QUIC，看這樣子可能是不行 CMI may be more thoroughly blocked, try to use QUIC on CMI, it may not work like this. |
@nursery01 根据我科学上网的体验，我当地三个省运营商并没什么独特的封锁机制，甚至比内地的省还要宽松。 自建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 |
|
也許我應該退出審查和反審查的研究 Maybe I should quit scrutinizing and counter-scrutinizing research |
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:
|
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
|
|
Firefox 119.0, released yesterday (2023-10-24) has ECH support. https://www.mozilla.org/en-US/firefox/119.0/releasenotes/#note-789800
It doesn't say directly whether it's enabled by default, but the linked blog post seems to suggest so.
|
|
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. |
They say in FAQ:
and
|
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
The text was updated successfully, but these errors were encountered: