Method and apparatus for selectively decrypting ssl / tls communications

Abstract

Systems, devices, and methods for selectively decrypting SSL / TLS communications are disclosed. The contents of the decrypted communications can cause certain actions; for example, terminating the communication, or recording and storing the clear-text data packets of the communication for subsequent content inspection and analysis. An SSL / TLS proxy can inspect information contained in the TLS handshake protocol and / or inspect other information associated with the connection. Based on the inspection, the proxy can determine whether to decrypt the encrypted communication. The proxy can take additional actions based on the content inspection.

Description

[0001] This application is a divisional application of the application filed on July 24, 2018, with application number 201880055475.7, entitled "Method and Apparatus for Selectively Decrypting SSL / TLS Communication" (formerly entitled "High-Efficiency SSL / TLS Proxy").

[0002] Cross-references to related applications

[0003] This application claims priority to U.S. Patent Application Serial No. 16 / 039,896, filed July 19, 2018, and U.S. Patent Application Serial No. 62 / 536,254, filed July 24, 2017, the entire contents of which are incorporated herein by reference for all purposes. Technical Field

[0004] The aspects described herein generally relate to computer hardware and software as well as network security. In particular, one or more aspects of this disclosure generally relate to computer hardware and software for selectively decrypting encrypted communications. Background Technology

[0005] With the continuous development of the information age, network security is becoming increasingly important. In TCP / IP networks, in-transit communication between endpoints can be protected by using the Transport Layer Security (TLS) protocol or by using TLS's predecessor—Secure Sockets Layer (SSL) protocol. TLS provides privacy, authentication, and the integrity of communication. For example, the Secure Hypertext Transfer Protocol (HTTPS) protocol, commonly used to secure web communications, consists of communication over HTTP within a connection encrypted with TLS or SSL. Typically, an inline SSL / TLS proxy may be needed to intercept and decrypt in-transit TLS communication in order to examine the plaintext of the communication and then take certain actions based on that plaintext content. Typically, an SSL / TLS proxy decrypts all SSL / TLS-protected communication passing through it; however, this can be undesirable and inefficient due to factors such as computational resource limitations, network performance issues, administrative complexity, and / or privacy concerns. Therefore, methods and logic are needed that allow the SSL / TLS proxy to selectively decrypt SSL / TLS communication. Summary of the Invention

[0006] The following is a brief overview to provide a basic understanding of some aspects of this disclosure. It is not intended to identify key or essential elements of this disclosure, nor to outline its scope. The following overview presents only some concepts of this disclosure in a simplified form, serving as a prelude to the following description.

[0007] This disclosure relates to an efficient SSL / TLS proxy for selectively decrypting SSL / TLS communications. Additional logic can then be applied to the content of the decrypted communications, potentially leading to actions such as terminating the communication or recording and storing the plaintext data packets that make up the communication for subsequent content inspection and analysis. According to embodiments of this disclosure, an efficient SSL / TLS proxy can receive data indicating which SSL / TLS communications will be decrypted; alternatively, the data can indicate which SSL / TLS communications will not be decrypted. Additionally or alternatively, the efficient SSL / TLS proxy can receive a mixed list indicating a portion of SSL / TLS communications that will be decrypted and another portion that will not be decrypted. The data indicating the SSL / TLS communications may include application-level (Layer 7) information to identify one or more sets of SSL / TLS communications. In some embodiments, the identification data may include a Uniform Resource Identifier (URI) containing a URI associated with the communication. In other embodiments, the identification data may include a Fully Qualified Domain Name (FQDN). In other embodiments, the identification data may include an Internet Protocol (IP) address. In some cases, identification data used for SSL / TLS communication can be embedded in encrypted data packets, making it unusable for inspection as plaintext. This may be the case for HTTPS communication and other protocols that use URIs and FQDNs as hostnames and domain names and are protected by SSL / TLS, such as Secure File Transfer Protocol (FTPS). In such cases, the efficient SSL / TLS proxy can inspect information contained in the TLS handshake protocol and / or inspect other information associated with the connection. Based on the inspection and comparison with the communication identification list, the efficient SSL / TLS proxy can determine whether to decrypt the encrypted communication. If or when the efficient SSL / TLS proxy determines that the encrypted communication should be decrypted, it can decrypt the communication so that the plaintext content can be inspected. The efficient SSL / TLS proxy may include additional logic to inspect the plaintext content after it has been decrypted. In some embodiments, the efficient SSL / TLS proxy may take additional actions based on the plaintext content. These additional actions can be taken to create higher-level applications or strategies, such as cybersecurity (e.g., protecting networks and their assets from malicious actors); or law enforcement-related eavesdropping, where only specific communications can be decrypted for observation; or protecting the privacy of personal medical and health insurance information. This can also affect higher-level applications or strategies, such as privacy protection and compliance with privacy laws and policies, if or when the efficient SSL / TLS proxy determines that encrypted communications will not be decrypted.

[0008] This application provides the following:

[0009] 1) A method comprising:

[0010] The computing device generates a list of identification data and corresponding actions to be performed on the encrypted communication streams associated with the corresponding identification data;

[0011] The computing device receives one or more data packets that initiate an encrypted communication stream;

[0012] The computing device identifies the stream identifier data associated with the encrypted communication stream;

[0013] The computing device compares the identified stream identifier data with the list of identifier data; and

[0014] The computing device performs corresponding actions on the encrypted communication stream based on comparison.

[0015] 2) According to the method in 1), wherein the list for generating the identifier data includes:

[0016] The computing device receives a list of one or more network addresses and / or domain names from a security application; and

[0017] The list of identification data is created based on the received list of one or more network addresses and / or domain names.

[0018] 3) According to the method in 1), wherein the list for generating the identifier data includes:

[0019] The computing device receives, via a subscription service, at least one list of network addresses and / or domain names from one or more network threat intelligence providers; and

[0020] The list of identification data is created based on at least one list of the received network addresses and / or domain names.

[0021] 4) According to the method in 1), wherein the list for generating the identifier data includes:

[0022] The computing device receives a list of one or more network addresses and / or domain names from a privacy-preserving application; and

[0023] The list of identification data is created based on the received list of one or more network addresses and / or domain names.

[0024] 5) According to the method of 1), wherein the list for generating the identifier data includes:

[0025] The computing device receives a list of one or more network addresses and / or domain names from a law enforcement eavesdropping application; and

[0026] The list of identification data is created based on the received list of one or more network addresses and / or domain names.

[0027] 6) According to the method described in 1), wherein performing the corresponding action includes:

[0028] The computing device forwards multiple data packets associated with a specific encrypted communication stream to their intended destination, wherein the multiple data packets are not decrypted before forwarding.

[0029] 7) According to the method of 1), wherein the list for generating the identifier data includes:

[0030] The computing device receives a first list of one or more network addresses and / or domain names, wherein the first list of one or more network addresses and / or domain names indicates the network addresses and / or domain names whose corresponding encrypted communication streams will be decrypted;

[0031] The computing device receives a second list of one or more network addresses and / or domain names, wherein the second list of one or more network addresses and / or domain names indicates the network addresses and / or domain names whose corresponding encrypted communication streams will not be decrypted;

[0032] Assigning a first priority to a first list of one or more network addresses and / or domain names, and assigning a second priority to a second list of one or more network addresses and / or domain names, wherein the first priority is different from the second priority; and

[0033] Based on the first priority and the second priority, a sorted list of identification data is created from the first list of one or more network addresses and / or domain names and the second list of one or more network addresses and / or domain names.

[0034] 8) According to the method described in 1),

[0035] The list of identification data indicates a specific action to be performed on the identification data included in the list;

[0036] Specifically, the identified flow identifier data is compared with the list of identifier data to determine that the list of identifier data does not include the identified flow identifier data; and

[0037] Performing the corresponding action includes performing actions other than the specific action indicated by the list of the identifier data.

[0038] 9) The method according to 8), wherein the action other than the specific action indicated by the list includes terminating the encrypted communication stream.

[0039] 10) The method according to 8), wherein the actions other than the specific actions indicated by the list include:

[0040] Record the data packets associated with the encrypted communication stream for subsequent analysis; and

[0041] The data packets associated with the encrypted communication stream are forwarded to their respective intended destinations.

[0042] 11) An apparatus comprising:

[0043] At least one processor; and

[0044] A memory storing instructions that, when executed by the at least one processor, cause the device to:

[0045] Generate a list of identification data and the corresponding actions to be performed on the encrypted communication stream associated with each corresponding identification data;

[0046] Receive one or more data packets that initiate an encrypted communication stream;

[0047] Identify the stream identifier data associated with the encrypted communication stream;

[0048] Compare the identified stream identifier data with the list of identifier data; and

[0049] Based on comparing the identified stream identifier data with the list of identifier data, the corresponding action is performed on the encrypted communication stream.

[0050] 12) The apparatus according to 11), wherein the instructions, when executed by the at least one processor, further cause the apparatus to:

[0051] Receive a list of one or more network addresses and / or domain names from a security application; and

[0052] The list of identification data is created based on the received list of one or more network addresses and / or domain names.

[0053] 13) The apparatus according to 11), wherein the instruction that, when executed by the at least one processor, causes the apparatus to generate the list of the identification data, further causes the apparatus to:

[0054] Receive at least one list of network addresses and / or domain names from one or more network threat intelligence providers through a subscription service; and

[0055] The list of identification data is created based on at least one list of the received network addresses and / or domain names.

[0056] 14) The apparatus according to 11), wherein the instruction that, when executed by the at least one processor, causes the apparatus to generate the list of the identification data, further causes the apparatus to:

[0057] Receive a list of one or more network addresses and / or domain names from a privacy-protected application; and

[0058] The list of identification data is created based on the received list of one or more network addresses and / or domain names.

[0059] 15) The apparatus according to 11), wherein the instruction that, when executed by the at least one processor, causes the apparatus to generate the list of the identification data, further causes the apparatus to:

[0060] Receive a list of one or more network addresses and / or domain names from a law enforcement eavesdropping application; and

[0061] The list of identification data is created based on the received list of one or more network addresses and / or domain names.

[0062] 16) The apparatus according to 11), wherein the instruction that causes the apparatus to perform the corresponding action when executed by the at least one processor further causes the apparatus to:

[0063] Multiple data packets associated with a specific encrypted communication stream are forwarded to their intended destination, wherein the multiple data packets are not decrypted before forwarding.

[0064] 17) The apparatus according to 11), wherein the instruction that causes the apparatus to generate the identification data when executed by the at least one processor further causes the apparatus to:

[0065] Receive a first list of one or more network addresses and / or domain names, wherein the first list of one or more network addresses and / or domain names indicates the network addresses and / or domain names whose corresponding encrypted communication streams will be decrypted;

[0066] Receive a second list of one or more network addresses and / or domain names, wherein the second list of one or more network addresses and / or domain names indicates the network addresses and / or domain names whose corresponding encrypted communication streams will not be decrypted;

[0067] Assigning a first priority to a first list of one or more network addresses and / or domain names, and assigning a second priority to a second list of one or more network addresses and / or domain names, wherein the first priority is different from the second priority; and

[0068] Based on the first priority and the second priority, a sorted list of identification data is created from the first list of one or more network addresses and / or domain names and the second list of one or more network addresses and / or domain names.

[0069] 18) According to the apparatus described in 11),

[0070] The list of identification data indicates a specific action to be performed on the identification data included in the list;

[0071] Specifically, the identified flow identifier data is compared with the list of identifier data to determine that the list of identifier data does not include the identified flow identifier data; and

[0072] The instruction that causes the device to perform the corresponding action when executed by the at least one processor further causes the device to perform an action other than the specific action indicated by the list of the identification data.

[0073] 19) The apparatus according to 18), wherein the action, in addition to the specific action indicated by the list of the identification data, includes terminating the encrypted communication stream.

[0074] 20) The apparatus according to 18), wherein the action, in addition to the specific action indicated by the list, further causes the apparatus to:

[0075] Record the data packets associated with the encrypted communication stream for subsequent analysis; and

[0076] The data packets associated with the encrypted communication stream are forwarded to their respective intended destinations. Attached Figure Description

[0077] This disclosure is specifically pointed out in the appended claims. Its features will become more apparent from a review of the disclosure as a whole (including the accompanying drawings).

[0078] In the figures of the accompanying drawings, some features herein are shown by way of example rather than limitation, wherein similar reference numerals refer to similar elements, and wherein:

[0079] Figure 1 A flowchart illustrating the operation of an efficient SSL / TLS proxy is shown.

[0080] Figure 2 An exemplary environment for an efficient SSL / TLS proxy for selectively decrypting encrypted communications, according to one or more aspects of this disclosure, is shown.

[0081] Figure 3 An exemplary high-efficiency SSL / TLS proxy for selectively decrypting encrypted communications is shown, according to one or more aspects of this disclosure;

[0082] Figure 4A , Figure 4B , Figure 5A , Figure 5B , Figure 5C and Figure 6 Exemplary event sequences are shown, illustrating methods for selectively decrypting TLS-protected communications according to one or more exemplary aspects described herein;

[0083] Figure 4A and Figure 4B This illustrates the process by which an efficient SSL / TLS proxy determines the domain name of an HTTPS server without decrypting the HTTPS session;

[0084] Figure 5A , Figure 5B and Figure 5C This demonstrates how an efficient SSL / TLS proxy can determine the process of decrypting an HTTPS session based on the domain name of the HTTPS server;

[0085] Figure 6 It shows something similar to Figures 5A-5C The process, except that the session URI does not match any element in the URI-decrypt-list. Detailed Implementation

[0086] In the following description of various exemplary embodiments, reference is made to the accompanying drawings, which form a part of this specification, and in which various embodiments that may practice aspects of this disclosure are illustrated by way of example. It should be understood that other embodiments may be utilized, and structural and functional modifications may be made, without departing from the scope of this disclosure. Furthermore, specific applications, protocols, and embodiments in which aspects of this disclosure may be practiced are referenced. It should be understood that other applications, protocols, and embodiments may be utilized, and structural and functional modifications may be made, without departing from the scope of this disclosure.

[0087] Various connections between components are discussed in the following description. These connections are general and, unless otherwise specified, can be direct or indirect, wired or wireless, physical or logical. In this respect, this specification is not intended to be limiting.

[0088] For simplicity, it is assumed that the TLS tunneling protocol is HTTP, the HTTPS server uses port 443 and TCP, and the IP version is IPv4. These assumptions and related specifications are not intended to be limiting in any way. This description can be readily applied to cover application-level protocols other than HTTP, ports other than 443, transport protocols other than TCP (e.g., UDP, SCTP, etc.), and other IP versions such as IPv6.

[0089] Many TCP / IP network communications are transmitted in plaintext, so an observer can read the communications by clicking on the link carrying the communication (wired, wireless, virtual, etc.). Such observation may not be desirable. For example, cybercriminals might observe financial transactions or collect other sensitive data; the latter could violate personal privacy. Transport Layer Security (TLS) or its predecessor, Secure Sockets Layer (SSL), can be used to protect network communications in transit by encryption, preventing the plaintext of the communications from being observed. To secure communication, two endpoints can first establish a TLS tunnel using the TLS handshake protocol, and then send communications through that tunnel. The tunnel provides privacy through encryption; authentication through X.509 certificates and associated public key encryption; and communication integrity through message authentication encoding.

[0090] For historical reasons, the labels "SSL" and "TLS" are often used interchangeably, although TLS has largely replaced and superseded SSL, which was the predecessor to TLS and has been deprecated / disabled by the Internet Engineering Task Force (IETF) due to security flaws. One notation convention adopted herein is to use the label "SSL / TLS" to indicate either or both protocols. In illustrative examples, embodiments, and figures, the TLS protocol is used unless otherwise stated, but this is not intended to limit the scope in any way relative to SSL, as the differences between SSL and TLS are irrelevant in the context of this disclosure.

[0091] A popular use of SSL / TLS is to secure HTTP (Web) communications when transmitted across networks. This configuration is known as the HTTPS protocol. The use of HTTPS to secure legitimate e-commerce communications has become widespread. The use of HTTPS by cybercriminals and other malicious actors has also become prevalent, motivated by the fact that HTTPS can mask their malicious activities, and that detecting and mitigating such activities is generally more difficult and costly than HTTP-mediated malicious activities.

[0092] One method to protect a network from cybercriminals and cyberattacks could be: (a) collecting cyber threat intelligence on the network addresses of endpoints operated / controlled by malicious actors; (b) filtering all network traffic—TCP / IP packets—communicating with that network address; (c) taking action if a match or correspondence is found between the network address and the network communication in the CTI; for example, blocking the communication; or monitoring, recording, and capturing the packets constituting the communication; and (d) analyzing the communication in terms of attack severity, asset loss, mitigation actions, and remedial actions.

[0093] Network addresses from CTIs can include one or more of the following identifying data: network layer (Layer 3) Internet Protocol (IP) address and protocol identifier, transport layer (Layer 4) port, and application layer (Layer 7) domain name (e.g., "cybersite.net"), host FQDN (e.g., "www.cybersite.net"), URI (e.g., "http: / / www.cybersite.net / path-segment-1 / path-segment-2 / resource-id"), and IP address (e.g., included in an HTTP header extension to identify the original source). If communication is mediated by HTTP, the network address information used for communication can be filtered directly against the CTI because it is not encrypted. However, if communication is mediated by HTTPS, the host FQDN or URI address included in the HTTP message may be encrypted, making direct filtering against the CTI impossible. This can be problematic for network analysts searching for network threats and attacks, as CTIs in URI form are generally considered the most reliable threat indicators. Conversely, this could benefit cybercriminals, who could evade conventional cybersecurity controls by using HTTPS to transmit sensitive information to URE-addressed resources under their control.

[0094] A common solution for viewing plaintext communications protected by HTTPS is to utilize an inline SSL / TLS proxy. When two endpoints initiate a session, such as a web client (e.g., a web browser application) and a web server, the proxy can initially create two separate TLS tunnels: one between the proxy and the web client, and the other between the proxy and the web server. Each tunnel's endpoint can encrypt inbound information and decrypt outbound information. Inside the proxy, a "man-in-the-middle" (MITM) can reside between the tunnel endpoints and act as an intermediary between the two TLS tunnels, applying logic to the (plaintext) information passed from one tunnel to the other. The MITM can, for example, examine the plaintext of HTTP communications, including the complete URI. The plaintext URI can be compared to the CTI to detect potential attacks.

[0095] This disclosure addresses several efficiency issues associated with SSL / TLS proxies. One issue is that SSL / TLS proxies consume significant computing resources compared to intermediate functions that do not decrypt and reencrypt TLS-protected communications. Insufficient computing resources can negatively impact network performance and degrade the end-user experience. Conversely, the availability of sufficient computing resources and the associated proxy management costs can be prohibitively expensive relative to budget—both in terms of capital expenditures (CAPEX) and operating expenditures (OPEX); therefore, organizations may not choose to use SSL / TLS proxies unless there is a compelling reason or requirement to do so.

[0096] Another issue might be that after setting up a proxy tunnel and MITM, the decryption / reencryption process continues throughout the entire session. This means it might be impossible to stop the decryption / reencryption process without halting communication, even after it has been determined that the proxy is no longer needed to read the plaintext of the communication. Another problem might be that for some applications or strategies involving network security and privacy protection, it may often be necessary to decrypt only a relatively small percentage of SSL / TLS tunnel traffic into plaintext; however, the lack of a native mechanism to decrypt only the relevant session for these applications and strategies could lead to inefficiency. For example, a network security application might only be interested in the plaintext of an HTTPS session where the underlying HTTP is accessing its specific URI or multiple URIs; however, since URIs may not be sent in plaintext during an HTTPS session, determining whether or when an HTTPS session is accessing a specific URI might require decrypting the HTTPS session.

[0097] This disclosure describes a technique for selectively decrypting SSL / TLS-protected sessions (e.g., HTTPS sessions) when the selection criteria are the host's FQDN (e.g., "www.abc123.com") and URI (e.g., https: / / www.abc123.com / path-segment-1 / path-segment-2 / resource). This technique is useful because, for HTTPS sessions, when a TLS-tunneled HTTP session is sending HTTP messages containing the host's FQDN and URI, these HTTP messages are encrypted; thus, an observer outside the tunnel cannot read the selection criteria, i.e., the host's FQDN and URI, in plaintext.

