CN111917694A

CN111917694A - TLS encrypted traffic identification method and device

Info

Publication number: CN111917694A
Application number: CN201910396042.4A
Authority: CN
Inventors: 宋科; 李华光; 刘西亮
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2019-05-09
Filing date: 2019-05-09
Publication date: 2020-11-10
Anticipated expiration: 2039-05-09
Also published as: CN111917694B; WO2020224341A1

Abstract

The invention provides a TLS encrypted traffic identification method, which comprises the steps that a DPI Server receives App registration request information from a registration website, distributes App characteristic identification information for a target App, and sends the App characteristic identification information back to the registration website. The DPI Server exchanges App characteristic verification information of the App with the App Server based on TLS connection of bidirectional verification, and the two exchanged parties have the same App characteristic identification information and App characteristic verification information. And the DPI Server sends App characteristic identification information and App characteristic verification information of the App to a DPI network element based on the TLS connection of the two-way verification. And the DPI network element verifies the legality of the App characteristic identification information in the user TLS flow according to the App characteristic verification information, and identifies the TLS flow generated by the App according to the App characteristic identification information. The invention can realize the anti-fraud and accurate and refined DPI identification of the TLS encrypted flow of the application service of the telecommunication operator cooperation SP, thereby reducing or preventing the occurrence of the flow fraud phenomenon.

Description

TLS encrypted traffic identification method and device

Technical Field

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

Background

With the continuous development of mobile broadband and intelligent terminals and the enhancement of user information Security and privacy protection, more and more network connections of the iOS and Android applications are carried by TLS (Transport Layer Security), so that TLS encryption traffic accounts for more and more. The demand scenario for telecom operators to accurately identify users TLS encrypted traffic is increasing. In a Mobile Network of a telecom operator, whether in a P-gw (Packet Data Network gateway) Network element, an MEC (Mobile Edge Computing) server, or other relevant switches, routers, firewalls, traffic analyzers, or other devices, it may be necessary to accurately identify TLS encrypted traffic based on a Deep Packet Inspection (DPI) technique.

Taking a 5G MEC as an example, edge computing provides a reliable mobile wireless network with high bandwidth and low delay for a 5G terminal, and a possible typical operation mode is that when network load is close to saturation, MEC equipment provides different QoS guarantees for different application services, and in particular provides high-priority QoS guarantees for application services paid by SPs (Service providers) with a cooperative relationship. Therefore, it is important to accurately identify the TLS encryption-based application traffic of the cooperating SPs through DPI technology.

However, the conventional DPI technology generally identifies the application service TLS encrypted traffic acting as SP according to the SNI (Server Name Indication) in the TLS Client Hello message or the Server Certificate cn (common Name) in the TLS Certificate message and the SAN (Subject Alternative Name) or DNS (Domain Name System) request/response message. Such identification methods often have drawbacks, such as: some VPN (Virtual Private Network) software disguises the VPN traffic as the application traffic of the cooperative SP of the telecom operator by using such features as SNI, CN, SAN, DNS, etc., thereby achieving the purpose of acquiring high priority QoS or avoiding charging, etc.

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

Currently, another common solution is for the telecom operator to DPI identify TLS encrypted traffic by the combined information of the server public network IP address of the cooperating SP and one or more SNI/CN/SAN/DNS. This method can refine the application service of the cooperative SP to some extent, but the refinement degree is usually not ideal. Moreover, the IETF (Internet Engineering Task Force) has encrypted the Certificate message in the TLS 1.3(RFC 8446) protocol, resulting in a failure of the CN/SAN feature; and DNS messages have been encrypted in the DoT (RFC 7858) and DoH (RFC 8484) protocols, resulting in DNS feature failures; and draft encrypted SNI has been proposed to release discussions that will cause future SNI features to fail as well.

There is a need for a feasible DPI identification method that is fraud-proof, accurately refined for the application service TLS encrypted traffic of the telecom operator partner SP. By using the method of the invention, the anti-fraud and accurate and refined DPI identification of the TLS encrypted flow of the application service of the telecom operator cooperation SP can be realized, and the occurrence of the flow fraud phenomenon is reduced or prevented.

Disclosure of Invention

