CN111917694B - A method and device for identifying TLS encrypted traffic - Google Patents

Abstract

The present invention provides a method for identifying TLS encrypted traffic, including DPI Server receiving App registration request information from a registration website, assigning App feature identification information to a target App, and sending it back to the registration website. The DPI Server exchanges the App feature verification information of the App with the App Server based on the TLS connection of two-way verification. After the exchange, both parties have the same App feature identification information and App feature verification information. The DPI Server sends the App feature identification information and App feature verification information of the App to the DPI network element based on the two-way authenticated TLS connection. The DPI network element verifies the legitimacy of the App feature identification information in the user TLS traffic according to the App feature verification information, and identifies the TLS traffic generated by the App according to the App feature identification information. The invention can realize the precise and detailed DPI identification for anti-fraud of the TLS encrypted flow of the application service of the cooperative SP of the telecommunication operator, thereby reducing or preventing the occurrence of traffic fraud.

Description

A method and device for identifying TLS encrypted traffic

technical field

The invention relates to the field of mobile communication, in particular to a TLS encrypted traffic identification method and device.

Background technique

With the continuous development of mobile broadband and smart terminals, and the strengthening of user information security and privacy protection, more and more network connections of iOS and Android applications are based on TLS (Transport Layer Security, Transport Layer Security) bearer, resulting in TLS encryption The proportion of traffic is increasing. There are also more and more scenarios where telecom operators need to accurately identify user TLS encrypted traffic. In the mobile network of telecom operators, whether in P-GW (Packet DataNetwork Gateway) network elements, MEC (Mobile Edge Computing, Mobile Edge Computing) servers, or other related switches, routers, firewalls, traffic analyzers, etc., It may be necessary to accurately identify TLS encrypted traffic based on DPI (Deep Packet Inspection) technology.

Taking 5G MEC as an example, edge computing provides 5G terminals with a reliable mobile wireless network with high bandwidth and low latency. A possible typical operation mode is that when the network load is close to saturation, MEC equipment will provide services for different applications. Different QoS guarantees, especially high-priority QoS guarantees for application services paid by SPs (Service Providers, service providers) with cooperative relations. Therefore, it is particularly important to accurately identify the TLS-encrypted application traffic of the cooperative SP through the DPI technology.

However, the conventional DPI technology is usually based on the SNI (Server Name Indication, server name indication) in the TLS Client Hello message or the server certificate CN (Common Name) and SAN (Subject Alternative Name, subject alternative name) or DNS (Domain Name Name) in the TLS Certificate message. System, Domain Name System) request/response message DNS domain name of the server to identify the TLS encrypted traffic of the application business of the cooperative SP. There are usually defects in this type of identification method, for example: some VPN (Virtual Private Network, virtual private network) software utilizes such features as SNI, CN, SAN, DNS to disguise its VPN traffic as the application business of the cooperative SP of the telecom operator Traffic, so as to achieve the purpose of obtaining high-priority QoS or evading billing.

At present, a common solution is that the telecom operator obtains the public network IP address of the server of the cooperative SP in advance, and performs DPI identification on the TLS encrypted traffic of these specified IP addresses. However, this method is too extensive to accurately identify the refined business of cooperative SPs.

At present, another common solution is that telecom operators perform DPI identification on TLS encrypted traffic through the combined information of the server public network IP address of the cooperative SP and one or more SNI/CN/SAN/DNS. This method can refine the application business of the cooperative SP to a certain extent, but the degree of refinement is usually not ideal. Moreover, IETF (InternetEngineering Task Force, Internet Engineering Task Force) has encrypted the Certificate message in the TLS 1.3 (RFC 8446) protocol, resulting in the failure of the CN/SAN feature; and in the DoT (RFC 7858) and DoH (RFC8484) protocols DNS messages have been encrypted, resulting in invalidation of DNS features; and a draft of encrypted SNI is proposed for publication and discussion, which will cause future SNI features to be invalidated as well.

At present, there is a need for a precise and fine-grained feasible DPI identification method for anti-fraud of the TLS encrypted traffic of the application service of the cooperation SP of the telecom operator. By using the method of the present invention, it is possible to realize precise and fine-grained DPI identification for anti-fraud of the TLS encrypted flow of the application service of the cooperation SP of the telecommunication operator, and reduce or prevent the occurrence of flow fraud.

