###### Abstract
The labeling on the gateway is mainly carried out by using the plaintext information remaining in the flow, among which the Server Name Indicator (SNI) based on the TLS header is the most representative one. However, SNI exists only in TLS. As a result, UDP and some non-TLS TCP traffic cannot be labeled. In addition, as an extended field, SNI does not necessarily exist and can be tampered with, resulting in labeling errors. Furthermore, the experiment found that as SNI is a domain name segment, multiple applications of one company may use the same SNI, and applications of different companies may call each other's services, resulting in further confusion about SNI. Eventually, with Encrypted SNI (ESNI) and TLS-1.3, SNI will become obsolete. Manual collection and labeling methods based on the traffic sniffing tool (such as Wireshark [5]) are much less efficient than gateway traffic filtering but they has better precision. However, there are still many problems with manual methods. Firstly, there is a manual error in this process, which lies in the integrity of samples and the correctness of labels. Secondly, to ensure the correctness of labels, it is necessary to ensure that there is only one target application that needs to be collected and labeled in the current operating system (OS) environment. This process is difficult to achieve, and there is interference from the background traffic of the OS. Third, in some OSs, such as Android, traffic collection and labeling require root authority, resulting in privacy and security risks. To break this situation, some attempts have been made to automate the collection of labels, such as OpenQPA [6] and PacketCapture [7]. OpenQPA has the problem of packet loss, and the system is not open source, resulting in incomplete, unusable, and unreliable samples. However, PacketCapture requires the installation of user certificates, resulting in privacy and security risks. In addition, the obtained samples are HTTP information assembled after decryption, which cannot be used to encrypt traffic classification. Overall, there are seven difficulties to overcome: (1) execute on the end system, supporting a variety of OSs, with satisfactory efficiency; (2) need to obtain the correct application labels and automatically label the samples; (3) need to include user behavior, that is, can operate the application manually, but can not introduce manual error; (4) the sample needs to be complete, with context, without packet loss; (5) users' privacy shall be protected, device security shall not be damaged, and keys shall not be obtained for decryption; (6) purity of samples shall be ensured, and background traffic of the OS shall not be mixed; and (7) collection and labeling procedure shall not affect the features of traffic, and the regular use of users shall not be affected. Hence, we propose a one-stop architecture named automated encrypted traffic labeled sample collection, construction, and correlation (A3C). Firstly, we analyze the principle and form of encrypted traffic and decide the end's automated encrypted traffic sample collection. This architecture includes the online acquisition procedure and the offline validation procedure. The main reason for the asynchronous design is that the validation process is complex and optional, requiring a considerable computation cost compared to the online acquisition procedure. Then, we adopt semi-auto and fully-auto modes to collect traffic. The differences lie in the relevance between traffic and user behavior. On this basis, we realized cross-platform process-level traffic collection and sample construction for three different OSs, respectively, by utilizing the different interfaces. Afterward, the labeled samples of multiple processes of complex multi-process applications are correlated, and process-level samples are combined into application-level samples. In the offline validation procedure, we can conduct encryption detection on traffic samples to purify labeled datasets.