The following is a summary of the subject matter described in detail herein. This summary is not intended to limit the scope of the claims.

In order to enable a telecom operator to finely identify the flow of the application service of the cooperative SP based on TLS encryption and reduce or prevent the occurrence of the flow fraud phenomenon, the invention provides a method for identifying the flow based on TLS encryption, which comprises the following steps:

the DPI Server receives App registration request information from a registration website, distributes App characteristic identification information for a target App, and sends the App characteristic identification information back to the registration website;

the DPI Server is connected with the App Server based on the TLS of the bidirectional verification, exchanges App characteristic verification information of the App with the App Server, and the exchanged two parties have the same App characteristic identification information and App characteristic verification information;

the DPI Server sends App characteristic identification information and App characteristic verification information of the App to a DPI network element based on the TLS connection of the bidirectional verification;

and the DPI network element verifies the legality of the App characteristic identification information in the user TLS flow according to the App characteristic verification information, and identifies the TLS flow generated by the App according to the App characteristic identification information.

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

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

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

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

The invention also provides a TLS encrypted traffic characteristic information management device, comprising:

the system comprises an App registration management module arranged in a DPI Server, a target network Server and a plurality of DPI servers, wherein the App registration management module is used for receiving App registration request information from a registration website, distributing App characteristic identification information for a target App and sending the App characteristic identification information back to the registration website;

an App Server update management module arranged in the DPI Server, which is connected with the App Server based on the TLS of the bidirectional verification and exchanges App characteristic verification information of the App, and the exchanged two parts have the same App characteristic identification information and App characteristic verification information;

and the DPI characteristic updating management module arranged in the DPI Server is used for sending the App characteristic identification information and the App characteristic verification information of the App to a DPI network element based on the TLS connection of the two-way verification.

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 issued by a legal third-party certificate authority.

The present invention also provides a server comprising: memory, processor and computer program stored on the memory and executable on the processor, the processor when executing the program implementing the method of TLS encrypted traffic identification according to any of the preceding claims.

Drawings

FIG. 1 is a flow chart of a TLS encrypted traffic identification method provided by the present invention;

FIG. 2 is a diagram of a TLS encrypted traffic characteristic information management apparatus according to the present invention;

FIG. 3 is a block diagram of a server provided by the present invention;

fig. 4 is a timing interaction diagram of the TLS encrypted traffic identification method provided in the present invention.

Detailed Description

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

The steps illustrated in the flow charts of the figures may be performed in a computer system such as a set of computer-executable instructions. Also, while a logical order is shown in the flow diagrams, in some cases, the steps shown or described may be performed in an order different than here.

The DPI network element described in the present invention may refer to a DPI independent network element device on the one hand, and may refer to a network element device with a built-in DPI function, such as a PGW gateway, an MEC server, an exchange, a router, a firewall, on the other hand.

The invention introduces the DPI Server and distributes information such as App Token and the like for App. The App service flow carries information such as App Token and the like through the custom TLS extension of the Server Hello message, so that a DPI network element can accurately identify the App service flow of the cooperative SP based on TLS encryption, and the DPI network element can prevent the flow fraud condition through a series of means provided by the invention: the integrity of related data is verified through MAC (Message Authentication Code), replay attack is prevented through multi-interval counter check, the identity of App is verified through public key cryptographic signature, and the accuracy of characteristic identification is enhanced through App Server public network IP address check.

As shown in fig. 1, an embodiment of the present invention provides a TLS encrypted traffic identification method.

S101, App registration phase. As shown in fig. 1, in the first step, the DPI Server receives and processes an App registration request message sent by an App developer through a registration website. And the DPI Server returns the corresponding App registration response message to the registration website to provide App registration information for the App developer.

Typically, the App registration request message includes: app name, SP name, App Server certificate CN/SAN used in App Server update phase, etc. Typically, the App registration response message includes: the special TLS extension type ID, the App Token, the date and time of successfully distributing the App Token and the like.

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

