## 4 Architecture of Tor-Snowflake Traffic Identification Framework
### Snowflake Traffic Identification Framework  
This section proposes a traffic identification framework for Tor's latest PT Snowflake. The framework of the Snowflake traffic identification and Tor hidden service access activity identification under the Tor-Snowflake scenario is shown in Figure 3.  
First, we control clients through automated scripts and capture traffic generated from clients into pcap files. We also collect traffic on the controlled gateway. Then, the pre-identification of Snowflake access behavior is performed by a rule-based matching approach. We analyze the pecp files according to the special behavior pattern of DNS query before Snowflake communication. On this basis, we filtered suspicious UDP flow  
Figure 3: Tor-Snowflake traffic identification framework F-ACCUMUL.  
and extracted handshake fingerprint features of the DTLS protocol. These features were combined and fed into an ML model and trained a classifier, which gives Snowflake's identification result. Furthermore, we extracted relevant statistical features and used our proposed ACCUMUL method to process Snowflake's DTLS flows. In the end, we used the extracted features to train a Snowflake traffic classification model based on machine learning algorithms to identify HS access activities in the Tor-Snowflake scenario.  
In the following parts, we analyze the pre-identification method based on the Snowflake communication process from the perspective of Snowflake communication messages. Snowflake utilizes WebRTC technology to establish peer-to-peer connections that require NAT traversal through STUN (Session Traversal Utilities for NAT) [32], which is mostly used in real-time-communication scenarios. Snowflake provides a list of available STUN server domain information, which is usually hard-coded in Tor's configuration file torrc. When the Snowflake client first starts up, it randomly selects a subset of these STUN server lists to initiate DNS requests. It looks for the hostname resolution using both IPv4 and IPv6(DNS 'A' and 'AAAA' records). The set of DNS request messages sent is shown in the Figure 4.  
After completing the DNS query to the STUN server, a DNS request to the domain-fronting server corresponding to the torrc hard-coded by snowflake PT will be sent. After obtaining the response, a TLS connection for the rendezvous phase will be established with the domain-fronting server immediately.  
Based on the above analysis, the Tor-Snowflake traffic pre-identification proposed in this paper consists of two main rules. The first rule is to extract the DNS queries initiated by a single user in the packet to STUN servers in a short period of time. If these DNS queries point to multiple STUN servers and these STUN servers are in torrc's Snowflake hard-coded list, the user is probably using Snowflake to try to access Tor, then turn to the second rule of pre-identification. The second rule is based on the first rule, in which after the client gets a DNS response to the above STUN server, the client continues to launch DNS queries to the hard-coded domain-fronting server address in torrc. By the above two rules, the suspicious Snowflake traffic can be filtered out.