Contents of the invention

The following is an overview of the topics described in detail in this article. This summary is not intended to limit the scope of the claims.

In order to enable telecom operators to finely identify the TLS-encrypted application traffic of their cooperative SPs, and reduce or prevent the occurrence of traffic fraud, the present invention proposes a method for identifying traffic based on TLS encryption, including:

DPI Server receives the App registration request information from the registration website, assigns App feature identification information to the target App, and sends it back to the registration website;

DPI Server exchanges the App feature verification information of the App with the App Server based on the TLS connection of two-way verification. After the exchange, both parties have the same App feature identification information and App feature verification information;

DPI Server sends the App feature identification information and App feature verification information of the App to the DPI network element based on the two-way verified TLS connection;

The DPI network element verifies the legitimacy of the App feature identification information in the user TLS traffic according to the App feature verification information, and identifies the TLS traffic generated by the App according to the App feature identification information.

Further, the App feature verification information includes App public key information for DPI identification, MAC key and MAC algorithm information, and legal range information of multi-interval counters.

Further, in the TLS connection established between the DPI Server and the App Server, the certificate of the App Server and the certificate of the DPI Server are both issued by a legal third-party certificate authority.

Further, the DPI network element matches the App feature identification information in the Server Hello message in the user App traffic information, and identifies the corresponding App traffic information.

Further, the DPI network element verifies the validity of the corresponding App feature identification information according to the App feature verification information in the Server Hello message in the user App traffic information.

The present invention also provides a TLS encrypted traffic feature information management device, including:

The App registration management module placed in the DPI Server is used to receive the App registration request information from the registration website, and assign App feature identification information to the target App, and send it back to the registration website;

The App Server update management module placed in the DPI Server, which is based on a two-way authenticated TLS connection, exchanges the App feature verification information of the App with the App Server, and after the exchange, both parties have the same App feature identification information and App feature verification information;

The DPI feature update management module placed in the DPI Server sends the App feature identification information and App feature verification information of the App to the DPI network element based on the two-way verified TLS connection.

Further, the App feature verification information includes App public key information for DPI identification, MAC key and MAC algorithm information, and legal range information of multi-interval counters.

Further, in the TLS connection established between the App Server update management module and the App Server, the certificate of the App Server and the certificate of the DPI Server are both issued by a legal third-party certificate authority.

The present invention also provides a server, including: a memory, a processor, and a computer program stored on the memory and operable on the processor. When the processor executes the program, it implements the TLS as described in any one of the above claims. Methods for encrypted traffic identification.

Description of drawings

Fig. 1 is the flowchart of the TLS encrypted traffic identification method provided by the present invention;

Fig. 2 is a structural diagram of a TLS encrypted traffic characteristic information management device provided by the present invention;

Fig. 3 is a structural diagram of a server provided by the present invention;

Fig. 4 is a sequence interaction diagram of the TLS encrypted traffic identification method provided by the present invention.

Detailed ways

Embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings.

The steps shown in the flowcharts of the figures may be performed in a computer system, such as a set of computer-executable instructions. Also, although a logical order is shown in the flowcharts, in some cases the steps shown or described may be performed in an order different from that shown or described herein.

The DPI network element described in the present invention can refer to DPI independent network element equipment on the one hand, and can also refer to network element equipment with built-in DPI functions such as PGW gateway, MEC server, switch, router, and firewall on the other hand.

The present invention introduces DPI Server to distribute App Token and other information to App. App business traffic carries App Token and other information through the custom TLS extension of the ServerHello message, so that the DPI network element can accurately identify the TLS-encrypted App business traffic of the cooperative SP, so that the DPI network element can prevent the traffic through a series of means proposed by the present invention Fraud situation: Verify the integrity of relevant data through MAC (Message Authentication Code, message authentication code), prevent replay attacks through multi-interval counter checks, verify App identity through public key cryptographic signatures, and strengthen through App Server public network IP address checks Accuracy of feature recognition.

As shown in FIG. 1 , an embodiment of the present invention provides a method for identifying TLS encrypted traffic.