For the assignment of the dedicated TLS extension type ID, the DPI Server first ensures that the selected extension type ID cannot be the well-known extension type ID Assigned by IANA (Internet Assigned Numbers Authority). The IANA (www.iana.org) formal document "Transport Layer Security (TLS) Extensions" records the latest known extension type IDs, such as 0 being server _ name, 1 being max _ fragment _ length, 16 being application _ Layer _ protocol _ notification (alpn), 35 being session _ token, 41 being pre _ shared _ key (psk), 43 being supported _ versions, etc., which cannot be selected. The DPI Server may select the extended type ID from currently 65000 "Unassigned" numbers or 200 "Reserved for Private Use" numbers.

Optionally, the DPI Server may support that the App registration request message includes one or more value ranges of the TLS extension type ID to be excluded. The App may add other custom extension type IDs in the TLS, which are not relevant to the present invention, so the dedicated TLS extension type ID assigned by the DPI Server cannot collide with other custom extension type IDs of the App. Typically, the DPI Server assigns a dedicated TLS extension type ID for DPI identification to an App after excluding IANA-known TLS extension type IDs and excluding other extension type IDs specified by the App.

Optionally, in order to add difficulty and cost to the traffic fraud, the DPI Server may assign the same or different dedicated TLS extension type IDs to different SPs (i.e., "SP names") after excluding the IANA-known TLS extension type ID and excluding other extension type IDs specified by the App; alternatively, different apps (i.e., "SP name + App name") may be assigned the same or different private TLS extension type IDs.

Typically, an App developer deploys information such as a special TLS extension type ID obtained through a registration website, App Token, and date and time of successfully allocating the App Token to an App Server. And the App developer deploys information such as the special TLS extension type ID obtained through the registered website to the App Client.

And deploying the special TLS extension type ID in the App Client, so that the App Client carries the special TLS extension type ID when generating a Client Hello message of TLS traffic.

And deploying a special TLS extension type ID in the App Server, so that the App Server carries the extension type ID and corresponding extension contents when replying a Server Hello response to the Client Hello containing the extension type ID.

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

For the TLS 1.3 protocol, the Client Hello is not encrypted and the Server Hello is not encrypted, and the special TLS extension introduced at the stage can be normally added into the Client Hello and the Server Hello. However, since the TLS 1.3 protocol introduces Encrypted Extensions for encrypting Extensions that do not require plaintext transport, it is necessary to ensure that the special TLS Extensions introduced at this stage should be added to the Server Hello, rather than to Encrypted Extensions, when the present invention is implemented. Typically, taking OpenSSL-1.1.1 library as an example, when a custom extension is set through the Open SSL API function SSL _ CTX _ add _ custom _ EXT (), the relevant parameters of the function are set to include "SSL _ EXT _ TLS1_3_ SERVER _ HELLO" instead of "SSL _ EXT _ TLS1_3_ ENCRYPTED _ EXTENSIONS", so that the dedicated TLS extension introduced in this phase can be normally added to the SERVER HELLO.

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

Typically, the App Server update request message contains: the system comprises an App Token, date and time for successfully distributing the App Token, an App Server public network IP address (optional) and App Server public key information for DPI identification. The App Server update response message contains: legal range of the multi-interval counter, MAC key, MAC algorithm and other information.

Typically, TLS connections between App Server and DPI Server employ a two-way certificate validation mechanism, adding difficulty and cost to traffic fraud. The App Server serves as a TLS client to send the Certificate of the client to the DPI Server through an uplink Certificate message, and the DPI Server serves as a TLS Server to send the Certificate of the client to the App Server through a downlink Certificate message. The respective certificates of the App Server and the DPI Server are issued by a third-party legal CA (Certificate Authority) to ensure that the two parties can verify the legal identity of the other party through the Certificate of the other party. The DPI Server verifies the CN and SAN sent by the App Server through the uplink Certificate through the 'App Server Certificate CN/SAN used for the App Server updating phase' obtained by the first App registering phase so as to verify the legal identity of the App Server.

Typically, the App Server is connected with the TLS of the DPI Server, periodically sends an App Server update request message to the DPI Server, and sends the public IP address (optional) of the App Server and the public key information of the App Server for DPI identification to the DPI Server; meanwhile, the message carries the App Token and the date and time for successfully distributing the App Token, so that the DPI Server is associated with the related information of the App formed in the first step of App registration phase.