[0098] Figure 1 A flowchart illustrating a method for selectively decrypting SSL / TLS communication, according to one or more exemplary embodiments, is shown. Figure 1 As can be seen, it can be found in, for example... Figure 2 The system shown, as well as other systems with different architectures (e.g., Figure 3 The exemplary flowchart and other similar examples described herein are executed in the computing environment of the device. In other embodiments, Figure 1 The methods and / or one or more steps thereof shown may be embodied in a computer-readable medium, such as in a non-transitory computer-readable storage medium.

[0099] refer to Figure 1 According to one or more embodiments described herein, in step 1-1, the efficient SSL / TLS proxy (“E-PROXY”) can construct a list of identifying data. E-PROXY can be configured to construct a first list of URIs, called a “URI-decrypt-list,” for which any HTTPS session connected to a URI address in the URI-decrypt-list will be decrypted. E-PROXY can also construct a second list of domain names and host FQDNs, called a “domain-name-decrypt-list,” for which any HTTPS session connected to a host whose name is in the domain-name-decrypt-list will be decrypted, while HTTPS sessions connected to hosts not in the domain-name-decrypt-list will not be decrypted.

[0100] In steps 1-2, for each URI in the URI-decrypt-list, E-PROXY can extract the hostname value from the URI, which may include an FQDN or an IP address, and add the extracted name value to the domain-name-decrypt-list. E-PROXY can be further configured to remove duplicates from the domain-name-decrypt-list. Alternatively or otherwise, E-PROXY can prevent duplicate hostname value identifiers from being added to the domain-name-decrypt-list. The domain-name-decrypt-list may contain IP addresses, but in some embodiments, the list may include a domain name and FQDN used to indicate the host.

[0101] In steps 1-3, E-PROXY can provide its "man-in-the-middle" (MITM), a proxy device that observes and can act on all network traffic on the link that transmits HTTPS sessions between endpoints, including HTTPS clients and HTTPS servers. In steps 1-4, for each TLSS tunnel setup, or TLS handshake, transmitted over the link, the MITM proxy can check the value of the Server Name Indication (SNI) field contained in the (plaintext) ClientHello message sent from the HTTPS client to the HTTPS server. This field can correspond to the FQDN of the destination HTTPS server. Furthermore, through a subsequent (plaintext) Certificate message sent from the HTTPS server to the HTTPS client, the value of the Subject:CN (General Name) field of the server certificate can be checked; this field is also the FQDN of the HTTPS server. It should be noted that the SNI value should, but not necessarily, match the Subject:CN value. In one or more embodiments / examples / scenarios, the SNI and CN values ​​may match. In such embodiments, the MITM proxy can be configured to continue the TLS session. In other embodiments, the SNI and CN values ​​may not match, and the MITM proxy may be configured to select the CN value to determine selective encryption because it is reliably the FQDN of the server used for the HTTPS session, while the SNI value is unreliable; or alternatively, the MITM proxy may warn of an exception but continue the TLS session, or it may warn of an exception and terminate the TLS session.

[0102] Similarly, in steps 1-4, the MITM proxy can compare the server's FQDN value with elements in the domain-name-decrypt-list. If no match or sufficient correspondence exists, in step 1-5a, the MITM proxy can take no action to decrypt the session, thus saving computational resources and potentially allowing for the implementation of strategies such as privacy protection. If a match or sufficient correspondence exists, in step 1-5b, the proxy can set up and use SSL / TLS proxy functionality to (a) decrypt the HTTPS session; and (b) inspect the plaintext of the HTTPS session. Before applying any intermediate logic to the plaintext, the MITM proxy checks whether the session's domain name value has been inserted into the domain-name-decrypt-list, as it is the hostname extracted from the URI-decrypt-list. If so, the proxy compares the session's URI value with elements in the URI-decrypt-list. If no match or sufficient correspondence exists, in step 1-6a, the proxy can re-encrypt the session and forward it to the destination without applying any intermediate logic to the plaintext of the session. If a match exists, or if the session's domain name is not generated from the URI-decrypt-list, then in steps 1-6b, the agent may apply certain intermediate logic to the session's plaintext. This intermediate logic may, for example, take some action on the session specified by a higher-level application (e.g., network security, privacy protection, law enforcement), such as blocking communication; or allowing communication to continue but logging and capturing the plaintext packets constituting the communication; or performing some transformation on the plaintext. If the intermediate logic does not block communication, the plaintext packets are re-encrypted and forwarded to the destination.

[0103] It should be noted that if Figure 1 The process proceeds to steps 1-5b and decrypts the session, but then proceeds to step 1-6a because the session's URI does not match an element in the URI-decrypt-list, resulting in unnecessary decryption of the session. However, since step 1-6a skips any intermediate logic applied in step 1-6b, efficiency can still be achieved. Furthermore, there is a non-zero probability of a URI match in step 1-5b, in which case the process will proceed to step 1-6b; in this case, decryption is necessary. Therefore, although unnecessary decryption may occur in step 1-5b, the overall process is deterministically more efficient when consistently applied to all TLS sessions in a typical real-world computing environment.

[0104] Alternatively, if the FQDN of the host associated with the HTTPS session is included in the domain-name-do-not-decrypt-list, the proxy can use the domain-name-do-not-decrypt-list instead of the domain-name-decrypt-list to selectively not decrypt the HTTPS session. Alternatively, both types of lists can be used simultaneously, with one list given higher priority than the other. This can occur when different applications or policies generate the lists; for example, the domain-name-decrypt-list might be generated by network security applications and policies, while the domain-name-do-not-decrypt-list might be generated by privacy protection applications and policies.

[0105] Figure 2 An exemplary environment for an efficient SSL / TLS proxy for selectively decrypting encrypted communications, according to one or more aspects of this disclosure, is shown. References Figure 2 Environment 100 may include network A 102 and network B 104, which are connected via network link 106 providing internet access / interconnection. Network A 102 may include one or more networks (e.g., local area network (LAN), wide area network (WAN), virtual private network (VPN), software-defined network (SDN), or combinations thereof) associated with one or more individuals or entities (e.g., governments, companies, service providers, or other organizations). Network B 104 may include one or more networks (e.g., LAN, WAN, VPN, SDN, or combinations thereof) that enable network A 102 to interact with one or more other networks (not shown). For example, network B 104 may include the Internet or a similar network or a portion thereof.

[0106] Environment 100 may also include one or more hosts, such as computing devices or network devices (e.g., servers, desktop computers, laptop computers, tablets, mobile devices, smartphones, routers, gateways, proxies, firewalls, switches, access points, etc.). For example, network 102 may include: hosts 110, 112, and 114, which may be configured to act as clients; proxy device 120; and network 104 may include hosts 130, 132, and 134, which may be configured to act as servers. As used herein, a “host” (or multiple “hosts”) means any type of network device (or node) or computing device; although such devices may be assigned (or configured to be assigned) one or more network layer addresses, the term “host” (or “host”) does not mean that such devices must be assigned (or configured to be assigned) one or more network layer addresses.

[0107] Proxy 120 may be located at or near the network boundary and network link 106 between networks 102 and 104, and may enable network 102 or one or more hosts therein to interact with network 104 or one or more hosts therein. For example, network 104 may contain hosts 130, 132, and 134, which may host networked application servers (e.g., web servers); while network 102 may contain hosts 110, 112, and 114, which may host networked application clients (e.g., web browsers). Proxy 120 may act as an intermediary proxy between networked application clients and servers, such as a web proxy mediating HTTP sessions between a web client and a web server, or an SSL / TLS proxy mediating HTTPS sessions between a web client and a web server.

[0108] Figure 3 An exemplary high-efficiency SSL / TLS proxy, E-PROXY 120, for selectively decrypting TLS-protected communications, is shown according to one or more aspects of this disclosure. References Figure 3Agent 120 may be located inline on network link 106 connecting networks 102 and 104. Agent 120 may include one or more TCP proxies (e.g., TCP-AGT1121 and TCP-AGT2 122), one or more TLS proxies (e.g., TLS-AGT1123 and TLS-AGT2 124), a "man-in-the-middle" (MITM) intermediary MITM 125, a Certificate Authority (CA) 126, a list manager LST-MGR 128, a storage store 129, a network interface NTKW I / F 127, and a data bus DATA-BUS 140 that interconnects the components of the agent. Agent 120 may interact inline with network link 106 via network interface 127. Therefore, IP packets, including TLS-protected communication between endpoints connected to networks 102 and 104, may pass through agent 120. TCP proxies 121 and 122 may terminate TCP connections, maintain TCP session state, and spoof IP network endpoints. TCP proxies 121 and 122 can also be configured to calculate (locally unique) flow identifiers, maintain flow state information, send / receive messages to / from other proxy components, and route / exchange messages to / from other proxy components. TCP proxies 121 and 122 can store and retrieve state information and other information via storage STORE 129. TLS proxies TLS-AGT1 123 and TLS-AGT2 124 can terminate TLS tunnels, maintain TLS session state, and spoof TLS clients and servers. TLS proxies 123 and 124 can also be configured to maintain TLS session state information, send / receive messages to / from other proxy components, and route / exchange messages to / from other proxy components. TCP proxies 123 and 124 can store and retrieve state information and other information via storage STORE 129. According to one or more aspects of this disclosure, TLS proxies 123 and 124 can interact with a Certificate Authority (CA) 126 as needed to generate digital certificates, such as X.509 certificates.

[0109] The "Man-in-the-Middle" (MITM) intermediary proxy MITM 125 can be configured to act on information in packets already decrypted by TLS proxies 123 and 124, such as cybersecurity applications, law enforcement applications, and privacy protection applications; for example, based on one or more requests from a higher-level application executing in proxy 120, MITM proxy 125 can copy packets and store them in storage STORE 129, can log packets and store logs in storage STORE 129, etc. According to one or more aspects of this disclosure, MITM proxy 125 can also be configured to signal message routing between proxy components to enable efficient proxy operation. By comparing the IP addresses, domain names, and URIs associated with communication through the proxy with a list of IP addresses, domain names, and URIs created and maintained by list manager 128, MITM proxy 125 can make concurrent signaling message routing decisions between proxy components based on information received from list manager LST-MGR 128.

[0110] Figure 3 An example of a system architecture that can be used is shown, and in some cases, the specific system architecture and computing devices used may vary and be secondary to the functionality they provide without departing from the scope of this disclosure. For example, one or more computing devices may be distributed across a network; that is, a portion of the data bus DATA-BUS140 may be a network. As another example, some components may be logically contained within other components; for example, TCP and TLS proxies may be integrated into a single component. As yet another example, the storage STORE 129 may consist of multiple sub-components that may be shared by multiple computing devices or dedicated to a single computing device.

[0111] Figures 4A-4B , Figures 5A-5C and Figure 6 An exemplary sequence of events for an efficient SSL / TLS proxy for selectively decrypting encrypted communications, according to one or more aspects of this disclosure, is shown. The steps shown are merely illustrative and may be omitted, combined, or performed in a different order than that shown; the numbering of the steps is for convenience only and does not imply that any particular order is necessary or preferred. The TLS handshake process shown is a basic handshake; other handshake message sequences are possible, but these do not affect the scope of this disclosure. Figures 4A-4B , Figures 5A-5C and Figure 6An exemplary embodiment is shown in which the HTTPS protocol is used on port 443, and the SSL / TLS proxy is transparent at network layer 3. In other words, the proxy components do not have IP addresses, nor do they change the source and destination IP addresses or protocol types at layer 3 / IP, nor do they change the source and destination ports at layer 4 / transport. However, these constraints, examples, and assumptions are exemplary and do not limit the scope of this disclosure, and can be applied to other TLS-protected protocols besides HTTPS, and to non-transparent proxies in other similar embodiments.

[0112] Similarly, for simplicity, when referring to a TLS handshake message sent between components X and Y, such as ClientHello, this is a shorthand representation of "one or more IP packets containing the TLS message ClientHello are sent from component X to component Y". Likewise, for HTTP messages, such as the GET method, each HTTP message can be contained within one or more IP packets sent between components.

[0113] Figure 4A and Figure 4B An embodiment is shown in which an efficient SSL / TLS proxy determines the HTTPS server's domain name without decrypting the HTTPS session. (See reference) Figure 4A In step 4-1, the list manager LST-MGR 128 generates a domain-name-decrypt-list containing domain names. Among other things, list generation can be performed via a user interface that accepts domain names, host FQDNs, etc., as input; or by extracting host FQDNs from URIs provided by a threat intelligence provider through a subscription service; or by using domain names provided by a threat intelligence provider through a subscription service; or by using privacy protection data and policies, etc. In step 4-2, the list manager LST-MGR 128 can transmit the domain-name-decrypt-list to MITM 125. The list manager can also generate and send a URI-decrypt-list containing URIs to MITM 125 if, or when a high-level application using an efficient SSL / TLS proxy requests a comparison of the URI of an HTTPS session with a database of URIs (e.g., as might happen in a cybersecurity application), which is used to derive a portion of the domain names from the domain-name-decrypt-list.

[0114] In steps 4-3, host HOST1 110 can initiate an HTTPS session with web server SRV1 130, which has a domain name (e.g., "www.srv1.net"), via a web browser (web / HTTP client) by directing the browser to the URI (e.g., "https: / / www.srv1.net / index.html"). HOST1 110 can resolve the domain name "www.srv1.net" to an IP address, such as 1.2.3.4. In some embodiments, HOST1 110 can resolve the domain name by checking its local cache. In other embodiments, HOST1 110 can query a Domain Name System (DNS) server (... Figure 4A (Not shown in the image).

[0115] To initiate HTTPS session communication with web server SRV1 130, in step 4-3, HOST1 110 can initiate a TCP connection with web server SRV1 130 on port 443 by publishing a TCP SYN message, which can be intercepted by TCP-AGT1 121. TCP-AGT1 121 can locally compute (and record in a lookup table) the (bidirectional) flow identifier "Flow-1234" for the TCP connection. For example, the flow identifier may include a hash of the source and destination IP addresses, source and destination ports, IP protocol type, and possibly other information of the packet, as well as the current or initial default in-proxy packet forwarding action of the packet associated with this HTTPS session. For packets transmitted in the client-to-server direction, such as TCP SYN packets initiating a new session, the initial default in-proxy packet forwarding action may be to forward the packet directly from TCP-AGT1 121 to TCP-AGT2 122, as shown in step 4-4. TCP-AGT2 122 can calculate and record the flow identifier "Flow-1234" and the initial default in-proxy packet forwarding action (i.e., packets transmitted in the server-to-client direction will be forwarded directly from TCP-AGT2 122 to TCP-AGT1 121). In steps 4-5, TCP-AGT2 122 can forward TCP SYN packets to its destination, the web server SRV1 130.

[0116] In steps 4-6, multiple sub-steps of TCP packet transmission establish a TCP connection between host HOST1 110 and web server SRV1 1130, mediated by TCP-AGT1 121 and TCP-AGT2 122, and are generally shown as bidirectional arrows between HOST1 1110, TCP-AGT1 121, TCP-AGT 122, and SRV1 130.

[0117] The following steps establish a TLS tunnel mediated by an SSL / TLS proxy between HOST1 110 and SRV1 130, during which the domain-name-decrypt-list is searched. In steps 4-7, HOST1 110 can send a TLS ClientHello message to SRV1 130, which is intercepted by TCP-AGT1 121. Upon receiving the TLSClientHello message (which initiates the TLS handshake / tunnel setup process), TCP-AGT1 121 can be configured to set its in-proxy packet forwarding action to forward client-to-server packets for this Flow-1234 to TLS-AGT1 123. In steps 4-8, TCP-AGT1 121 can send the TLS ClientHello message to TLS-AGT1 123.

[0118] In response to receiving one or more packets including a ClientHello message, in steps 4-9, TLS-AGT1 123 may calculate and record a flow identifier value (e.g., “Flow-1234”) and an initial default in-proxy packet forwarding action, which may be to forward the ClientHello message directly to TLS-AGT2 124. TLS-AGT1 123 may extract the Server Name Indicator (SNI) value from the ClientHello message. In some embodiments, the SNI value may be unavailable because the browser / host's use of the SNI field (signaling to the server which virtual domain is being requested) may be optional. In other embodiments, the SNI value may be incorrect or may have been manipulated by a malicious adversary. In any case, the certificate provided by server SRV1 130 (www.srv1.net) in subsequent steps will have the actual server name (www.srv1.net) in the Subject:CN (General Name) field of the certificate and may be used to verify (or not verify) the correctness of the SNI value. Assuming the SNI value is being used and it is correct, i.e., the value is www.srv1.net. In steps 4-9, TLS-AGT1 123 can send a query to MITM 125 to check if www.srv1.net is in the domain-name-decrypt-list. In step 4-10, in response to receiving the query request from step 4-9, MITM 125 can search the domain-name-decrypt-list, and based on this search, can determine that www.srv1.net is not in the list, therefore the session should not be decrypted, and can respond to the query with an indication that the requested domain was not found, thereby signaling to TLS-AGT1 123 that www.srv1.net is not in the domain-name-decrypt-list, and therefore the proxy should not decrypt the associated HTTPS session.

[0119] refer to Figure 4BIn step 4-11, TLS-AGT1 123 can signal to both TCP proxies (e.g., TCP-AGT1 121 and TCP-AGT2 122) to directly send all (directed) intra-proxygen packets corresponding to the flow identifier "Flow-1234" to each other, thus bypassing the proxy function. This step has the advantage of increasing proxy efficiency and reducing processing and resource load on the proxies by avoiding unnecessary communication decryption and re-encryption. In step 4-12, TLS-AGT1 123 can send a ClientHello message to TCP-AGT2 122. In step 4-13, TCP-AGT2 122 can send the ClientHello message to its destination, the web server SRV1 130. In step 4-14, SRV1 130 can respond to the ClientHello message with a TLS ServerHello message, which can be intercepted by TCP-AGT2 122. TCP-AGT2 122 can calculate the flow identifier "Flow-1234" of a data packet, and this can be found in STORE 129 (reference). Figure 3 The system searches for the packet in TCP-AGT1 121 to perform intra-proxy packet forwarding, which involves sending the packet directly to TCP-AGT1 121, thus bypassing the proxy function. In step 4-15, TCP-AGT2 122 can send the ServerHello message directly to TCP-AGT1 121. In step 4-16, TCP-AGT1 121 can send the ServerHello message to HOST1 110.

[0120] In steps 4-17, multiple sub-steps involving the sending of subsequent TLS handshake messages (Certificate, ServerKeyExchange, ..., Finished, etc.) between host HOST1 110 and web server SRV1 130 establish a TLS tunnel between HOST1 110 and SRV1 1130, mediated by TCP-AGT1 121 and TCP-AGT2 122, and generally represented as a bidirectional arrow between HOST1 1110, TCP-AGT1 121, TCP-AGT 122, and SRV1 130. The TLS messages referenced above can bypass the proxy function because this HTTPS session will not be decrypted, as determined by the domain-name-decrypt-list (which does not contain www.srv1.net).

[0121] A TLS tunnel has now been created, with endpoints at HOST1 110 and SRV1 130. HOST1 110 and SRV1 130 can conduct HTTP sessions, but each HTTP message is encrypted upon entering the TLS tunnel and decrypted upon leaving the tunnel, i.e., it is an HTTPS session. Step 4-18 generally illustrates the HTTPS session between HOST1 110 and SRV1 130, mediated by TCP-AGT1 121 and TCP-AGT2 122. If or when the HTTPS session ends, the TCP connection between HOST1 110 and SRV1 130 can be disconnected via a typical TCP signal sequence (e.g., FIN, ACK alternating). This is generally represented in step 4-19, where TCP-AGT1 121 and TCP-AGT2 122 are mediated.

[0122] Figure 5A , Figure 5B and Figure 5C This illustrates an example where an efficient SSL / TLS proxy can determine the decryption of an HTTPS session based on the domain name of the HTTPS server. During decryption, the session's URI may match a list of URIs managed by the MITM 125. Therefore, according to the logic of some high-level applications (e.g., network security applications) utilizing the efficient proxy, further processing of the encrypted packets constituting the HTTPS session can be performed by passing these packets through the MITM 125.

[0123] for Figure 5A Steps 5-1 to 5-8 and Figure 4A The corresponding steps 4-1 to 4-8 are similar, except that the target HTTPS server is web server SRV2 132 instead of SRV1 130. Figure 5A Steps 5-1 and 5-2 in the text are similar to... Figure 4A Steps 4-1 and 4-2 are the same.

[0124] refer to Figure 5A Host 110 can initiate an HTTPS session with web server SRV2 132 (with the domain name www.srv2.net) by directing its browser to the URI https: / / www.srv2.net / index.html using a web browser (web / HTTP client). Host 110 checks its local DNS cache or queries the Domain Name System (DNS), etc. Figure 5A (Not shown in the image) Resolve the domain name www.srv2.net into an IP address, such as 5.6.7.8.

[0125] To initiate an HTTPS session with web server SRV2 132 (www.srv2.net), in step 5-3, HOST1 110 first initiates a TCP connection to web server SRV2 132 port 443 by publishing a TCP SYN message (which is intercepted by TCP-AGT1 121). TCP-AGT1 121 locally calculates (and records in a lookup table) the (bidirectional) flow identifier "Flow-5678" for this TCP connection, such as hashes of the source and destination IP addresses, source and destination ports, and IP protocol type of the packets, as well as the current or initial default in-proxy packet forwarding action for packets associated with this HTTPS session. For packets transmitted in the client-to-server direction, such as this TCP SYN packet initiating a new session, the initial default in-proxy packet forwarding action is to forward the packet directly from TCP-AGT1 121 to TCP-AGT2 122, which is performed by TCP-AGT1 121 in step 5-4. Similarly, TCP-AGT2 calculates and records the flow identifier "Flow-5678" and the initial default in-proxy packet forwarding action (i.e., packets destined for the server-to-client direction are forwarded directly from TCP-AGT2 122 to TCP-AGT1 121). In steps 5-5, TCP-AGT2 122 forwards TCP SYN packets to its destination, the web server SRV2132.

[0126] In steps 5-6, multiple sub-steps of TCP packet transmission establish a TCP connection between HOST1 110 and SRV2 132, mediated by TCP-AGT1 121 and TCP-AGT2 122, and are generally shown as bidirectional arrows between HOST1 110, TCP-AGT1 1121, TCP-AGT 122, and SRV2 132.

[0127] The following steps establish a TLS tunnel mediated by an SSL / TLS proxy between HOST1 110 and SRV2 132, during which the domain-name-decrypt-list is searched. In steps 5-7, host HOST1 110 can send a TLS ClientHello message to web server SRV2 132, which is intercepted by TCP-AGT1 121. Upon receiving the TLSClientHello message (which initiates the TLS handshake / tunnel setup process), TCP-AGT1 121 can be configured to set its in-proxy packet forwarding action to forward client-to-server packets to TLS-AGT1 123. In steps 5-8, TCP-AGT1 121 can send a packet containing the TLS ClientHello message to TLS-AGT1 123.

[0128] Upon receiving a packet containing a ClientHello message, TLS-AGT1 123 calculates and records the flow identifier value "Flow-5678" and the initial default in-proxy packet forwarding action, which could be to forward the ClientHello message directly to TLS-AGT2 124. However, first, TLS-AGT1 123 extracts the Server Name Indicator (SNI) value from the ClientHello message (which is www.srv2.net). In steps 5-9, TLS-AGT1 123 sends a query to MITM 125 to check if www.srv2.net is in the domain-name-decrypt-list. MITM 125 searches the domain-name-decrypt-list and determines that www.srv2.net is in the list, therefore subsequent HTTPS sessions should be decrypted by the proxy. In steps 5-10, MITM 125 signals TLS-AGT1 123www.srv2.net to respond "true" to the query in the domain-name-decrypt-list, thus the associated HTTPS session will be decrypted by the proxy.

[0129] refer to Figure 5BIn step 5-11, TLS-AGT1 123 sends signals to the TCP proxies TCP-AGT1 121 and TCP-AGT2 122 respectively, to forward all intra-proxy packets with the flow identifier "Flow-5678" to TLS-AGT1 123 and TLS-AGT2 124 respectively, so that the proxies can decrypt subsequent HTTPS sessions. In step 5-12, TLS-AGT1 123 sends a ClientHello message to TLS-AGT2 124. Upon receiving the ClientHello message, TLS-AGT2 124 calculates and records the flow identifier value "Flow-5678" and the initial default intra-proxy packet forwarding action locally, which is to forward the packet directly to TLS-AGT1 123. In step 5-13, TLS-AGT2 124 sends a ClientHello message to TCP-AGT2 122, which then forwards the ClientHello message to the destination SRV2 132. In steps 5-14, SRV2 132 responds with a ServerHello message, which is intercepted by TCP-AGT2 122. TCP-AGT2 122 sends the ServerHello message to TLS-AGT2 124, TLS-AGT2 124 sends the ServerHello message to TLS-AGT1 123, TLS-AGT1 123 sends the ServerHello message to TCP-AGT1 121, and TCP-AGT1 121 sends the ServerHello message to HOST1 110.

[0130] In steps 5-15 to 5-21, TLS tunnels can be established between TLS-AGT2 124 and SRV2 132, and between TLS-AGT1 123 and HOST1 110. In this embodiment, TLS-AGT2 124 can deceive HOST1 110, making it appear to SRV2 132 as both an IP-addressable endpoint and a remote endpoint of the TLS tunnel between HOST1 110 and SRV2 132, directly interacting with HOST1 110; and similarly, TLS-AGT1 123 can deceive SRV2 132, making it appear to HOST1 110 as both an IP-addressable endpoint and a remote endpoint of the TLS tunnel between HOST1 110 and SRV2 132, directly interacting with SRV2 132. Neither HOST1 110 nor SRV2 132 will be aware that they are actually interacting with the proxy components TLS-AGT1 123 and TLS-AGT2 124. For simplicity, steps 5-15 through 5-21 described below may use a self-signed certificate; however, in common practice, the server certificate may not be self-signed (applications often consider self-signed certificates a security risk), but rather signed by the certificate authority that created the server certificate; and the certificate of the certificate authority used to sign the server certificate, along with the server certificate, will be included in the Certificate message to form a chain of trust. In this respect, these assumptions, simplifications, and associated specifications are not intended to be restrictive.

[0131] In steps 5-15, SRV2 132 can send a Certificate message containing the server certificate of SRV2 132, which can be intercepted by TCP-AGT2 122, which can then forward the Certificate message to TLS-AGT2 124. For simplicity, the server certificate can be self-signed, and any agent handling a self-signed certificate (e.g., a web browser on host 110, TLS agents 123 and 124, MITM 125) may not reject them or otherwise request intervention from other agents or users. Further assuming that, although in practice, implementations might extract the server name (www.srv2.net) from the server certificate and compare it to the SNI value, or otherwise apply logic to the server name for this session (since the server name contained in the Certificate is reliable), such as having MITM check if the server name is in the domain-name-decrypt-list, these steps will not be described here for simplicity. This does not limit the scope of this disclosure.

[0132] Upon receiving the Certificate message, TLS-AGT2 124 can establish a TLS tunnel with SRV2 132 while simultaneously spoofing HOST1 110 (by using HOST1 110's IP address as the source IP address in the IP header of the packets generated by TLS-AGT2 124), with TCP-AGT2 122 acting as an intermediary. In steps 5-16, TLS-AGT2 124 and SRV2 132 can establish the TLS tunnel. In one of many embodiments, the following sub-steps can be used to establish a TLS tunnel: SRV2 132 can send a ServerKeyExchange message to TLS-AGT2 124; SRV2 132 can send a ServerHelloDone message to TLS-AGT2 124; TLS-AGT2 124 can send a ClientKeyExchange message to SRV2 132; TLS-AGT2 124 can send a ChangeCipherSpec message to SRV2 132; TLS-AGT2 124 can send a Finished message to SRV2 132; SRV2 132 can send a ChangeCipherSpec message to TLS-AGT2 124; and SRV2 132 can send a Finished message to TLS-AGT2 124 (message sequence details are not included). Figure 5B (as shown in the image).

[0133] Subsequently, a TLS tunnel can be established between TLS-AGT1 123 and HOST1 110. To do this, TLS-AGT1 123 deceives SRV2 132; that is, HOST1 110 believes it is interacting directly with SRV2 132 to establish a TLS tunnel, but is actually interacting with TLS-AGT1 123. However, first, the proxy needs to generate a new server certificate for SRV2 132. TLS-AGT1 123 uses this new certificate to establish a TLS tunnel with HOST1 110, which is standard operation for SSL / TLS proxies. (The server certificate provided by SRV2 132 may not be easily copied and reused; one reason is that the private key known only to SRV2 132 is associated with the server certificate it uses to decrypt and encrypt messages. Without this key, TLS-AGT1 123 may not be able to establish a TLS tunnel with HOST1 1110 when using SRV2 132's server certificate.)

[0134] In step 5-17, TLS-AGT2 124 may send a copy of the server certificate to MITM 125. In step 5-18, MITM 125 sends the server certificate to the Certificate Authority (CA) 126 and requests a new certificate to forge the SRV2 132 server certificate. In step 5-19, CA 126 sends the new forged server certificate and other necessary information (e.g., the certificate's private key) to MITM 125. In step 5-20, MITM 125 sends the forged server certificate and associated information, along with instructions used to establish a TLS channel with HOST1 110, to TLS-AGT1 123. In step 5-21, in a process similar to step 5-16, TLS-AGT1 123 continues to establish a TLS tunnel with HOST1 110 while spoofing SRV2 132 (by using the IP address of SRV2 132 as the source IP address in the IP header of the packet generated by TLS-AGT1 123, and by using the spoofed server certificate generated by CA126), with TCP-AGT1 121 acting as the mediator.

[0135] Now, HOST1 110 initiates an HTTP session with SRV2 132. All HTTP messages will be sent through two TLS tunnels, mediated by a proxy. (See reference) Figure 5C In step 5-22, HOST1 110 sends an HTTP request message with the request line “GET https: / / www.srv2.net / path1 / resource1 HTTP / 1.1” to the TLS tunnel, which encrypts the request when entering the tunnel and decrypts the HTTP request message when leaving the tunnel, at which point it is received by TLS-AGT1123 (where TCP-AGT1 121 acts as an intermediary).

[0136] In step 5-23, TLS-AGT1 123 extracts the URI https: / / www.srv2.net / path1 / resource1 from the (plaintext) HTTP request message and sends it to MITM 125. Recall that in Figure 5AIn step 5-2, MITM 125 stores a list of URIs, the “URI-decrypt-list,” for comparison with the URIs used in the HTTPS session, as can be done in a cybersecurity application, a privacy application, a law enforcement eavesdropping application, or other applications with logic that operates on the URI values ​​of the HTTPS session. MITM 125 compares the URI https: / / www.srv2.net / path1 / resource1 with entries in the URI-decrypt-list. If a match or sufficient correspondence exists, MITM 125 can signal to the higher-level application using the efficient SSL / TLS proxy (…). Figure 5C (Not shown in the image). The higher-level application can then execute additional logic. For example, a cybersecurity application or law enforcement eavesdropping application can signal MITM 125 to record and capture decrypted packets constituting the HTTPS session for subsequent use by a network analysis application that can assess the severity of the threat posed by communication between HOST1 110 and the URI https: / / www.srv2.net / path1 / resource1. Therefore, the remainder of the session will allow all decrypted packets to pass through MITM 125. Accordingly, in step 5-24a, MITM 125 signals TLS-AGT1 123 to send in-proxy packets to MITM 125; and in step 5-24b, MITM 125 signals TLS-AGT2 124 to send in-proxy packets to MITM 125. In step 5-25, TLS-AGT1 123 sends a (plaintext) HTTP request message to MITM 125, which can then use an efficient proxy to apply logic to the packets according to the higher-level application. In steps 5-26, MITM 125 sends the HTTP request message to TLS-AGT2 124, which then forwards the message into the TLS tunnel. The (encrypted) message then traverses the tunnel via TCP-AGT2 122 and exits at the destination endpoint SRV2 132. In steps 5-27, SRV2 132 generates a response to the HTTP request and forwards it into the tunnel toward HOST1 110 via TCP-AGT2 122, TLS-AGT2 124, MITM 125, TLS-AGT1 123, and TCP-AGT1 121. In steps 5-28, the HTTPS session can be terminated by disconnecting the TCP connection between HOST1 110 and SRV1 132, which is transparently mediated by the proxied TCP-AGT1 121 and TCP-AGT2 122, using a typical TCP signaling sequence (e.g., FIN, ACK alternating).

[0137] Figure 6 It shows something similar to Figures 5A-5C Another embodiment, where the session's URI does not match any element in the URI-decrypt-list, thus the rest of the session does not pass through MITM 125, provides a degree of efficiency. (See reference) Figure 6 Except that the URI is https: / / www.srv2.net / path2 / resource2 instead of https: / / www.srv2.net / path1 / resource1, steps 6-1 to 6-21 are the same as... Figures 5A-5B Steps 5-1 to 5-21 are the same. In step 6-22, HOST1 110 sends an HTTP request message with the request line “GET https: / / www.srv2.net / path2 / resource2HTTP / 1.1” to a TLS tunnel. The TLS tunnel encrypts the request when entering the tunnel and decrypts the HTTP request message when leaving the tunnel, at which point it is received by TLS-AGT1 123 (where TCP-AGT1 121 acts as an intermediary).

[0138] In step 6-23, TLS-AGT1 123 extracts the URI https: / / www.srv2.net / path2 / resource2 from the (plaintext) HTTP request message and sends it to MITM 125. Recall that in Figure 5A Step 5-2, which corresponds to Figure 6In step 6-2, MITM 125 stores a list of URIs, “URI-decrypt-list,” to compare with the URIs used in the HTTPS session, as can be done in a network security application, a privacy-preserving application, or other applications with logic that operates on the URI values ​​of the HTTPS session. MITM 125 compares the URI https: / / www.srv2.net / path2 / resource2 with the entries in the URI-decrypt-list. MITM 125 determines that no match or sufficient correspondence exists; therefore, in step 6-24a, MITM 125 signals TLS-AGT1 123 to send in-proxy packets directly to TLS-AGT2 124 (i.e., bypassing MITM 125, since the higher-level application using the proxy is not interested in handling this session). Similarly, in step 6-24b, MITM 125 signals TLS-AGT2 124 to send in-proxy packets directly to TLS-AGT1 123 (i.e., bypassing MITM 125, since the higher-level application using the proxy is not interested in handling this session). In step 6-25, TLS-AGT1 123 sends the HTTP request message directly to TLS-AGT2 124 (bypassing MITM 125); then TLS-AGT2 124 sends the HTTP request message into a TLS tunnel toward SRV2 132; the message then traverses the tunnel via TCP-AGT2 122 and exits the tunnel at the destination endpoint SRV2 132. In step 6-26, SRV2 132 generates a response to the HTTP request and sends it toward HOST1 110 via TCP-AGT2 122, TLS-AGT2 124, TLS-AGT1 123, and TCP-AGT1 121 (again bypassing MITM 125). In steps 6-27, the HTTPS session can be terminated by disconnecting the TCP connection between HOST1 110 and SRV1 132 using a typical TCP signal sequence (e.g., FIN, ACK alternately), which is transparently mediated by the proxy's TCP-AGT1 121 and TCP-AGT2 122.

[0139] Regarding the above Figures 4A-4B , Figures 5A-5C and Figure 6 Variations exist that can broaden the scope of this disclosure. Specifically in... Figure 4A , Figure 5A and Figure 6In steps 4-1, 5-1, and 6-1, a "domain-name-decrypt-list" containing domain names is created. This list is ultimately used to signal the efficient agent to potentially decrypt packets in the session if the session's domain name matches a domain name in the "domain-name-decrypt-list." Alternatively or supplemented, a "domain-name-do-not-decrypt-list" can be used, which signals the efficient agent not to decrypt packets in the session if the session's domain name matches a domain name in this list. This may be more relevant to privacy applications where certain communications should remain encrypted during transmission. Alternatively, both types of lists can be used simultaneously, with one list taking precedence over the other.

[0140] above Figure 5A Another variation is that when a match is found between the URI in the URI-decrypt-list and the session's URI, MITM can signal the termination of the session, for example, to prevent the transmission of sensitive information. This can be achieved, for example, by generating a TCP RST signal and sending it to HOST1 110 or SRV2 132 or both to terminate the TCP connection.

[0141] Figures 4A-4B Another variation uses a list of IP addresses, known as an "IP-address-decrypt-list," to determine whether to decrypt a given TLS-protected communication. (See reference) Figure 4AIn step 4-1, the list manager 128 generates an IP-address-decrypt-list containing IP addresses. List generation can be achieved through a user interface that accepts IP addresses as input, by resolving domain names using DNS, by using IP addresses provided by a threat intelligence provider through a subscription service, or by using privacy protection data and policies, etc. In step 4-2, the list manager LST-MGR 128 transmits the IP-address-decrypt-list to MITM 125. Steps 4-3 through 4-8 are the same as above (although in step 4-8, the extraction of the SNI value contained in the ClientHello message can be omitted). In step 4-9, TLS-AGT1 123 extracts the source IP address and / or destination IP address from the header of the IP packet containing the ClientHello message, and then sends a query to MITM 125 to check if the IP address is in the IP-address-decrypt-list. MITM 125 searches the IP-address-decrypt-list and determines that the IP address is not in the list, therefore the session should not be decrypted. In steps 4-10, MITM 125 responds to the query with "false," signaling to TLS-AGT1 123 that the IP address is not in the IP-address-decrypt-list, therefore the associated HTTPS session should not be decrypted by the proxy. (See reference) Figure 4B Steps 4-11 to 4-19 are performed as described above, that is, session bypass proxy decryption.

[0142] As a variant immediately following the above variation, if in Figure 4A In steps 4-9, MITM 125 searches the IP-address-decrypt-list and, if the IP address is found in the list, the session will be decrypted. In this case, the process is similar to... Figures 5A-5C Proceed through steps 5-10 to 5-28.

[0143] The functions and steps described herein may be embodied in computer-usable data or computer-executable instructions, such as those in one or more program modules, which are executed by one or more computers or other devices used to perform the functions described herein. Typically, program modules contain routines, programs, objects, components, data structures, etc., which perform specific tasks or implement specific abstract data types when executed by one or more processors in a computer or other data processing device. Computer-executable instructions may be stored on computer-readable media such as hard disks, optical disks, removable storage media, solid-state storage, RAM, etc. It should be understood that the functions of program modules can be combined and allocated as needed. Furthermore, functions may be wholly or partially embodied in firmware or hardware equivalents, such as integrated circuits, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), etc. Specific data structures may be used to more efficiently implement one or more aspects of this disclosure, and such data structures are considered to be within the scope of the computer-executable instructions and computer-usable data described herein.

[0144] Although not essential, those skilled in the art will understand that the various aspects described herein can be embodied as a method, system, apparatus, or one or more computer-readable media storing computer-executable instructions. Therefore, the aspects can take the form of a completely hardware embodiment, a completely software embodiment, a completely firmware embodiment, or an embodiment combining software, hardware, and firmware aspects in any combination.

[0145] As described herein, various methods and actions can operate on one or more computing devices and networks. Functionality can be distributed in any way, or it can reside in a single computing device (e.g., a server, client computer, etc.).

[0146] Various aspects of this disclosure have been described with reference to their exemplary embodiments. Many other embodiments, modifications, and variations within the scope and spirit of the appended claims will arise from reading this disclosure. For example, those skilled in the art will understand that the steps illustrated in the exemplary drawings may be performed in a different order than those listed, and that one or more steps illustrated may be optional. Any and all features of the appended claims may be combined or rearranged in any possible manner.

Claims

1. A method for selectively decrypting SSL / TLS communication, comprising: A computing device determines a list indicating multiple encrypted communication streams, wherein for each of the multiple encrypted communication streams, the list indicates: Identification data associated with their respective encrypted communication streams, and To perform one or more corresponding actions on each of the respective encrypted communication streams; The computing device receives one or more first data packets that initiate the first encrypted communication stream; The computing device determines, based on first stream identifier data corresponding to the one or more first data packets, that the list indicates the first encrypted communication stream; The computing device receives one or more second data packets; Based on determining that the one or more second data packets are part of the first encrypted communication stream initiated by the one or more first data packets, and based on determining that the list indicates the first encrypted communication stream, the one or more second data packets are decrypted; Perform a corresponding action among one or more corresponding actions associated with a matching encrypted communication stream on one or more decrypted second data packets, wherein performing the corresponding action includes recording the decrypted data packets for subsequent analysis; After performing the corresponding action, re-encrypt one or more of the decrypted second data packets; as well as Send each of the one or more re-encrypted second data packets to its intended destination.

2. The method according to claim 1, wherein, Performing the corresponding action on one or more decrypted second data packets includes: Capture at least a portion of one or more decrypted second data packets; Re-encrypt one or more second data packets that have been decrypted; and Each of the one or more re-encrypted second data packets is transmitted to its intended destination.

3. The method according to claim 1, wherein, Performing the corresponding action on one or more decrypted second data packets includes: Process at least a portion of one or more decrypted second data packets; Discard one or more decrypted second data packets.

4. The method according to claim 1, further comprising: The computing device receives a second list from the security application, the second list including one or more of the following items: Network address Domain name, or Uniform Resource Identifier (URI) Determining the list includes determining first identification data for at least one stream based on the second list.

5. The method according to claim 1, further comprising: The computing device receives a second list from one or more network threat intelligence providers, the second list comprising one or more of the following: Network address Domain name, or Uniform Resource Identifier (URI) Determining the list includes determining first identification data for at least one stream based on the second list.

6. The method according to claim 1, further comprising: The computing device receives a second list from the privacy-preserving application, the second list including one or more of the following: Network address Domain name, or Uniform Resource Identifier (URI) Determining the list includes determining first identification data for at least one stream based on the second list.

7. The method according to claim 1, further comprising: The computing device receives a second list from the law enforcement application, the second list including one or more of the following: Network address Domain name, or Uniform Resource Identifier (URI) Determining the list includes determining first identification data for at least one stream based on the second list.

8. The method according to claim 1, further comprising: The computing device, based on the determination that there is no indication of a second encrypted communication stream in the list, forwards multiple data packets associated with the second encrypted communication stream to their intended destinations, wherein the multiple data packets are not decrypted before the forwarding.

9. The method according to claim 1, further comprising: The computing device receives a second list containing one or more of the following: One or more first network addresses, One or more first domain names, or One or more First Uniform Resource Identifier (URI); The computing device receives a third list containing one or more of the following: One or more second network addresses, One or more second domain names, or One or more URIs; and Assign a first priority to the second list and a second priority to the third list, wherein the first priority is different from the second priority; And the list is determined based on the second list, the third list, the first priority, and the second priority.

10. The method according to claim 1, further comprising: Based on determining whether the list indicates a second encrypted communication stream, perform an action on one or more data packets of the second encrypted communication stream that is different from the action in the list.

11. The method according to claim 10, wherein, Performing the corresponding action on one or more decrypted second data packets includes one or more of the following: Record one or more of the second data packets; Terminate the first encrypted communication stream; or Discard at least one of the one or more second data packets.

12. The method according to claim 1, wherein, At least one of the one or more corresponding actions includes a decryption action.

13. The method according to claim 1, in, The list is determined to include identified domain names, and Determining that the list indicates the first encrypted communication stream includes determining that the list indicates the domain name.

14. A computing device comprising: One or more processors; as well as A memory storing instructions that, when executed by the one or more processors, cause the computing device to: Determine a list indicating multiple encrypted communication streams, wherein for each of the multiple encrypted communication streams, the list indicates: Identification data associated with their respective encrypted communication streams, and To perform one or more corresponding actions on each of the respective encrypted communication streams; Receive one or more first data packets that initiate the first encrypted communication stream; Based on the first stream identifier data corresponding to the one or more first data packets, it is determined that the list indicates the first encrypted communication stream; Receive one or more second data packets; Based on determining that the one or more second data packets are part of the first encrypted communication stream initiated by the one or more first data packets, and based on determining that the list indicates the first encrypted communication stream, the one or more second data packets are decrypted; Perform a corresponding action among one or more corresponding actions associated with a matching encrypted communication stream on one or more decrypted second data packets, wherein performing the corresponding action includes recording the decrypted data packets for subsequent analysis; After performing the corresponding action, re-encrypt one or more of the decrypted second data packets; as well as Send each of the one or more re-encrypted second data packets to its intended destination.

15. The computing device according to claim 14, wherein, When executed by the one or more processors, the instructions cause the computing device to perform the corresponding action on the decrypted one or more second data packets by causing the computing device to perform the following actions: Capture at least a portion of one or more decrypted second data packets; Re-encrypt one or more second data packets that have been decrypted; as well as Each of the one or more re-encrypted second data packets is transmitted to its intended destination.

16. The computing device according to claim 14, wherein, When executed by the one or more processors, the instructions cause the computing device to perform the corresponding action on the decrypted one or more second data packets by causing the computing device to perform the following actions: Process at least a portion of one or more decrypted second data packets; Discard one or more decrypted second data packets.

17. The computing device of claim 14, wherein the instructions, when executed by the one or more processors, further cause the computing device to: Receive a second list from the security application, the second list including one or more of the following: Network address Domain name, or Uniform Resource Identifier (URI) in, When executed by the one or more processors, the instructions further prompt the computing device to determine the list by causing the computing device to determine first identification data for at least one stream based on the second list.

18. The computing device of claim 14, wherein the instructions, when executed by the one or more processors, further cause the computing device to: Receive a second list from one or more cyber threat intelligence providers, the second list including one or more of the following: Network address Domain name, or Uniform Resource Identifier (URI) in, When executed by the one or more processors, the instructions further prompt the computing device to determine the list by causing the computing device to determine first identification data for at least one stream based on the second list.

19. The computing device of claim 14, wherein the instructions, when executed by the one or more processors, further cause the computing device to: From the privacy protection application, receive a second list, which includes one or more of the following items: Network address Domain name, or Uniform Resource Identifier (URI) in, When executed by the one or more processors, the instructions further prompt the computing device to determine the list by causing the computing device to determine first identification data for at least one stream based on the second list.

20. The computing device of claim 14, wherein the instructions, when executed by the one or more processors, further cause the computing device to: From the law enforcement application, a second list is received, which includes one or more of the following items: Network address Domain name, or Uniform Resource Identifier (URI) in, When executed by the one or more processors, the instructions further prompt the computing device to determine the list by causing the computing device to determine first identification data for at least one stream based on the second list.

21. The computing device of claim 14, wherein the instructions, when executed by the one or more processors, further cause the computing device to: Based on the determination that no second encrypted communication stream is indicated in the list, multiple data packets associated with the second encrypted communication stream are forwarded to their intended destinations, wherein the multiple data packets are not decrypted before the forwarding.

22. The computing device of claim 14, wherein the instructions, when executed by the one or more processors, further cause the computing device to: Receive a second list containing one or more of the following: One or more first network addresses, One or more first domain names, or One or more First Uniform Resource Identifier (URI); Receive a third list containing one or more of the following: One or more second network addresses, One or more second domain names, or One or more URIs; and Assign a first priority to the second list and a second priority to the third list, wherein the first priority is different from the second priority; and wherein, When executed by the one or more processors, the instruction causes the computing device to determine the list based on the second list, the third list, the first priority, and the second priority.

23. The computing device of claim 14, wherein the instructions, when executed by the one or more processors, further cause the computing device to: Based on determining whether the list indicates a second encrypted communication stream, an action different from the action in the list is performed on one or more third data packets of the second encrypted communication stream.

24. The computing device according to claim 14, wherein, When executed by the one or more processors, the instructions cause the computing device to perform the corresponding action on the decrypted one or more second data packets by causing the computing device to perform the following actions: Record one or more of the second data packets; Terminate the first encrypted communication stream; or Discard at least one of the one or more second data packets.

25. The computing device according to claim 14, wherein, At least one of the one or more corresponding actions includes a decryption action.

26. The computing device according to claim 14, in, When executed by the one or more processors, the instructions prompt the computing device to determine the list by causing the computing device to recognize the domain name, and When the instruction is executed by the one or more processors, it causes the computing device to determine that the list indicates the first encrypted communication stream by causing the computing device to determine that the list indicates the domain name.

27. One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors of a computing device, cause the computing device to: Determine a list indicating multiple encrypted communication streams, wherein for each of the multiple encrypted communication streams, the list indicates: Identification data associated with their respective encrypted communication streams, and One or more corresponding actions to be performed on each of the respective encrypted communication streams; Receive one or more first data packets that initiate the first encrypted communication stream; Based on the first stream identifier data corresponding to the one or more first data packets, it is determined that the list indicates the first encrypted communication stream; Receive one or more second data packets; Based on determining that the one or more second data packets are part of the first encrypted communication stream initiated by the one or more first data packets, and based on determining that the list indicates the first encrypted communication stream, the one or more second data packets are decrypted; Perform a corresponding action among one or more corresponding actions associated with a matching encrypted communication stream on one or more decrypted second data packets, wherein performing the corresponding action includes recording the decrypted data packets for subsequent analysis; After performing the corresponding action, re-encrypt one or more of the decrypted second data packets; as well as Send each of the one or more re-encrypted second data packets to its intended destination.

28. The non-transitory computer-readable medium according to claim 27, wherein, When executed by the one or more processors, the instructions cause the computing device to perform the corresponding action on the decrypted one or more second data packets by causing the computing device to perform the following actions: Capture at least a portion of one or more decrypted second data packets; Re-encrypt one or more second data packets that have been decrypted; as well as Each of the one or more re-encrypted second data packets is transmitted to its intended destination.

29. The non-transitory computer-readable medium according to claim 27, wherein, When executed by the one or more processors, the instructions cause the computing device to perform the corresponding action on the decrypted one or more second data packets by causing the computing device to perform the following actions: Process at least a portion of one or more decrypted second data packets; and Discard one or more decrypted second data packets.

30. The non-transitory computer-readable medium of claim 27, wherein the instructions, when executed by the one or more processors, further cause the computing device to: Receive a second list from the security application, the second list including one or more of the following: Network address Domain name, or Uniform Resource Identifier (URI) in, When executed by the one or more processors, the instructions further prompt the computing device to determine the list by causing the computing device to determine first identification data for at least one stream based on the second list.

31. The non-transitory computer-readable medium of claim 27, wherein the instructions, when executed by the one or more processors, further cause the computing device to: Receive a second list from one or more cyber threat intelligence providers, the second list including one or more of the following: Network address Domain name, or Uniform Resource Identifier (URI) in, When executed by the one or more processors, the instructions further prompt the computing device to determine the list by causing the computing device to determine first identification data for at least one stream based on the second list.

32. The non-transitory computer-readable medium of claim 27, wherein the instructions, when executed by the one or more processors, further cause the computing device to: From the privacy protection application, receive a second list, which includes one or more of the following items: Network address Domain name, or Uniform Resource Identifier (URI) in, When executed by the one or more processors, the instructions further prompt the computing device to determine the list by causing the computing device to determine first identification data for at least one stream based on the second list.

33. The non-transitory computer-readable medium of claim 27, wherein the instructions, when executed by the one or more processors, further cause the computing device to: Receive a second list from the law enforcement application, the second list including one or more of the following: Network address Domain name, or Uniform Resource Identifier (URI) in, When executed by the one or more processors, the instructions further prompt the computing device to determine the list by causing the computing device to determine first identification data for at least one stream based on the second list.

34. The non-transitory computer-readable medium of claim 27, wherein the instructions, when executed by the one or more processors, further cause the computing device to: Based on the determination that no second encrypted communication stream is indicated in the list, multiple data packets associated with the second encrypted communication stream are forwarded to their intended destinations, wherein the multiple data packets are not decrypted before the forwarding.

35. The non-transitory computer-readable medium of claim 27, wherein the instructions, when executed by the one or more processors, further cause the computing device to: Receive a second list containing one or more of the following: One or more first network addresses, One or more first domain names, or One or more First Uniform Resource Identifier (URI); Receive a third list containing one or more of the following: One or more second network addresses, One or more second domain names, or One or more URIs; and Assign a first priority to the second list and a second priority to the third list, wherein the first priority is different from the second priority, and wherein, When executed by the one or more processors, the instruction causes the computing device to determine the list based on the second list, the third list, the first priority, and the second priority.

36. The non-transitory computer-readable medium of claim 27, wherein the instructions, when executed by the one or more processors, further cause the computing device to: Based on determining whether the list indicates a second encrypted communication stream, an action different from the action in the list is performed on one or more third data packets of the second encrypted communication stream.

37. The non-transitory computer-readable medium according to claim 27, wherein, When executed by the one or more processors, the instructions cause the computing device to perform the corresponding action on the decrypted one or more second data packets by causing the computing device to perform the following actions: Record one or more of the second data packets; Terminate the first encrypted communication stream; or Discard at least one of the one or more second data packets.

38. The non-transitory computer-readable medium according to claim 27, wherein, At least one of the one or more corresponding actions includes a decryption action.

39. The non-transitory computer-readable medium according to claim 27, in, When executed by the one or more processors, the instructions prompt the computing device to determine the list by causing the computing device to recognize the domain name, and When the instruction is executed by the one or more processors, it causes the computing device to determine that the list indicates the first encrypted communication stream by causing the computing device to determine that the list indicates the domain name.

40. One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors of a computing device, cause the computing device to: Determine a list indicating multiple encrypted communication streams, wherein for each of the multiple encrypted communication streams, the list indicates: Identification data associated with their respective encrypted communication streams, and One or more corresponding actions to be performed on each of the respective encrypted communication streams; Receive one or more first data packets that initiate the first encrypted communication stream; Determine the first stream identification data associated with the one or more first data packets; The determined first-order identifier data is compared with the identifier data in the list; Based on the comparison, determine the encrypted communication stream that matches the first encrypted communication stream among the plurality of encrypted communication streams indicated in the list; Decrypt one or more second data packets of the first encrypted communication stream initiated by the one or more first data packets; Execute the corresponding action in one or more corresponding actions; After performing the corresponding action, re-encrypt one or more of the decrypted second data packets; as well as Send each of the one or more re-encrypted second data packets to its intended destination.

41. The non-transitory computer-readable medium of claim 40, wherein the instructions, when executed by the one or more processors, further cause the computing device to: Receive a second list from the security application, the second list including one or more of the following: Network address Domain name, or Uniform Resource Identifier (URI) in, When executed by the one or more processors, the instructions cause the computing device to determine the list by causing the computing device to determine first identification data for at least one stream based on the second list.

42. The non-transitory computer-readable medium of claim 40, wherein the instructions, when executed by the one or more processors, further cause the computing device to: Receive a second list from one or more cyber threat intelligence providers, the second list including one or more of the following: Network address Domain name, or Uniform Resource Identifier (URI) in, When executed by the one or more processors, the instructions cause the computing device to determine the list by causing the computing device to determine first identification data for at least one stream based on the second list.

43. The non-transitory computer-readable medium of claim 40, wherein the instructions, when executed by the one or more processors, further cause the computing device to: From the privacy protection application, receive a second list, which includes one or more of the following items: One or more network addresses, Domain name, or Uniform Resource Identifier (URI) in, When executed by the one or more processors, the instructions cause the computing device to determine the list by causing the computing device to determine first identification data for at least one stream based on the second list.

44. The non-transitory computer-readable medium of claim 40, wherein the instructions, when executed by the one or more processors, further cause the computing device to: From the law enforcement application, a second list is received, which includes one or more of the following items: One or more network addresses, Domain name, or Uniform Resource Identifier (URI) in, When executed by the one or more processors, the instructions cause the computing device to determine the list by causing the computing device to determine first identification data for at least one stream based on the second list.

45. The non-transitory computer-readable medium of claim 40, wherein the instructions, when executed by the one or more processors, further cause the computing device to: Based on the determination that the second stream identifier data used for the second encrypted communication stream does not correspond to the identifier data in the list, multiple data packets associated with the second encrypted communication stream are forwarded to their intended destinations, wherein the multiple data packets are not decrypted before the forwarding.

46. ​​The non-transitory computer-readable medium of claim 40, wherein the instructions, when executed by the one or more processors, further cause the computing device to: Receive a second list containing one or more of the following: One or more first network addresses, One or more first domain names, or One or more Uniform Resource Identifiers (URIs); Receive a third list containing one or more of the following: One or more second network addresses, One or more second domain names, or One or more URIs; and Assign a first priority to the second list and a second priority to the third list, wherein the first priority is different from the second priority. in, The instructions, when executed by the one or more processors, are configured to cause the computing device to determine the list based on the second list, the third list, the first priority, and the second priority.

47. The non-transitory computer-readable medium of claim 40, wherein the instructions, when executed by the one or more processors, cause the computing device to: Based on a comparison of the second stream identifier data associated with one or more third data packets of the second encrypted communication stream and the identifier data in the list, an action different from the action in the list is performed on one or more fourth data packets of the second encrypted communication stream.

48. The non-transitory computer-readable medium according to claim 47, wherein, The action that differs from the actions in the list includes terminating the second encrypted communication stream.

49. The non-transitory computer-readable medium according to claim 47, wherein, The action that differs from the actions in the list includes recording data packets associated with the second encrypted communication stream.

50. One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors of a computing device, cause the computing device to: Receive a first list containing one or more of the following: The corresponding encrypted communication stream will be decrypted from one or more first network addresses, or The corresponding encrypted communication stream will be decrypted from one or more first domain names; Receive a second list containing one or more of the following: The corresponding encrypted communication stream will not be decrypted by one or more second network addresses, or The corresponding encrypted communication stream will not be decrypted by one or more second domain names; Assign a first priority to the first list and a second priority to the second list; Based on the first priority and the second priority, a sorted list indicating a plurality of encrypted communication streams is determined, wherein for each of the plurality of encrypted communication streams, the sorted list indicates: Identification data associated with their respective encrypted communication streams, and One or more corresponding actions to be performed on each of the respective encrypted communication streams; Receive one or more first data packets of the first encrypted communication stream that initiates the plurality of encrypted communication streams; Determine the first stream identification data associated with the one or more first data packets; Based on comparing the determined first stream identifier data with the identifier data in the sorting list, the encrypted communication stream that matches the first encrypted communication stream among the plurality of encrypted communication streams indicated in the sorting list is determined; Based on the first list, decrypt one or more second data packets of the first encrypted communication stream; Perform the corresponding action among one or more corresponding actions associated with the matched encrypted communication stream on the one or more second data packets of the first encrypted communication stream; After performing the corresponding action, the one or more second data packets of the first encrypted communication stream are re-encrypted; as well as Each of the one or more second data packets is transmitted to its intended destination.

51. The non-transitory computer-readable medium of claim 50, wherein the instructions, when executed by the one or more processors, cause the computing device to transmit each data packet by causing the computing device to perform the following operations: Based on the second list, the one or more second data packets are forwarded to their intended destinations, wherein the one or more second data packets are not decrypted prior to the forwarding.

52. The non-transitory computer-readable medium of claim 50, wherein the instructions, when executed by the one or more processors, further cause the computing device to: Based on the second list, perform the second corresponding action among one or more corresponding actions associated with the matching encrypted communication stream on the one or more second data packets.

53. One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors of a computing device, cause the computing device to: A list of stored identification data and at least one corresponding action to be performed on the encrypted communication stream associated with each corresponding identification data; Receive one or more data packets that initiate at least one encrypted communication stream; Identifying and associating with the one or more data packets that initiate the at least one encrypted communication stream; The identified stream identifier data is compared with the list of identifier data; Based on the comparison of the identified stream identifier data with the list of identifier data resulting in a match with the data in the list, the data packet of the encrypted communication stream associated with the match of the data in the list is decrypted, and the corresponding action is performed on the data packet of the encrypted communication stream associated with the match of the data in the list; as well as After performing the corresponding action, the data packets of the decrypted communication stream associated with the match of the data in the list are re-encrypted, and the data packets of the re-encrypted communication stream are transmitted to their intended destination.

54. The non-transitory computer-readable medium according to claim 53, wherein, When the instructions are executed by the one or more processors, they further cause the computing device to: Receive a list of one or more network addresses and / or domain names from a security application; and The list of identification data is created based on the received list of one or more network addresses and / or domain names.

55. The non-transitory computer-readable medium according to claim 53, wherein, When the instructions are executed by the one or more processors, they further cause the computing device to: Receive at least one list of network addresses and / or domain names from one or more network threat intelligence providers through a subscription service; and The list of identification data is created based on at least one list of the received network addresses and / or domain names.

56. The non-transitory computer-readable medium according to claim 53, wherein, When the instructions are executed by the one or more processors, they further cause the computing device to: Receive a list of one or more network addresses and / or domain names from a privacy-protected application; and The list of identification data is created based on the received list of one or more network addresses and / or domain names.

57. The non-transitory computer-readable medium according to claim 53, wherein, When the instructions are executed by the one or more processors, they further cause the computing device to: Receive a list of one or more network addresses and / or domain names from a law enforcement application; and The list of identification data is created based on the received list of one or more network addresses and / or domain names.

58. The non-transitory computer-readable medium according to claim 53, wherein, When the instructions are executed by the one or more processors, they further cause the computing device to: Multiple data packets associated with the encrypted communication stream are forwarded to their intended destinations, wherein the multiple data packets are not decrypted before forwarding.

59. The non-transitory computer-readable medium according to claim 53, wherein, When the instructions are executed by the one or more processors, they further cause the computing device to: Receive a first list of one or more network addresses and / or domain names, wherein the first list of one or more network addresses and / or domain names indicates the network address and / or domain name whose corresponding encrypted communication stream will be decrypted; Receive a second list of one or more network addresses and / or domain names, wherein the second list of one or more network addresses and / or domain names indicates the network addresses and / or domain names whose corresponding encrypted communication streams will not be decrypted; Assign a first priority to the first list of one or more network addresses and / or domain names, and assign a second priority to the second list of one or more network addresses and / or domain names, wherein the first priority is different from the second priority; as well as Based on the first priority and the second priority, a sorted list of identification data is created from the first list of one or more network addresses and / or domain names and the second list of one or more network addresses and / or domain names.

60. The non-transitory computer-readable medium according to claim 53, in, The list of identification data indicates a specific action to be performed on the identification data included in the list; Specifically, the comparison between the identified flow identifier data and the list of identifier data determines that the list of identifier data does not include the identified flow identifier data; and When executed by the one or more processors, the instructions cause the computing device to perform actions other than the specific actions indicated by the list of identified data, based on a comparison indicating a mismatch with the data in the list.

61. The non-transitory computer-readable medium of claim 60, wherein the action, in addition to the specific action indicated by the list of identifying data, includes terminating the associated encrypted communication stream.

62. The non-transitory computer-readable medium of claim 60, wherein the action, in addition to the specific action indicated by the list, further causes the computing device to: Record data packets associated with the linked encrypted communication stream for subsequent analysis; and The data packets associated with the encrypted communication stream are forwarded to their respective intended destinations.

Images