S101, App registration stage. As shown in the first step in Figure 1, the DPI Server receives and processes the App registration request message sent by the App developer through the registration website. The DPI Server returns the corresponding App registration response message to the registration website to provide App registration information for App developers.

Typically, the App registration request message includes information such as App name, SP name, App Server name, and App Server certificate CN/SAN used in the AppServer update phase. Typically, the App registration response message includes: dedicated TLS extension type ID, App Token, date and time when the App Token is successfully allocated, and other information.

For example, DPI Server uses "SP name + App name" as the unique identifier, and assigns a globally unique App Token to the App of the SP. App Token can be a 128-bit (ie 16-byte) large integer.

For the allocation of a dedicated TLS extension type ID, the DPI Server first ensures that the selected extension type ID cannot be a well-known extension type ID assigned by the IANA (Internet Assigned Numbers Authority, Internet Numbering Authority). IANA (www.iana.org) official document "Transport Layer Security (TLS) Extensions" records the latest well-known extension type ID, such as 0 for server_name, 1 for max_fragment_length, 16 for application_layer_protocol_negotiation (ALPN), 35 for session_ticket, and 41 for pre_shared_key(PSK), 43 is supported_versions, and dozens of others. These well-known extension type IDs cannot be selected. The DPI Server can select the extension type ID from more than 65,000 "Unassigned" numbers at present, or select the extension type ID from more than 200 "Reserved for Private Use" numbers at present.

Optionally, the DPI Server may support that the App registration request message includes one or more value ranges of TLS extension type IDs that need to be excluded. App may add other custom extension type IDs irrelevant to the present invention in TLS, so the dedicated TLS extension type ID allocated by DPI Server cannot conflict with other custom extension type IDs of App. Typically, the DPI Server allocates a dedicated TLS extension type ID for DPI identification to the App after excluding the well-known IANA TLS extension type ID and other extension type IDs specified by the App.

Optionally, in order to increase the difficulty and cost of traffic fraud, after excluding the well-known IANA TLS extension type ID and other extension type IDs specified by App, DPI Server can assign the same or different dedicated TLS extension type IDs; alternatively, the same or different dedicated TLS extension type IDs may be assigned to different Apps (namely "SP name+App name").

Typically, the App developer deploys information such as the dedicated TLS extension type ID obtained through the registration website, the App Token, and the date and time when the App Token was successfully allocated to the App Server. The app developer deploys information such as the dedicated TLS extension type ID obtained through the registration website to the App Client.

Deploy a dedicated TLS extension type ID in the App Client, so that when the App Client generates a ClientHello message for TLS traffic, it carries a dedicated TLS extension type ID.

Deploy a dedicated TLS extension type ID in the App Server, so that the App Server will carry the extension type ID and the corresponding extension content when replying the Server Hello response to the Client Hello containing the extension type ID.

For the TLS 1.0 protocol, TLS 1.1 protocol, and TLS 1.2 protocol, Client Hello is not encrypted, and Server Hello is not encrypted. The dedicated TLS extension introduced at this stage can be added to Client Hello and Server Hello normally.

For the TLS 1.3 protocol, Client Hello is not encrypted, and Server Hello is not encrypted. The dedicated TLS extension introduced at this stage can be added to Client Hello and Server Hello normally. However, because the TLS 1.3 protocol introduces the Encrypted Extensions message to encrypt extensions that do not require plaintext transmission, it is necessary to ensure that the dedicated TLS extensions introduced at this stage should be added to Server Hello instead of EncryptedExtensions when the present invention is implemented. Typically, taking the OpenSSL-1.1.1 library as an example, when setting a custom extension through the OpenSSL API function SSL_CTX_add_custom_ext(), set the relevant parameters of the function to include "SSL_EXT_TLS1_3_SERVER_HELLO" instead of "SSL_EXT_TLS1_3_ENCRYPTED_EXTENSIONS", so that this The dedicated TLS extension introduced in the stage can be added to Server Hello normally.