For example, the App Server update request message includes App Server public key information for DPI identification. Typically, the App Server may periodically regenerate the public key and its paired private key and send the newly generated public key to the DPI Server via this message. The public key is used in a subsequent fourth DPI characteristic identification stage, and the DPI network element verifies the signature of the App Server on the related part of the App Token extended content.

Optionally, in the App Server update request message, if the App Server can obtain the IP addresses of the App Server public network for the services provided by the App Client, the IP addresses should be reported to the DPI Server, so that in the subsequent fourth step of DPI feature identification, the DPI network element enhances the feature identification accuracy. Typically, for these IP addresses, it may be described by means of "including" and "excluding including" through multiple sets/pairs, for example, IPv4 may be described as including IP addresses in the range from x1.x2.x3.x4 to y1.y2.y3.y4, and excluding IP addresses in the range from m1.m2.m3.m4 to n1.n2.n3.n4, and the inclusion or exclusion may be one or more address ranges.

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

For example, the App Server update response message includes a MAC key and MAC algorithm information. Typically, the MAC algorithm may adopt an HMAC algorithm (RFC 2104), and the algorithm description format in the message may be "HMAC-MD 5", "HMAC-SHA 1", "HMAC-SHA 224", "HMAC-SHA 256", "HMAC-SHA 384", "HMAC-SHA 512", or the like.

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

Typically, the DPI feature update response message includes: the system comprises information such as an App name, an SP name, an App Server name, a special TLS extension type ID, an App Token, date and time for successfully distributing the App Token, an App Server public network IP address (optional), an App Server public key for DPI identification, a multi-interval counter legal range, an MAC key, an MAC algorithm and the like.

Typically, the TLS connection between the DPI network element and the DPI Server employs a two-way certificate authentication mechanism, which adds difficulty and cost to traffic fraud. The DPI network element serves as a TLS client to send the Certificate of the DPI network element to a DPI Server through an uplink Certificate message, and the DPI Server serves as a TLS Server to send the Certificate of the DPI network element to the DPI network element through a downlink Certificate message. The certificate of the DPI Server needs to be issued by a legal CA of a third party so as 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 signed and issued by the DPI Server as a private CA, is preset in the DPI network element and serves as a 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 TLS connection with the DPI Server to obtain the latest identification feature information of each App in the DPI Server.

Typically, the DPI Server sends each App identification feature information, which is updated with the relevant information after the last DPI network element request, to the DPI network element through a DPI feature update response message. Optionally, the DPI Server places each App Token or "SP name + App name" in a message to be sent to the DPI network element, where the update of the relevant information does not occur after the last DPI network element request.

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

And S104, a DPI feature identification stage. As shown in fig. 1, in the fourth step, the DPI network element detects the specified extension types and contents thereof in the Client Hello 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, thereby accurately identifying the App service traffic.

Typically, a Client Hello message sent by an App Client in the App service traffic includes: the previously assigned private TLS extension type ID and the content is empty. The Server Hello message sent by the App Server in the App service flow contains: the special TLS extension type ID distributed before comprises information such as App Token, date and time for successfully distributing the App Token, a multi-interval counter value in a legal range of the multi-interval counter, a signature for the front part extension content, a signature algorithm, a MAC value for the front part extension content, a MAC algorithm and the like.

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

Typically, a Server Hello message sent by the App Server includes a custom TLS extension, an extension type ID of the custom TLS extension is a dedicated TLS extension type ID allocated at the first step App registration stage, and the extension contents of the custom TLS extension are as follows:

specifically, the extended content 1: app Token. The App Token comes from the first App registration phase.

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

Specifically, the extended content 3: a multiple interval counter value within the legal range of the multiple interval counter. The legal range of the multi-interval counter comes from the second step App Server updating stage. Typically, for the same App Client user (distinguished by an IP address), the App Server takes a value from small to large within the legal range of the multi-interval counter, adds 1 to the value of the multi-interval counter of the Server Hello message connected to each TLS, and wraps around to the minimum value again after the maximum value of the value range of the multi-interval counter is reached.

