TLS record fragmentation, DPYProxy

[wkrp]

Circumventing the GFW with TLS Record Fragmentation
Niklas Niere (@JonSnowWhite)
https://github.com/UPB-SysSec/DPYProxy

This blog post explores an interesting idea: fragmenting TLS messages (especially Client Hello) over multiple TLS records. This is different from TCP segmentation, which has been studied in the past by, e.g., Winter & Lindskog 2012 (Section 5.2, brdgrd), Khattak et al. 2013, and Bock et al. 2021 (Section 4.1), and is implemented in tools including GoodbyeDPI. Rather, this research takes advantage of the fact that TLS messages (e.g. Client Hello) are carried in TLS records, and that one message may be fragmented over multiple records:

The TLS Record Protocol is a layered protocol. At each layer, messages may include fields for length, description, and content. The Record Protocol takes messages to be transmitted, fragments the data into manageable blocks, optionally compresses the data, applies a MAC, encrypts, and transmits the result.

The post introduces a tool, DPYProxy, that fragments TLS messages over multiple records (by parsing the user's TLS records and re-wrapping them in multiple shorter records). They test the tool in China and find that when a Client Hello message is fragmented at the TLS record layer, the SNI is not interpreted by the firewall and the connection doesn't get blocked. (Surprisingly, TCP-layer segmentation also worked in their tests—as long as the Client Hello message is broken before the SNI extension.)

[HectorHW]

Verified to work (for now at least) against Roskomnadzor blocking https websites in Russia. Nice finding!

[JonSnowWhite]

@HectorHW Thanks for the info!

I believe both TCP Segmentation and TLS Hello Fragmentation are implemented in Xray-core.
Although, some CDNs like Fastly are not compatible with these methods, they work fine with majority of websites in Iran using different ISPs.
Also, to my understanding @RPRX and Chinese community insist that these methods do not work in China.

[klzgrad]

It is less likely for realtime systems to handle TCP or TLS reassembly due to its computation or memory cost at scale, in realtime, but this is not a fact that can be relied on in general. During a previous blockage of Cloudflare in #295 I tested various ways of TCP fragmentation of TLS Hello and was able to trigger TCP resets in all variations. I believe in general it is more likely for offline and deeper traffic analysis to perform traffic reassembly as realtime decisions are not required.

[RPRX]

@5e2t 针对河南 GFW 和广州国际出口 GFW 测试过 tlshello 分片：XTLS/Xray-core#2426 (comment)

我的观点是这些分片 可能可用，但 GFW 并不需要重组它们，目前来说，一个报文只含一部分而不是完整的 client hello 即为异常

@5e2t tested tlshello fragmentation against Henan GFW and Guangzhou international outbound GFW: XTLS/Xray-core#2426 (comment)

My view is that these fragments may be usable, but the GFW doesn't need to reconstruct them, and for now, it's an anomaly for a message to contain only a portion of a client hello rather than the full one

[JonSnowWhite]

Should Record Fragmentation not work standalone, it can hopefully be combined with TCP fragmentation. That might be something to try out for circumvention tools like XRay. Especially when the TCP and TLS Records are of different size/in different order.

@5e2t 针对河南 GFW 和广州国际出口 GFW 测试过 tlshello 分片：XTLS/Xray-core#2426 (comment)

我的观点是这些分片 可能可用，但 GFW 并不需要重组它们，目前来说，一个报文只含一部分而不是完整的 client hello 即为异常

@5e2t tested tlshello fragmentation against Henan GFW and Guangzhou international outbound GFW: XTLS/Xray-core#2426 (comment)

My view is that these fragments may be usable, but the GFW doesn't need to reconstruct them, and for now, it's an anomaly for a message to contain only a portion of a client hello rather than the full one

河南GFW能阻断servername位于第一个clienthello分片的TLS握手，对于VLESS-TCP不开TLS的翻墙流量则未触发阻断，说明并不是用hex string的方式识别特定域名的，而是识别出来clienthello握手包了。

Henan GFW can block servername located in the first clienthello fragment of the TLS handshake. As for VLESS-TCP, it does not open TLS flows that trigger blocking, that shows it does not identify a specific domain name hex string, but the clienthello handshake packet.

理论上要是用hex string来识别的话(iptables可以做到)，则VLESS-TCP不开TLS的翻墙流量，以及server name写在第二个clienthello分片的流量都能被识别，但是直接靠16进制数对应的字符来识别域名肯定会造成流量的误伤吧。GFW应该肯定不会维护我跟目标IP的连接状态，也就是说gfw不管我有没有给对方发过syn，也不管我在这条连接上跟对方通信了多久，只看流量是不是clienthello，或者HTTP请求。那也就是说这种情况下用hex string来识别，必然造成流量的误伤(虽然我不知道概率是多少)...........

Theoretically, if you use hex string to identify the traffic (iptables can do it), then the fact that VLESS-TCP does not open TLS circumvention traffic, as well as that the server name written in the second clienthello fragment of the flow can also be recognized, however it directly relies on the hexadecimal number of the corresponding characters to identify the domain name, will certainly cause traffic to be mistakenly injured, right? GFW should definitely not maintain my connection status with the target IP, that is to say, GFW does not care whether I have sent syn to the other party or not, and does not care how long I have been communicating with the other party on this connection, it only looks at the traffic to see whether it is a clienthello, or an HTTP request. That means that using a hex string to classify in this case will inevitably cause the traffic to be misdirected (although I don't know what the probability is)...

@RPRX 之前 河南数据流量网络上的墙 能识别出开了TFO的流量的 clienthello，应该就是因为 数据流量网络上的墙 会看 headerlenth，就是那个一比特代表4字节的字段，4个比特都置1 也就是代表整个报头最大60字节的那个字段

所以说并不是 河南数据流量网络上的墙，特别地对TFO流量做了应对，反倒说明 这个墙是不维护连接状态的。 也就是说，我与某个IP 某个端口建立连接以后，发送 SNI不位于黑名单中的 clienthello握手包，通信一段时间以后，在这条连接上，再发送一个 SNI位于黑名单中的 clienthello握手包，应该是一定会收到阻断的。

所以固定宽带网络上的墙为什么那么傻，连HeaderLenth都不看（兴许是故意不看的.............）

Previously, the wall on Henan's data traffic network was able to recognize the clienthello of the TFO traffic because the wall on the data traffic network would look at the headerlenth, that is, the field where one bit represents 4 bytes, and all 4 bits are set to 1, that is, the field representing the maximum of 60 bytes of the entire header.

So it's not that the wall on Henan's data traffic network specifically responds to TFO traffic, but rather that the wall doesn't maintain connection status. That is to say, after I establish a connection with a certain IP port, I send a clienthello handshake packet with SNI not in the blacklist, and after a period of communication, on this connection, I send another clienthello handshake packet with SNI in the blacklist, and I should be sure to receive a block.

So why are the walls on fixed broadband networks so stupid that they don't even look at HeaderLenth (perhaps on purpose...)

@RPRX 会看HeaderLenth当然也算不上先进~~，之前我对计算机网络知识的了解还不够，所以才觉得河南数据流量网络上的墙 先进，现在看来，这一切似乎都是故意的~~

Looking at HeaderLenth is certainly not considered advanced~~, earlier I did not have enough knowledge of computer networks, and that's why I considered the wall on the network of Henan data traffic to be advanced, now it all seems to be intentional~~

@RPRX 那么问题来了，
TCP Timestamps和TCP Fast Open均绕不过 河南数据流量网络GFW的SNI阻断的原因已经知道了，就是无状态+会看HeaderLenth，
TCP Timestamps和TCP Fast Open均能绕过河南固定宽带网络GFW的SNI阻断的原因也知道了，是无状态+不看HeaderLenth

那么 TCP Timestamps绕不过北上广出口GFW的SNI阻断，TCP Fast Open可以绕过北上广出口GFW的SNI阻断，是说明北上广出口GFW是无状态的还是有状态的，到底是看HeaderLenth还是不看HeaderLenth................

So here's the question.
The reason why TCP Timestamps and TCP Fast Open cannot bypass the Henan data traffic network GFW SNI blocking is known, it is stateless + looks at the HeaderLenth.
The reason why TCP Timestamps and TCP Fast Open can bypass the Henan fixed broadband network GFW SNI blocking is also known, is is stateless + does not look at the HeaderLenth

So, given the facts that TCP Timestamps cannot bypass GFW SNI blocking in the north, and TCP Fast Open can bypass GFW SNI blocking in the north, does it mean that the GFW in the north is stateless or stateful? In the end, does it look at the HeaderLenth or does it not look at HeaderLenth?...

@RPRX 无论是河南固定宽带网络上的GFW还是河南数据流量网络上的GFW，都能识别出servername位于第一个clienthello分片的TLS握手，并且 河南GFW的行为与 tcp的 HeaderLenth高度相关联， 我有很大的信心确认，河南GFW是靠 应用层的前几个或前十几个字节来识别TLS Clienthello的................

Both the GFW on Henan's fixed broadband network and the GFW on Henan's data traffic network are able to recognize TLS handshakes in which servername is located in the first clienthello fragment, and the behavior of Henan's GFW is highly correlated with the tcp HeaderLenth, and I have a great deal of confidence in confirming that Henan's GFW is relying on the application layer's first few or first dozen or so bytes at the application layer to recognize the TLS Clienthello...

@RPRX 北上广出口GFW识别不出 servername 写在了第一个clienthello分片的TLS握手，更像是”有状态“ 行为......
TCP Timestamps绕不过北上广出口GFW的SNI阻断， 只能说明 北上广出口GFW会看TCP HeaderLenth。
前面已经知道了，无状态+看HeaderLenth可识别TFO的clienthello，
TCP FastOpen可以绕过北上广出口GFW的SNI阻断，大概也许说明了 TCP FastOpen的clienthello流量无法被GFW识别为syn，或者说，被识别为Syn了，然后就忽略了这个包的应用层数据了..........

就是说只能说明北上广GFW是有状态+看HeaderLenth的。。。。

Northbound exiting GFW can't recognize TLS handshakes where the servername is written in the first clienthello fragment, more like "stateful" behavior ......
TCP Timestamps can't bypass the SNI blocking of the GFW, which only means that the GFW can look at the TCP HeaderLenth.
As you already know, statelessness + looking at HeaderLenth can recognize the clienthello of TFO,
TCP FastOpen can bypass the SNI blocking of the northbound exiting GFW, probably perhaps indicating that the clienthello traffic of TCP FastOpen cannot be recognized by the GFW as syn, or rather, is recognized as Syn, but then the packet's application layer data is ignored...

That is, it can only mean that the Northbound GFW is stateful + looks at HeaderLenth...

@RPRX 北上广出口GFW 可能会维护连接状态，就是说，以每条TCP连接 为单位，只看 每条连接的前几个包，或者干脆是只看客户端发的第一个包............，如果客户端发的第一个包 不触发阻断，那么 此条连接后续所有通信 内容 将不再 被 检测..............

（以上为纯粹的猜测~~~~~~~~~）

Northbound exiting GFW may maintain the connection status, that is to say, in terms of each TCP connection, it only looks at the first few packets of each connection, or simply only looks at the first packet sent by the client... If the first packet sent by the client does not trigger a block, then all subsequent traffic on the connection will no longer be detected...

(The above is pure speculation~~~~~~~~~)

@RPRX 我个人认为 TCP Fast Open之所以能绕过 北上广出口GFW的SNI阻断，是因为北上广出口GFW 期望看到syn用以维护连接状态，然后syn包的应用层数据就理所当然的忽略掉了（因为在等着看后面一个包是不是Clienthello..........）。

而河南GFW 由于不维护连接状态，则期望看到的是TLS Clienthello握手包，所以 这就是同样的一个开了TCP Fast Open的TLS clienthello握手包，在 河南GFW和国际出口GFW那里有不同的表现的原因吧~~~

Personally, I think the reason why TCP Fast Open bypasses the SNI blocking of the northbound exit GFW is because the northbound exit GFW expects to see a syn to maintain the connection status, and then the syn packet's application-layer data is rightly ignored (because it's waiting to see if the later packet is Clienthello...).

The Henan GFW expects to see TLS Clienthello handshake packets because it doesn't maintain the connection state, so that's why the same TLS Clienthello handshake packet with TCP Fast Open is treated differently by the Henan GFW and the international exit GFWs, right?~~~