S102, App Server update stage. In the second step shown in Figure 1, the DPI Server receives the TLS connection establishment request initiated by the App Server, and establishes a TLS connection using a two-way certificate verification mechanism. The DPI Server receives the App Server update request message, and processes the periodically updated DPI identification and verification information of the App Server. At the same time, the DPI Server also sends the new DPI identification and verification information to the App Server through the App Server update response message.

Typically, the App Server update request message includes: App Token, the date and time when the App Token is successfully allocated, the public IP address of the App Server (optional), and the public key information of the App Server for DPI identification. The App Server update response message includes information such as the legal range of multi-interval counters, MAC keys, and MAC algorithms.

Typically, the TLS connection between the App Server and the DPI Server uses a two-way certificate verification mechanism, which increases the difficulty and cost of traffic fraud. As a TLS client, App Server sends its own certificate to DPI Server through an uplink Certificate message, and DPI Server, as a TLS server, sends its own certificate to App Server through a downlink Certificate message. The respective certificates of the App Server and the DPI Server must be issued by a third-party legitimate CA (Certificate Authority, Certificate Authority) to ensure that both parties can verify the legal identity of the other party through the other party's certificate. Among them, the DPI Server verifies the CN and SAN sent by the App Server through the uplink Certificate through the "App Server Certificate CN/SAN for the App Server Update Phase" obtained in the first App registration stage to verify the legitimacy of the App Server identity.

Typically, the App Server periodically sends an App Server update request message to the DPI Server through a TLS connection with the DPI Server, and sends the App Server public network IP address (optional) and the App Server public key information used for DPI identification to the DPI Server; at the same time, the App Token is carried in the message, and the date and time when the App Token is successfully allocated, so that the DPI Server can associate with the relevant information of the App formed in the first step of the App registration stage.

For example, App Server public key information used for DPI identification is included in the App Server update request message. Typically, the App Server can periodically regenerate the public key and its paired private key, and send the newly generated public key to the DPI Server through this message. The public key is used in the fourth step of the DPI feature identification stage, and the DPI network element verifies the App Server's signature on the relevant part of the App Token extension content.

Optionally, in the App Server update request message, if the App Server can obtain the public IP address of the App Server that provides services to the App Client, it should report these IP addresses to the DPI Server, so that the fourth step DPI feature In the recognition phase, DPI network elements enhance the accuracy of feature recognition. Typically, these IP addresses can be described by multiple groups/pairs in the manner of "include" and "exclude from inclusion". For example, taking IPv4 as an example, it can be described as, including from X1.X2.X3.X4 to IP addresses in the range Y1.Y2.Y3.Y4, and exclude IP addresses in that range from M1.M2.M3.M4 to N1.N2.N3.N4, and including or excluding what is described can is one or more address ranges.

Typically, the App Server update response message includes the legal range of the multi-interval counter allocated by the DPI Server. Typically, the value range of the multi-interval counter can be a positive integer from 1 to a maximum value of 64 bits (8 bytes) (marked as MAX64). The legal range of a multi-interval counter can be one or more range segments from 1 to MAX64.

For example, the App Server update response message includes MAC key and MAC algorithm information. Typically, the MAC algorithm can use the HMAC algorithm (RFC 2104), and the algorithm description format in this message can be "HMAC-MD5", "HMAC-SHA1", "HMAC-SHA224", "HMAC-SHA256", "HMAC -SHA384", "HMAC-SHA512", etc.

S103, a DPI feature update stage. In the third step shown in Figure 1, the DPI Server receives the TLS connection establishment request initiated by the DPI network element, and establishes the TLS connection by using a two-way certificate verification mechanism. The DPI Server receives and processes the DPI feature update request initiated by the DPI network element, and provides the DPI network element with the latest DPI feature information of the App through the corresponding DPI feature update response.

Typically, the DPI feature update response message includes: App name, SP name, App Server name, dedicated TLS extension type ID, App Token, date and time when App Token is successfully allocated, App Server public network IP address (optional), App server public key identified by DPI, legal range of multi-interval counters, MAC key, MAC algorithm and other information.