Specifically, the extended content 4: signatures are made for the entire extended contents 1 to 3. The App Server signs the whole of the extended contents 1 to 3 by adopting a signature algorithm of the extended contents 5. Typically, the content is hashed to obtain a hash result with a fixed length, and then the hash result is encrypted by using a private key corresponding to an App Server public key for DPI identification, which is generated in the second-step App Server update stage, and the encrypted result is a signature.

Specifically, the extension content 5: and (4) signature algorithm. The signature algorithm is determined by the App Server, and includes a hash algorithm and a public key encryption algorithm, typically one of "MD 5-RSA", "SHA 1-RSA", "SHA 224-RSA", "SHA 256-RSA", "SHA 384-RSA", "SHA 512-RSA", and the like.

Specifically, the extended content 6: MAC values for the entire extended content 1 to 5. The App Server adopts the MAC algorithm of the extended content 7, and generates MAC values for the extended contents 1 to 5 as a whole by using the MAC key acquired from the DPI Server in the second step of App Server updating.

Specifically, the extension content 7: and (4) MAC algorithm. The MAC algorithm is determined by the App Server, and one of the MAC algorithms is selected for use from a plurality of MAC algorithms distributed by the DPI Server in the second-step App Server update phase.

Typically, the DPI network element detects whether a Client Hello message in TLS traffic contains a relevant dedicated TLS extension type ID, and if so, needs to continue to further detect a Server Hello message of the TLS-TCP (Transmission Control Protocol) flow; if not, then no further detection of the Server Hello message for the TLS-TCP flow need be continued.

Typically, the DPI network element detects whether the Server Hello message in the TLS traffic contains a relevant dedicated TLS extension type ID, and if so, continues to further detect and verify the extension content; if not, further detection and verification of the extension content is not required. Typically, the method for the DPI network element to detect and verify the extended content is as follows:

typically, the DPI network element extracts the extended content 1 as App Token. And if the follow-up verification is passed, identifying the App Token as a corresponding App, namely accurately identifying the current TLS flow as a corresponding App service.

Optionally, the DPI network element extracts the extended content 2, and as the date and time for successfully allocating the App Token, the DPI network element may be used to verify uniqueness of the App Token on one hand, and may be used to describe version information of the App Token on the other hand.

Typically, the DPI network element extracts the extension content 3 as a multi-interval counter value. And the DPI network element detects whether the value of the multi-interval counter is within the legal range of the multi-interval counter. If the value is in the legal range, checking whether the counter value of the Server Hello message multi-interval of different TLS flows of the same App Client user (distinguished by the IP address of the network side and the PORT of the network side) under the same App Server is increased or wound around by the maximum value, if the counter value is increased or wound around by the maximum value, considering that the counter value of the multi-interval passes the check, otherwise, considering that the counter value does not pass the check. If not, the inspection is not considered to be passed. And checking the legal value of the multi-interval counter to prevent the flow fraud condition based on replay attack.

Typically, the DPI network element extracts the extended content 4 as a signature of the App Server on the whole of the extended contents 1 to 3; and the DPI network element verifies the signature for the whole of the extended contents 1 to 3 by using the signature algorithm extracted from the extended contents 5 and the App Server public key for DPI identification acquired from the third DPI characteristic updating stage. Specifically, the signature algorithm extracted from the extended content 5 includes a hash algorithm and a public key encryption algorithm, and the hash algorithm is used to perform hash on the whole of the extended contents 1 to 3 to obtain a hash result; the public key encryption algorithm is adopted, and an App Server public key which is acquired from the third DPI characteristic updating stage and used for DPI identification is used for decrypting the extended content 4 to acquire a decryption result; if the hash result is consistent with the decryption result, the signature verification is considered to be passed; otherwise, the signature verification is considered to be failed. The signature verification on the extension is used for authenticating the identity validity of the App Server so as to reduce or prevent traffic fraud.

Typically, the DPI network element extracts the extension 5 as a signature algorithm to verify the extension 4.

Typically, the DPI network element extracts the extended content 6 as the MAC value of the App Server for the whole of the extended content 1 to the extended content 5; the DPI network element calculates and generates an MAC value for the whole of the extended contents 1-5 by using the MAC algorithm extracted from the extended contents 7 and the MAC key acquired from the third DPI feature updating stage; and if the generated MAC value is consistent with the extracted MAC value, the MAC check is considered to pass, otherwise, the MAC check is considered to fail. The extended MAC check is used for ensuring the integrity of the extended content and reducing the possibility of traffic fraud.

