在启用TCP Timestamp（TCP时间戳）后，GFW对obfs4的审查无效 / After enabling TCP Timestamp, GFW's censorship of obfs4 is rendered ineffective

[ThEWiZaRd0fBsoD]

（我太兴奋了，重写一下，之前有大量错误，并且重新进行实验）

在之前我看到这么一篇博客文章，提到TCP时间戳选项会影响河南省墙的判断。

我对这个说法保持怀疑，但想到如果头部多出十个字节的明文，那么应该可以干扰GFW对obfs4的判断（众所周知，obfs4在中国已经被屏蔽很长一段时间）。

于是我自己配置了一个obfs4 iat-mode=2的网桥，将Windows设置为同时启用TCP窗口和TCP时间戳。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts（设置为3）

很有趣的是：obfs4网桥就此恢复正常使用，就好像GFW从来没有侦测到过它一样。

这里是抓包文件，其他人能很明显地发现，到达网桥的通信（TCP 17120端口）从未被干扰/阻止。

即使在我已经在听歌，这段通信依旧未被阻止。

网桥地址：obfs4 172.236.211.247:17120 126E14CC2C03133E70FBBF306D76D75AA96D47EB cert=ubysetrGTVF+eux3IDgjC/w9u6xjGGNUnz89U2zkuDFCF3lQsWb0FuB9qfG6TzN1AL73HA iat-mode=2

---