Typically, the TLS connection between the DPI network element and the DPI Server uses a two-way certificate verification mechanism, which increases the difficulty and cost of traffic fraud. As a TLS client, the DPI network element sends its own certificate to the DPI Server through the uplink Certificate message, and the DPI Server, as the TLS server, sends its own certificate to the DPI network element through the downlink Certificate message. The certificate of the DPI Server must be issued by a third-party legal CA to ensure that the DPI network element can verify the legal identity of the DPI Server through the certificate. The certificate of the DPI network element can be issued by the DPI Server as a private CA for the DPI network element, and it is preset in the DPI network element as the legal identity certificate of the DPI network element.

Typically, the DPI network element periodically sends a DPI feature update request message to the DPI Server through a TLS connection with the DPI Server, so as to obtain the latest identification feature information of each App in the DPI Server.

Typically, the DPI Server sends the identification feature information of each App whose relevant information has been updated after the last DPI network element request to the DPI network element through a DPI feature update response message. Optionally, the DPI Server puts each App Token or "SP name+App name" whose relevant information has not been updated after the last DPI network element request in a message and sends it to the DPI network element.

Optionally, in the DPI feature update request message sent by the DPI network element, one or more AppTokens or "SP name+App name" may be specified or excluded. Correspondingly, the DPI feature update response message sent by the DPI Server only carries the latest identification feature information of the corresponding App.

S104, the DPI feature recognition stage. In the fourth step shown in Figure 1, the DPI network element detects the specified extension type and content in the ClientHello and Server Hello messages in the App Internet traffic, matches the App Token and verifies the App Server signature and MAC, and confirms the authenticity of the App traffic. In this way, App business traffic can be accurately identified.

Typically, the Client Hello message sent by the App Client in the App business traffic contains: the previously assigned dedicated TLS extension type ID and the content is empty. The Server Hello message sent by the App Server in the App business traffic contains: the previously allocated dedicated TLS extension type ID, the extension content includes the App Token, the date and time when the AppToken is successfully allocated, and a multi-interval counter within the legal range of the multi-interval counter value, the signature of the extended content of the former part, the signature algorithm, the MAC value of the extended content of the former part, the MAC algorithm and other information.

Typically, the Client Hello message sent by the App Client contains a custom TLS extension whose extension type ID is the dedicated TLS extension type ID allocated in the first step of the App registration phase, and whose extension content is empty.

Typically, the Server Hello message sent by the App Server contains a custom TLS extension whose extension type ID is the dedicated TLS extension type ID allocated in the first step of the App registration phase, and the extension content is as follows:

Specifically, extension content 1: App Token. The App Token comes from the first step of App registration.

Specifically, extended content 2: the date and time when the App Token is successfully allocated. The date and time information comes from the first step of app registration.

Specifically, extension content 3: a multi-interval counter value within the legal range of the multi-interval counter. The legal range of the multi-interval counter comes from the second step of the App Server update phase. Typically, for the same App Client user (distinguished by IP address), the App Server takes values from small to large within the legal range of the multi-interval counter. For each Server Hello message connected by TLS, the value of the multi-interval counter is increased by 1 , after reaching the maximum value of the multi-interval counter value range, wrap around to the minimum value and start again.

Specifically, extended content 4: a signature for the entirety of extended content 1 to extended content 3 . The App Server uses the signature algorithm of the extension content 5 to sign the extension content 1 to extension content 3 as a whole. Typically, the content is first hashed to obtain a fixed-length hash result, and then the hash result is hashed using the private key corresponding to the App Server public key for DPI identification generated in the second App Server update stage. Encryption, the result of encryption is the signature.

Specifically, extended content 5: signature algorithm. The signature algorithm is determined by App Server, including hash algorithm and public key encryption algorithm, typically, such as "MD5-RSA", "SHA1-RSA", "SHA224-RSA", "SHA256-RSA", "SHA384-RSA ", "SHA512-RSA", etc.

Specifically, the extended content 6: the MAC value for the whole of the extended content 1 to the extended content 5 . The App Server adopts the MAC algorithm of the extension content 7, and uses the MAC key obtained from the DPI Server in the second step of the App Server update phase to generate MAC values for the extension content 1 to the extension content 5 as a whole.

Specifically, extended content 7: MAC algorithm. The MAC algorithm is determined by the App Server, and one of the multiple MAC algorithms allocated by the DPI Server in the second step of the App Server update phase is selected for use.