Typically, the DPI network element extracts the extension 7 as a MAC algorithm to validate the extension 6.

Typically, for an App Token passing through multi-interval counter inspection, signature verification and MAC verification, the DPI network element may identify the App Token as a corresponding App, that is, accurately identify the current TLS traffic as a corresponding App service.

Optionally, in the case of accurately identifying the App service, if the DPI network element acquires the App Server public network IP address from the third DPI feature update stage, it may check whether the network side IP address of the current TLS-TCP flow is within the App Server public network IP address range, and if so, may further enhance the accuracy of the identification result.

As shown in fig. 2, an embodiment of the present invention further provides a TLS encrypted traffic characteristic information management apparatus, including:

and an App registration management module 201 arranged in the DPI Server 200. The App registration management module receives App registration request information from a registration website, distributes App characteristic identification information for a target App, and sends the App characteristic identification information back to the registration website.

An App Server update management module 202 disposed in the DPI Server 200. The App Server updating management module is connected with the App Server through TLS based on bidirectional verification, exchanges App characteristic verification information of the App with the App Server, and the exchanged two parties have the same App characteristic identification information and App characteristic verification information.

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

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

The present invention is not limited to the above embodiments, and all equivalent modifications made within the scope of the claims of the present invention are included in the scope of the claims of the present invention.

It will be understood by those of ordinary skill in the art that all or some of the steps of the methods, systems, functional modules/units in the devices disclosed above may be implemented as software, firmware, hardware, and suitable combinations 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 performed by several physical components in cooperation. 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). The term computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data, as is well known to those of ordinary skill in the art. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by a computer. In addition, 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 includes any information delivery media as known to those skilled in the art.

Claims

1. A TLS encrypted traffic identification method comprises the following steps:

the DPI Server is connected with the App Server based on the TLS of the bidirectional verification, exchanges App characteristic verification information of a target App with the App Server, and the exchanged two parties have the same App characteristic identification information and App characteristic verification information;

the DPI Server sends App characteristic identification information and App characteristic verification information of a target App to a DPI network element based on TLS connection of bidirectional verification;

and the DPI network element verifies the legality of the App characteristic identification information in user TLS flow according to the App characteristic verification information, and identifies the TLS flow generated by the target App according to the App characteristic identification information.

2. The method of claim 1, wherein the App signature verification information comprises App public key information, MAC key and MAC algorithm information, multi-interval counter legal scope information for DPI identification.

3. The method of claim 2 wherein in the TLS connection that a DPI Server establishes with an App Server, a certificate for the App Server and a certificate for a DPI Server are both issued by a legitimate third party certificate authority.

4. The method of claim 3, wherein the DPI network element matches App feature identification information in a Server Hello message in user App traffic information, identifying traffic information for a corresponding App.

5. The method of claim 4, wherein the DPI network element verifies the validity of the corresponding App feature identification information according to App feature verification information in a Server Hello message in user App traffic information.

6. A TLS encrypted traffic characteristic information management apparatus comprising:

an App Server update management module arranged in the DPI Server, which is connected with the App Server based on the TLS of the bidirectional verification and exchanges App characteristic verification information of a target App, and the exchanged two parts have the same App characteristic identification information and App characteristic verification information;

and the DPI characteristic updating management module arranged in the DPI Server sends the App characteristic identification information and the App characteristic verification information of the target App to the DPI network element based on the TLS connection of the bidirectional verification.

7. The apparatus of claim 6, wherein the App feature verification information comprises App public key information, MAC key and MAC algorithm information, multi-range counter legal scope information for DPI identification.

8. The apparatus of claim 7, wherein in the TLS connection established by the App Server update management module with the App Server, the certificate of the App Server and the certificate of the DPI Server are both issued by a legitimate third party certificate authority.

9. A server, comprising: memory, processor and computer program stored on the memory and executable on the processor, wherein the processor when executing the program implements the method of TLS encrypted traffic identification according to any one of claims 1 to 8.