(I'm so excited, I've rewritten it, there were a lot of mistakes before, and I've done the experiment again)

Previously, I read a blog post that mentioned the TCP timestamp option would affect the Henan Province wall's judgment.

I was skeptical of this claim, but thought that if there were ten more bytes of plaintext in the header, it should be able to interfere with the GFW's judgment of obfs4 (as we all know, obfs4 has been blocked in China for a long time).

So I configured an obfs4 iat-mode=2 bridge myself, and set Windows to enable both TCP window and TCP timestamp.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts (set to 3)

It's interesting: the obfs4 bridge then returned to normal use, as if the GFW had never detected it.

Here is the packet capture file, and it is obvious to anyone else that the communication to the bridge (TCP port 17120) has never been interfered with/blocked.

Even when I was already listening to music, this communication was still not blocked.

bridge line: obfs4 172.236.211.247:17120 126E14CC2C03133E70FBBF306D76D75AA96D47EB cert=ubysetrGTVF+eux3IDgjC/w9u6xjGGNUnz89U2zkuDFCF3lQsWb0FuB9qfG6TzN1AL73HA iat-mode=2

呃

Um

[ThEWiZaRd0fBsoD]

呃

我上午太兴奋了所以写下了不少错误，现在重写了（扶额）。

I was so excited this morning that I made a lot of mistakes when writing, so I've rewritten it now (with my hands on my forehead).

在2024年5月我用比较严谨的实验证明 河南固定宽带网络之所以开了tcp timestamps情况会跟没开有所不同，并不是省墙能力不足，而是河南的省墙在固定宽带网络上故意放过了 tcp header length不等于5的数据包。

而出口GFW并没有这个关于tcp timestamps或tcp header length的豁免规则。至于封禁obfs4网桥应该是出口GFW的工作/任务才对。

In May 2024, I used more rigorous experiments to prove that the reason why the Henan fixed broadband network has enabled tcp timestamps is that the situation will be different from not enabling it. It is not that the provincial firewall is insufficient, but that the provincial firewall in Henan deliberately passes packets on the fixed broadband network with a tcp header length that is not equal to 5.

However, the egress GFW does not have this exemption rule for tcp timestamps or tcp header length. As for blocking the obfs4 bridge, that should be the job/task of the egress GFW.

[gfw-report]

在2024年5月我用比较严谨的实验证明 河南固定宽带网络之所以开了tcp timestamps情况会跟没开有所不同，并不是省墙能力不足，而是河南的省墙在固定宽带网络上故意放过了 tcp header length不等于5的数据包。

Hi @5e2t, your observation and conclusion align with our experimental findings on the Henan Firewall. Below is an excerpt from our unpublished documentation:

TCP header length has to be 20 bytes. The four most significant bits of the 13th byte of the TCP header represent the TCP Data Offset, which specifies the length of the TCP header in 32-bit words. The minimum value of the TCP Data Offset field is 5 words (20 bytes) when no TCP options are present, and the maximum value is 15 words (60 bytes). We found that the Henan Firewall required the TCP header length to be exactly 20 bytes to correctly parse and block the TLS ClientHello or HTTP request messages. We tested this by sending forbidden messages (e.g. TLS ClientHello messages with a forbidden SNI 011.com) from our vantage point in Henan to our sink server in Guangzhou on October 17, 2024, with different TCP options set in their TCP headers. While varying the TCP header length, we made sure that the TCP options is always a multiple of 4 bytes to comply with the 32-bit word alignment requirement of TCP header. The TCP options we tested include common TCP ones like Maximum Segment Size (MSS), Window Scale, Timestamps, Selective Acknowledgment Permitted (SAckOk), No Option (NOP), End of Option List (EOL), as well as self-defined TCP options that are not commonly used. We found that as long as any TCP option was set, the Henan Firewall did not block the connection.

A possible explanation for this strange behavior is that the Henan Firewall does not parse the TCP header length field in the TCP header, and falsely assumes that the TCP header length is always 20 bytes. This way, when a TCP header has more than 20 bytes due to TCP options, it will treat the TCP options as part of the TCP payload and will thus fail to recognize a complete TLS ClientHello or HTTP request message. However, we falsified this hypothesis and confirmed the Henan Firewall did parse the TCP header length field. In particular, we sent TLS ClientHello messages with a forbidden SNI 011.com with no TCP option set in its TCP header, confirming that this message was blocked by the Henan Firewall. If the Henan Firewall does not parse the TCP header length field in the TCP header, then regardless of the TCP header length value we put in the TCP header, this message should be blocked. We changed the 4-bit TCP header length field in the TCP header to be all 24 possible values from 0 to 15, and recomputed the correct TCP checksum for each TCP packet, and found that the Henan Firewall only blocked a connection when its TCP header length value was 5 words (20 bytes). This experiment indicates that the Henan Firewall did parse the TCP header length field in the TCP header, but had a condition to only block a connection when its TCP header length is 20 bytes.

Although we were unable to determine the rationale behind this condition — possibly an oversight by the censor — it raises an important question about how much real-world traffic evaded detection due to this condition. We conducted a test on a university network tap in the United States. Specifically, we captured the TCP header length fields for all traffic on the network tap over a one-hour period from 10:56:14 PM to 11:56:14 PM (UTC) on October 31, 2024. In total, we collected 23.1 billion TCP packets and 5.0 billion TLS packets. As shown in Figure 6, only 22% of the TCP packets had a header length of 20 bytes, and only 19% of the TLS packets had a header length of 20 bytes. This result suggests that the Henan Firewall may only be able to censor around 20% of the targeted connections.

在2024年5月我用比较严谨的实验证明 河南固定宽带网络之所以开了tcp timestamps情况会跟没开有所不同，并不是省墙能力不足，而是河南的省墙在固定宽带网络上故意放过了 tcp header length不等于5的数据包。

Hi @5e2t, your observation and conclusion align with our experimental findings on the Henan Firewall. Below is an excerpt from our unpublished documentation:

TCP header length has to be 20 bytes. The four most significant bits of the 13th byte of the TCP header represent the TCP Data Offset, which specifies the length of the TCP header in 32-bit words. The minimum value of the TCP Data Offset field is 5 words (20 bytes) when no TCP options are present, and the maximum value is 15 words (60 bytes). We found that the Henan Firewall required the TCP header length to be exactly 20 bytes to correctly parse and block the TLS ClientHello or HTTP request messages. We tested this by sending forbidden messages (e.g. TLS ClientHello messages with a forbidden SNI 011.com) from our vantage point in Henan to our sink server in Guangzhou on October 17, 2024, with different TCP options set in their TCP headers. While varying the TCP header length, we made sure that the TCP options is always a multiple of 4 bytes to comply with the 32-bit word alignment requirement of TCP header. The TCP options we tested include common TCP ones like Maximum Segment Size (MSS), Window Scale, Timestamps, Selective Acknowledgment Permitted (SAckOk), No Option (NOP), End of Option List (EOL), as well as self-defined TCP options that are not commonly used. We found that as long as any TCP option was set, the Henan Firewall did not block the connection.

A possible explanation for this strange behavior is that the Henan Firewall does not parse the TCP header length field in the TCP header, and falsely assumes that the TCP header length is always 20 bytes. This way, when a TCP header has more than 20 bytes due to TCP options, it will treat the TCP options as part of the TCP payload and will thus fail to recognize a complete TLS ClientHello or HTTP request message. However, we falsified this hypothesis and confirmed the Henan Firewall did parse the TCP header length field. In particular, we sent TLS ClientHello messages with a forbidden SNI 011.com with no TCP option set in its TCP header, confirming that this message was blocked by the Henan Firewall. If the Henan Firewall does not parse the TCP header length field in the TCP header, then regardless of the TCP header length value we put in the TCP header, this message should be blocked. We changed the 4-bit TCP header length field in the TCP header to be all 24 possible values from 0 to 15, and recomputed the correct TCP checksum for each TCP packet, and found that the Henan Firewall only blocked a connection when its TCP header length value was 5 words (20 bytes). This experiment indicates that the Henan Firewall did parse the TCP header length field in the TCP header, but had a condition to only block a connection when its TCP header length is 20 bytes.

Although we were unable to determine the rationale behind this condition — possibly an oversight by the censor — it raises an important question about how much real-world traffic evaded detection due to this condition. We conducted a test on a university network tap in the United States. Specifically, we captured the TCP header length fields for all traffic on the network tap over a one-hour period from 10:56:14 PM to 11:56:14 PM (UTC) on October 31, 2024. In total, we collected 23.1 billion TCP packets and 5.0 billion TLS packets. As shown in Figure 6, only 22% of the TCP packets had a header length of 20 bytes, and only 19% of the TLS packets had a header length of 20 bytes. This result suggests that the Henan Firewall may only be able to censor around 20% of the targeted connections.

在河南固定宽带网络上，仅阻断tcp header length为5的流量，从节省算力的角度来讲，也是说的通的。不可能是技术人员疏忽的原因，毕竟先检查4比特 tcp header length，根据header length的值 来决定是否进入 一个继续检查其他字段的 ”分岔路口“，本来就是在节省算力方面效率比较高的行为。

而且在河南数据流量网络上不仅不会放过有 tcp option的流量，也不会放过 tcp fast open流量，也不会放过client hello分片流量（即便servername写在第二个clienthello分片也没用，只有给分片之间加延迟才可避免被阻断）。

几乎只有两种可能性，1.为了节省算力，2.不想这个墙影响范围太广。（具体是哪种原因则不得而知）

On the Henan fixed broadband network, only traffic with a tcp header length of 5 is blocked, which also makes sense from the perspective of saving computing power. It is impossible that it is due to negligence on the part of the technical staff. After all, first checking the 4-bit tcp header length and then deciding whether to enter a “fork in the road” that continues to check other fields based on the value of the header length is inherently an action that is more efficient in terms of saving computing power.

Moreover, on the Henan data traffic network, not only will traffic with tcp options not be spared, but also tcp fast open traffic and client hello fragmentation traffic (even if the servername is written in the second clienthello fragment, it is useless, and only adding a delay between fragments can prevent blocking).

There are almost only two possibilities: 1. to save computing power, 2. do not want this wall to have a wide range of influence. (It is not known which reason is actually the case.)

[gfw-report]

不可能是技术人员疏忽的原因，毕竟先检查4比特 tcp header length，根据header length的值 来决定是否进入 一个继续检查其他字段的 ”分岔路口“，

We agree with you that it's unlikely to be an "oversight" by the censor as they intentionally checked for this field.

几乎只有两种可能性，1.为了节省算力，2.不想这个墙影响范围太广。（具体是哪种原因则不得而知）

For your second conjecture, it would be helpful to understand which Operating System will send TCP packets without any TCP options. Do you have any idea on this? Any specific examples would be very helpful.

而且在河南数据流量网络上不仅不会放过有 tcp option的流量，也不会放过 tcp fast open流量，也不会放过client hello分片流量（即便servername写在第二个clienthello分片也没用，只有给分片之间加延迟才可避免被阻断）。

These observations are very interesting. We, unfortunately, haven't been able to obtain a vantage point to test the Henan mobile network. Do you have any suggestions on how we can obtain such vantage points for testing? (Please feel free to reach out to us privately if you consider this information sensitive. Thank you!)

@gfw-report XTLS/Xray-core#3601 (comment)
XTLS/Xray-core#3601 (comment)
XTLS/Xray-core#3601 (comment)
XTLS/Xray-core#3601 (comment)
XTLS/Xray-core#3601 (comment)
再结合出口GFW 对于 servername 写在了第一个ClientHello分片里，但是clientHello分片之间加了延迟的情况是无法阻断的。XTLS/Xray-core#3601 (comment)

我这个测试结果或许能说明河南的省墙在解析ClientHello方面用了比出口GFW更加高级的方式，就是说有不止一种出口GFW无法阻断的clientHello形态，河南的省墙都能阻断：
1.TFO ClientHello
2.ClientHello分片
3.自己随便组装的一个TLS option只有servername字段且 TLS option length填写的并不正确。
4. XTLS/Xray-core#3660 的ClientHello分片之后在同一个TCP包里发送。
当然我是按照河南数据流量网络上的省墙来说的。那个是完全体。

以上4个例子都是出口GFW无法阻断，但河南的省墙可以阻断的情况，可以想象设计河南省墙的人就没有任何可能性犯那个 假定 所有TCP包的 TCP头都是20字节的 低级错误。

XTLS/Xray-core#3601 (comment)
然后河南数据流量网络上的省墙还会 对 tcp syn包发送RST。

也就是说，河南数据流量网络上的省墙，能观测到极多 河南固定宽带网络上的省墙所没有的行为，如果把数据流量网络上的省墙的所有行为都搬到 固定宽带网络上的话，可能算力的确不够用吧。

---

@gfw-report XTLS/Xray-core#3601 (comment)
XTLS/Xray-core#3601 (comment)
XTLS/Xray-core#3601 (comment)
XTLS/Xray-core#3601 (comment)
XTLS/Xray-core#3601 (comment)
In combination with the egress GFW, if the servername is written in the first ClientHello fragment, but a delay is added between the ClientHello fragments, the connection cannot be blocked. XTLS/Xray-core#3601 (comment)

My test results may indicate that the Henan provincial firewall uses a more advanced method than the egress GFW for parsing ClientHello. In other words, there is more than one ClientHello format that the egress GFW cannot block, and the Henan provincial firewall can block them all:

1. TFO ClientHello
2. ClientHello fragmentation
3. A TLS option assembled at random by itself, with only the servername field and the TLS option length incorrectly filled in.
4. TLS Hello Fragmenting: New Single TLS Hello Fragmenting Method XTLS/Xray-core#3660 ClientHello fragmentation followed by sending in the same TCP packet.

Of course, I'm talking about the provincial wall on the Henan data traffic network. That's the complete version.

The above four examples are all cases where the egress GFW cannot block, but the Henan provincial wall can be blocked. One can imagine that the person who designed the Henan provincial wall did not have any possibility of making the basic mistake of assuming that the TCP header of all TCP packets is 20 bytes.

XTLS/Xray-core#3601 (comment)
Then the provincial wall on the Henan data traffic network will also send an RST to the TCP SYN packet.

In other words, one can observe a lot of behaviors on the provincial wall of the Henan data traffic network that the provincial walls of the Henan fixed broadband network do not have. If all the behaviors of the provincial wall on the data traffic network are moved to the fixed broadband network, it may be that the computing power is indeed insufficient.

不可能是技术人员疏忽的原因，毕竟先检查4比特 tcp header length，根据header length的值 来决定是否进入 一个继续检查其他字段的 ”分岔路口“，

We agree with you that it's unlikely to be an "oversight" by the censor as they intentionally checked for this field.

几乎只有两种可能性，1.为了节省算力，2.不想这个墙影响范围太广。（具体是哪种原因则不得而知）

For your second conjecture, it would be helpful to understand which Operating System will send TCP packets without any TCP options. Do you have any idea on this? Any specific examples would be very helpful.

而且在河南数据流量网络上不仅不会放过有 tcp option的流量，也不会放过 tcp fast open流量，也不会放过client hello分片流量（即便servername写在第二个clienthello分片也没用，只有给分片之间加延迟才可避免被阻断）。

These observations are very interesting. We, unfortunately, haven't been able to obtain a vantage point to test the Henan mobile network. Do you have any suggestions on how we can obtain such vantage points for testing? (Please feel free to reach out to us privately if you consider this information sensitive. Thank you!)

Linux系统和一般的安卓手机都是打开tcp timestamps的，而Windows默认并没有打开tcp timestamps。

Linux systems and Android phones in general enable tcp timestamps, while Windows does not enable tcp timestamps by default.

不可能是技术人员疏忽的原因，毕竟先检查4比特 tcp header length，根据header length的值 来决定是否进入 一个继续检查其他字段的 ”分岔路口“，

We agree with you that it's unlikely to be an "oversight" by the censor as they intentionally checked for this field.

几乎只有两种可能性，1.为了节省算力，2.不想这个墙影响范围太广。（具体是哪种原因则不得而知）

For your second conjecture, it would be helpful to understand which Operating System will send TCP packets without any TCP options. Do you have any idea on this? Any specific examples would be very helpful.

而且在河南数据流量网络上不仅不会放过有 tcp option的流量，也不会放过 tcp fast open流量，也不会放过client hello分片流量（即便servername写在第二个clienthello分片也没用，只有给分片之间加延迟才可避免被阻断）。

These observations are very interesting. We, unfortunately, haven't been able to obtain a vantage point to test the Henan mobile network. Do you have any suggestions on how we can obtain such vantage points for testing? (Please feel free to reach out to us privately if you consider this information sensitive. Thank you!)

至于如何获得河南数据流量网络的测试环境，呃，也只能把一台安装了中国手机卡的手机放在河南连入数据流量网络，然后在上面跑代理。只不过麻烦的事情在于，数据流量网络是 有状态防火墙的，IPv6不允许入站，IPv4也是对称性NAT，对此我的建议应该是，在一台连入了有线网络的设备上，再把一台连入了河南数据流量的手机通过USB与此【连入了有线网络的设备】连到一起，跑代理时 通过 有线网络入站， 出站时 绑定到 USB网卡也就是手机 上。

As for how to obtain a test environment for the Henan data traffic network, well, you can only put a phone with a Chinese SIM card in Henan and connect it to the data traffic network, and then run a proxy on it. The only problem is that the data traffic network has a stateful firewall, which does not allow inbound IPv6 traffic, and IPv4 is also a symmetric NAT. My suggestion is to connect a mobile phone that is connected to the Henan data traffic network to a device connected to the wired network via USB. When running the proxy, inbound traffic will enter via the wired network, and outbound traffic will be bound to the USB network card, which is the mobile phone.

[diwenx]

2. ClientHello fragmentation

Which layer are you fragmenting here? IP fragmentation / TCP segmentation / TLS record layer fragmentation?

2. ClientHello fragmentation

Which layer are you fragmenting here? IP fragmentation / TCP segmentation / TLS record layer fragmentation?

TCP segmentation and TLS record layer fragmentation

2. ClientHello fragmentation

Which layer are you fragmenting here? IP fragmentation / TCP segmentation / TLS record layer fragmentation?

It's TCP segmentation and TLS record layer fragmentation.

IPv6 doesn't allow IP fragmentation so I don't care about the situation of IP fragmentation.

[UjuiUjuMandan]

Can you confirm that obfs4 will be identified quickly from traffic characteristics without the modification? And your result is not related to the unusual iat-mode?

[Lanius-collaris]

@5e2t

Which layer are you fragmenting here? IP fragmentation / TCP segmentation / TLS record layer fragmentation?

It's TCP segmentation and TLS record layer fragmentation.

IPv6 doesn't allow IP fragmentation so I don't care about the situation of IP fragmentation.

Did you take countermeasures against Residual Censorship? If not, you might get incorrect results. And IPv6 does support fragmentation, see https://datatracker.ietf.org/doc/html/rfc8200#section-4.5

The Fragment header is used by an IPv6 source to send a packet larger
than would fit in the path MTU to its destination. (Note: unlike
IPv4, fragmentation in IPv6 is performed only by source nodes, not by
routers along a packet's delivery path -- see Section 5.) The
Fragment header is identified by a Next Header value of 44 in the
immediately preceding header and has the following format

---

只不过麻烦的事情在于，数据流量网络是 有状态防火墙的，IPv6不允许入站，IPv4也是对称性NAT，对此我的建议应该是，在一台连入了有线网络的设备上，再把一台连入了河南数据流量的手机通过USB与此【连入了有线网络的设备】连到一起，跑代理时 通过 有线网络入站， 出站时 绑定到 USB网卡也就是手机 上。

It is unlikely that users of cellular data in China are behind IPv6 NAT, symmetric UDP Firewall can easily be traversed with UDP hole punching. In some regions, users of China Telecom (cellular data) are even behind Endpoint-Independent Mapping NAT.

@5e2t

Which layer are you fragmenting here? IP fragmentation / TCP segmentation / TLS record layer fragmentation?

It's TCP segmentation and TLS record layer fragmentation.
IPv6 doesn't allow IP fragmentation so I don't care about the situation of IP fragmentation.

Did you take countermeasures against Residual Censorship? If not, you might get incorrect results. And IPv6 does support fragmentation, see https://datatracker.ietf.org/doc/html/rfc8200#section-4.5

The Fragment header is used by an IPv6 source to send a packet larger
than would fit in the path MTU to its destination. (Note: unlike
IPv4, fragmentation in IPv6 is performed only by source nodes, not by
routers along a packet's delivery path -- see Section 5.) The
Fragment header is identified by a Next Header value of 44 in the
immediately preceding header and has the following format

只不过麻烦的事情在于，数据流量网络是 有状态防火墙的，IPv6不允许入站，IPv4也是对称性NAT，对此我的建议应该是，在一台连入了有线网络的设备上，再把一台连入了河南数据流量的手机通过USB与此【连入了有线网络的设备】连到一起，跑代理时 通过 有线网络入站， 出站时 绑定到 USB网卡也就是手机 上。

It is unlikely that users of cellular data in China are behind IPv6 NAT, symmetric UDP Firewall can easily be traversed with UDP hole punching. In some regions, users of China Telecom (cellular data) are even behind Endpoint-Independent Mapping NAT.

thank you,very useful message.