Typically, the DPI network element detects whether the Client Hello message in the TLS traffic contains the relevant dedicated TLS extension type ID, and if it does, it needs to continue to further detect the Server Hello message of the TLS-TCP (Transmission Control Protocol, transmission control protocol) flow ; If not included, further detection of the Server Hello message of the TLS-TCP stream is not required.

Typically, the DPI network element detects whether the Server Hello message in the TLS traffic contains the relevant dedicated TLS extension type ID, and if it does, it continues to further detect and verify the extension content; if it does not contain it, it does not need to continue the extension content. Detect and verify. Typically, the DPI network element detects and verifies the extended content as follows:

Typically, the DPI network element extracts the extended content 1 as App Token. If the subsequent verification passes, the AppToken will be identified as the corresponding App, that is, the current TLS traffic will be accurately identified as the corresponding App business.

Optionally, the DPI network element extracts the extended content 2 as the date and time of the successful allocation of the App Token. On the one hand, it can be used to verify the uniqueness of the App Token, and on the other hand, it can be used to describe the version information of the App Token.

Typically, the DPI network element extracts the extended content 3 as a multi-interval counter value. The DPI network element detects whether the value of the multi-interval counter is within the legal range of the multi-interval counter. If it is within the legal range, check the Server Hello message multi-interval counter for different TLS flows of the same App Client user (distinguished by user-side IP address) under the same AppServer (distinguished by network-side IP address + network-side PORT) Whether the value increments or wraps around at the maximum value. If it is incremented or wraps around at the maximum value, the multi-interval counter value is considered to pass the check, otherwise it is considered not to pass the check. If it is not within the legal range, it is also considered to have failed the inspection. Check the legal value of multi-interval counters to prevent traffic fraud based on replay attacks.

Typically, the DPI network element extracts the extended content 4 as the signature of the App Server for the entire extended content 1 to the extended content 3; the DPI network element uses the signature algorithm extracted from the extended content 5 for the entire extended content 1 to the extended content 3, And the App Server public key used for DPI identification obtained from the third step DPI feature update phase, to verify the signature. Specifically, the signature algorithm extracted from the extension content 5 includes a hash algorithm and a public key encryption algorithm, and the hash algorithm is used to hash the entire extension content 1 to extension content 3 to obtain a hash result; the public key encryption algorithm is used to , using the App Server public key used for DPI identification obtained from the third step DPI feature update stage, to decrypt the extension content 4 to obtain the decryption result; if the hash result is consistent with the decryption result, it is considered that the signature verification is passed; Otherwise, it is considered that the signature verification has not been passed. The extended signature verification is used to authenticate the identity of the App Server to reduce or prevent traffic fraud.

Typically, the DPI network element extracts the extended content 5 as a signature algorithm for verifying the extended content 4 .

Typically, the DPI network element extracts the extended content 6 as the MAC value of the App Server for the entire extended content 1 to the extended content 5; the DPI network element uses the MAC algorithm extracted from the extended content 7 for the entire extended content 1 to the extended content 5 , and the MAC key obtained from the third step DPI feature update phase to calculate and generate a MAC value; if the generated MAC value is consistent with the extracted MAC value, it is considered that the MAC verification has passed, otherwise it is considered that the MAC verification has not passed. The extended MAC check is used to ensure the integrity of the extended content and reduce the possibility of traffic fraud.

Typically, the DPI network element extracts the extended content 7 as a MAC algorithm for verifying the extended content 6 .

Typically, the DPI network element can identify the App Token as the corresponding App for the App Token that has passed the multi-interval counter check, signature verification, and MAC verification, that is, the current TLS traffic can be accurately identified as the corresponding App service.

Optionally, in the above-mentioned case of accurately identifying App services, if the DPI network element obtains the App Server public network IP address from the third step DPI feature update stage, it can check the network side IP address of the current TLS-TCP flow Whether it is within the range of the public network IP address of the App Server, and if so, the accuracy of the identification result can be further enhanced.

As shown in Figure 2, the embodiment of the present invention also provides a TLS encrypted traffic feature information management device, including:

The App registration management module 201 set in the DPI Server 200. The App registration management module receives the App registration request information from the registration website, assigns App feature identification information to the target App, and sends it back to the registration website.

The App Server update management module 202 installed in the DPI Server 200 . The App Server update management module exchanges the App feature verification information of the App with the App Server based on the two-way verified TLS connection. After the exchange, both parties have the same App feature identification information and App feature verification information.

The DPI feature update management module 203 set in the DPI Server 200 . The DPI feature update management module sends the App feature identification information and App feature verification information of the App to the DPI network element based on the two-way verified TLS connection.

As shown in Figure 3, the embodiment of the present invention also provides a server 300, including: a memory 301, a processor 302, a bus interface 303, a user interface 304, and an output interface 305, and the processor 302 executes the TLS encrypted traffic identification method.

The present invention is not limited to the above embodiments, and all equivalent changes made according to the scope of the claims of the present invention fall within the scope of the claims of the present invention.

Those of ordinary skill in the art can understand that all or some of the steps in the methods disclosed above, the functional modules/units in the system, and the device can be implemented as software, firmware, hardware, and an appropriate combination thereof. In a hardware implementation, the division between functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be composed of several physical components. Components cooperate to execute. Some or all of the components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on computer readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media). As known to those of ordinary skill in the art, the term computer storage media includes both volatile and nonvolatile media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. permanent, removable and non-removable media. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cartridges, tape, magnetic disk storage or other magnetic storage devices, or can Any other medium used to store desired information and which can be accessed by a computer. In addition, as is well known to those of ordinary skill in the art, communication media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media .

Claims (8)

1. A method for identifying TLS encrypted traffic, comprising: DPI Server receives the App registration request information from the registration website, assigns App feature identification information to the target App, and sends it back to the registration website; DPI Server exchanges the App feature verification information of the target App with the App Server based on the TLS connection of two-way verification. After the exchange, both parties have the same App feature identification information and App feature verification information; DPI Server sends the App feature identification information and App feature verification information of the target App to the DPI network element based on the two-way verified TLS connection; The DPI network element verifies the legitimacy of the App feature identification information in the user TLS traffic according to the App feature verification information, and identifies the TLS traffic generated by the target App according to the App feature identification information, and the DPI network element passes through multiple intervals Counter checks to prevent replay attacks; Wherein, the DPI network element matches the App feature identification information in the Server Hello message in the user App traffic information, and identifies the corresponding App traffic information. 2. The method according to claim 1, wherein the App feature verification information includes App public key information, MAC key and MAC algorithm information, and multi-interval counter legal range information for DPI identification. 3. The method according to claim 1, wherein, in the TLS connection established between the DPI Server and the App Server, the certificate of the App Server and the certificate of the DPI Server are all issued by a legal third-party certification authority . 4. The method according to claim 1, wherein the DPI network element verifies the validity of the corresponding App feature identification information according to the App feature verification information in the Server Hello message in the user App traffic information. 5. A TLS encrypted traffic characteristic information management device, comprising: The App registration management module placed in the DPI Server is used to receive the App registration request information from the registration website, assign App feature identification information to the target App, and send it back to the registration website; The App Server update management module placed in the DPI Server, which is based on a bidirectionally authenticated TLS connection, exchanges the App feature verification information of the target App with the AppServer, and after the exchange, both parties have the same App feature identification information and App feature verification information; The DPI feature update management module placed in the DPI Server, which is based on a two-way verified TLS connection, sends the App feature identification information and App feature verification information of the target App to the DPI network element, and the DPI network element checks through the multi-interval counter prevent replay attacks; Wherein, the DPI network element matches the App feature identification information in the Server Hello message in the user App traffic information, and identifies the corresponding App traffic information. 6. The device according to claim 5, wherein the App feature verification information includes App public key information for DPI identification, MAC key and MAC algorithm information, and legal range information of multi-interval counters. 7. The device according to claim 5, wherein, in the TLS connection established between the App Server update management module and the App Server, the certificate of the App Server and the certificate of the DPI Server are all legal third-party certificates issued by the issuing authority. 8. A server, comprising: a memory, a processor, and a computer program stored on the memory and operable on the processor, characterized in that, when the processor executes the program, any A method for identifying TLS encrypted traffic.

Images