Method and system for encrypted SNI filtering for cybersecurity application

Abstract

To provide a packet filtering method, device and system for filtering packets having an encrypted host name according to one or more packet filtering rules, and a computer-readable medium.SOLUTION: A packet-filtering system receives one or more threat indicators, receives a plurality of packets including a cipher text including an encrypted Server Name Indication (eSNI) value, resolves a plaintext hostname using a plurality of techniques from the ciphertext including the encrypted Server Name Indication (eSNI) value. Once the plaintext hostname is resolved, the packet-filtering system uses the plaintext hostname to determine whether the packets are associated with one or more threat indicators. If the packet-filtering system determines that the packets are associated with one or more threat indicators, the packet-filtering system may apply a packet filtering operation associated with packet-filtering rules to the packets.SELECTED DRAWING: Figure 11

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Provisional Patent Application No. 16 / 928,083, filed July 14, 2020 (now U.S. Patent No. 10,924,456). This application is also related to continuations of U.S. Non-Provisional Patent Application No. 17 / 175,747, filed February 15, 2021, and U.S. Non-Provisional Patent Application No. 17 / 307,080, filed May 4, 2021. The contents of each of these prior applications are expressly incorporated herein by reference in their entirety.

[0002] FIELD OF THEINVENTION Aspects of the present disclosure described herein (hereinafter sometimes referred to as "the disclosure") generally relate to computer hardware, software, and network security. In particular, one or more aspects of the disclosure generally relate to cryptographically-based methods for detecting and detecting a Server Name Indication (SNI) (e.g., encrypted SNI, eSNI) value associated with cybersecurity applications. The present invention relates to computer hardware and software for efficient packet filtering of Transport Layer Security (TLS) handshake messages containing statements, and more generally to network communications policy enforcement applications. [Background technology]

[0003] As the information age advances, network security becomes increasingly important. Network threats / attacks can take many forms (e.g., fraudulent requests or data transfers, viruses, malware, floods of traffic designed to overwhelm resources (e.g., DDoS), etc.). Many of these threats use the Internet to access and attack computer resources and / or assets of a business or organization (hereafter referred to as an "enterprise"). For example, enterprise hosts such as desktop computers, mobile devices, on-premise or cloud enterprise application servers, public web servers, etc., may be directly connected (e.g., attached) to private networks (e.g., TCP / IP networks) owned and / or operated and controlled by an enterprise such as a commercial business, government, nation, etc. These enterprise networks are in turn directly connected to the Internet such that the enterprise hosts may, for example, access other publicly addressed, Internet-connected hosts (e.g., public web servers, application servers, etc.). However, in some cases, the enterprise hosts may be accessing Internet-connected hosts or Internet hosts that are malicious in nature, for example, when the operators / users of the enterprise hosts are socially engineered to click on phishing email links that communicate with the malicious Internet hosts. In other cases, enterprise hosts may communicate with Internet hosts in violation of the enterprise's network communications policies.

[0004] An enterprise may, for example, install network packet filtering devices at the boundary between the enterprise network and the Internet (e.g., at or near one or more Internet access links) that can inspect host-to-host communications (in the form of L2 / L3 packets in transit) that cross the boundary. Thus, these enterprises may attempt to protect their networks from malicious actors or otherwise enforce network communication policies. These packet filtering devices may determine whether a communication is malicious in nature or otherwise violates an enterprise communication policy, and if so, may enforce a policy (e.g., blocking the communication by dropping the associated IP packets) that protects the enterprise network from the threat or violation. Enterprises may also use such network devices to enforce enterprise communication policies, for example, by controlling and / or monitoring access to specific Internet hosts. One approach to enforcing such policies is for the network packet filtering devices to detect instances of domain names (e.g., fully qualified domain names (FQDNs)), such as malicious-adware-site.net, associated with packet filtering rules in the policies. The rule may be to inspect or filter in-flight packets of a communication for a domain name. If a match is found between the packet and the rule, the network packet filtering device may drop the packet. The common HTTP protocol used to transport and mediate many web, e-commerce, social media, etc. communications often includes such domain names of Internet hosts in the HTTP message. Filtering in-flight packets for domain names included in the HTTP message is a policy enforcement technique. Similarly, other application layer protocols (e.g., DNS, SMTP, SIP, etc.) may include domain names that may be used during policy enforcement. Enterprise communication policies may also include privacy protection & preservation (P3) policies, which may be defined by the enterprise itself or by an external entity with regulatory or compliance authority over the enterprise, e.g., HIPAA, PCI DSS, etc. Enterprise communications policies also govern law enforcement (LE) applications. This may include support for various applications, for example lawful interception.

[0005] Network traffic in transit may be secured through encryption, for example, using the Transport Layer Security (TLS) protocol. The TLS Handshake Protocol may be used first to establish a secure encrypted connection or tunnel between two hosts connected by a network (e.g., a TCP / IP network). The TLS Record Protocol may be used to securely transfer application layer data, including communications through the tunnel. When an HTTP session is secured by TLS, this combination is labeled "HTTPS" and is generally considered to be an extension of HTTP. The application layer of an in-transit HTTPS packet contains an encrypted HTTP message (encapsulated in a TLS Record Protocol packet). The cleartext HTTP message, and therefore any domain name, contained in an in-transit HTTPS packet cannot be read by an observer. This secures the HTTP session from malicious actors that may be eavesdropping, but also prevents non-malicious / legitimate packet filtering devices and associated applications from reading any domain name contained in the HTTP message. This may prevent enterprises from enforcing their enterprise communication policies and protecting their enterprise networks.

[0006] However, the TLS Handshake Protocol ClientHello message may include a (cleartext) domain or hostname associated with the application (e.g., HTTP) session to be secured / encrypted in the Server Name Indication (SNI) extension (RFC6066) of the ClientHello message. Enterprise packet filtering devices and associated applications, as well as eavesdroppers, may be able to eavesdrop on the cleartext SN of the ClientHello message included in the in-flight packet. By inspecting the SNI field, one may continue to read and possibly act on the domain name associated with a session secured by TLS. However, to make TLS even more secure, one or more extensions to TLS have been developed that support encryption of SNI values ​​while in transit. Those skilled in the art will generally recognize this extension and related technology as "ESNI." The primary purpose of ESNI is to reduce the risk of domain name theft by malicious actors. However, enterprises that protect their networks and enforce their communications policies by reading and possibly acting on clear-text domain names contained in the SNI extension of in-transit packets will not be able to do so when ESNI is used because the domain names are encrypted.

[0007] Therefore, enterprises need a way to use plain / cleartext domain names to protect their networks and enforce communication policies when enterprise hosts use ESNI when establishing communications secured by TLS. Summary of the Invention

[0008] The following presents a simplified summary to provide a basic understanding of some aspects of the disclosure. It is not intended to identify key or critical elements of the disclosure or to delineate the scope of the disclosure. The following summary merely presents some concepts of the disclosure in a simplified form as a prelude to the description that follows.

[0009] The methods, devices, systems, and / or computer-readable media disclosed herein describe protecting enterprise networks from threats (e.g., Internet threats) and enforcing enterprise communication policies in some cases where, for example, a domain name included in a packet is encrypted in transit (e.g., an encrypted Server Name Indication (eSNI) extension in a TLS Handshake Protocol message, an encrypted TLS protocol message, etc.). A cybersecurity application may detect an encrypted hostname in one or more packets. Based on detecting the encrypted hostname (e.g., a domain name), the cybersecurity application may decrypt a cleartext hostname (e.g., a domain name) that corresponds to the encrypted hostname. The cybersecurity application may use the cleartext hostname to determine whether the cleartext hostname is associated with any communication policies. For example, a cybersecurity application protecting a network from threats identified in a report (e.g., a cyber threat intelligence report) may use the cleartext hostname to determine whether the cleartext hostname is associated with one or more threat indicators. If the cleartext hostname is associated with one or more threat indicators, the cybersecurity application may apply one or more packet filtering rules to one or more packets. By decrypting clear hostnames from encrypted hostnames, cybersecurity applications can, for example, protect enterprise networks from threats (e.g., Internet threats) and from privacy violations such as malicious theft, enforce enterprise communication policies, and / or assist with law enforcement.

[0010] There are many possible variations of the above process, some of which are detailed below in the Detailed Description section. [Brief description of the drawings]

[0011] The present invention is illustrated by way of example and not by way of limitation in the accompanying figures, in which: Like reference numbers indicate like elements. [Figure 1] 1 illustrates an example environment of a threat protection and policy enforcement system for TLS secured communications and associated enterprise networks in accordance with one or more aspects of the present disclosure. [Diagram 2] 1 illustrates an example efficient eSNI packet filtering gateway for performing cybersecurity applications, in accordance with one or more aspects of the present disclosure. [Diagram 3] 1 shows an exemplary eSNI Domain Name Correspondence List (EDCL) that is used by cybersecurity applications to determine the correspondence between eSNI ciphertext and plaintext domain names. [Figure 4A] 1 shows a flow diagram of an exemplary process for creating, distributing, and maintaining an EDCL. [Figure 4B] 1 shows a flow diagram of an exemplary process for creating, distributing, and maintaining an EDCL. [Diagram 5] 1 illustrates a flow diagram of an exemplary process for creating, distributing, and maintaining policies comprised of packet filtering rules derived from a CTI database. [Figure 6] FIG. 1 shows a flow diagram of an example process for creating, distributing, and maintaining a DNS-ESNI Set data structure that includes elements that are DNS-registered domain names that support eSNI. [Figure 7] 1 illustrates a flow diagram of an exemplary process for creating, distributing, and maintaining EDCL, CTI derived policies, and DNS-ESNI Set data structures. [Figure 8A] 1 illustrates a method for configuring and operating an efficient eSNI gateway according to one or more embodiments described herein. [Figure 8B]1 illustrates a method for configuring and operating an efficient eSNI gateway according to one or more embodiments described herein. [Figure 9] 1 illustrates a methodology for configuring and operating an efficient eSNI gateway according to one or more aspects described herein. [Figure 10] 1 illustrates a method for configuring and operating an efficient eSNI gateway in accordance with one or more embodiments described herein. [Figure 11] 1 illustrates one embodiment of a process for determining whether encrypted network traffic is associated with one or more threats. [Figure 12] 1 illustrates one embodiment of a process for enforcing a policy using encrypted hostnames, according to one or more embodiments described herein. [Figure 13] 1 illustrates one embodiment of a method for storing packets according to one or more embodiments described herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] In the following description of various embodiments of the present disclosure, reference is made to the accompanying drawings, which form a part of this specification and which show by way of example various embodiments in which aspects of the present disclosure may be implemented. It is to be understood that other embodiments may be utilized and structural and functional changes may be made without departing from the scope of the present disclosure. Furthermore, reference is made to specific applications, protocols, and embodiments in which aspects of the present disclosure may be implemented. It is to be understood that other applications, protocols, and embodiments may be utilized and structural and functional changes may be made without departing from the scope of the present disclosure.

[0013] In the following description, various connections between elements are discussed. These connections are general and, unless otherwise specified, may be direct or indirect, wired or wireless, physical or logical (virtual / software-defined). Similarly, network elements such as hosts and appliances may be physical or virtual. In this regard, the present specification is not intended to be limiting.

[0014] This disclosure describes techniques for cybersecurity applications to act on domain names included in in-flight packets constituting TLS-secured communications where the domain names may be encrypted. Some network cybersecurity applications enforce TCP / IP communication policies consisting of packet filtering rules that include cleartext domain names as rule matching criteria. The policies cannot be enforced when the domain names included in the in-flight packets are, for example, encrypted Server Name Indication (SNI) extension field values ​​in TLS ClientHello messages. Additionally or alternatively, cybersecurity applications may selectively enforce the use of, for example, encrypted SNI to thwart the theft associated with cleartext domain names.

[0015] Throughout this specification, the term "domain name" may be used interchangeably with the network domain identified by the domain name. The context determines whether "domain name" refers to the actual name or identity of the domain, or whether "domain name" refers to the domain itself. This interchangeability of terms will be understood by those skilled in the art. Also, "domain name" may be used interchangeably with host name, fully qualified domain name (FQDN), etc., with the exact meaning defined by the context. For example, a domain name observed in a structured field of an L2 / L3 packet in transit may be an FQDN. Similarly, a domain name that is a CTI indicator may also be an FQDN.

[0016] As used herein, encrypted server name indication ("eSNI") may generally refer to the techniques and logic associated with encrypted SNI, rather than to a specific protocol, implementation, or standard. Additionally, an "eSNI ciphertext" may generally refer to one or more encrypted portions (e.g., fields, values, etc.) of a message (e.g., a TLS ClientHello message) associated with establishing a secure communications channel between two or more parties. The one or more encrypted portions may include an SNI value and other portions of a message (e.g., a ClientHello message), including, for example, the entire message (e.g., a ClientHello message). Applicant believes that an eSNI protocol is currently being developed by the Internet Engineering Task Force (IETF) and that the eSNI protocol may include any portion of a message (e.g., a TLS ClientHello message) associated with establishing a secure communications channel between two or more parties. will be encrypted has not yet been finalized and / or classified as part of the standard. Those skilled in the art will recognize that the processes, methods, techniques, devices, apparatus, and / or systems described herein may be applied to detect threats (e.g., Internet threats), protect enterprise networks, mitigate privacy violations, enforce enterprise communication policies, and / or assist law enforcement in communications that include encrypted Server Name Indication (eSNI), regardless of what portions of such communications are encrypted.

[0017] Aspects of the present disclosure relate to methods, devices, systems, and / or computer-readable media for protecting enterprise networks from Internet threats and enforcing enterprise communication policies, for example, when a domain name included in an in-flight packet of a communication is encrypted. An application, such as a cybersecurity application, operating an in-line and / or in-flight packet filtering device may detect when a domain name is encrypted using eSNI. Based on detecting the use of eSNI, the application and / or in-flight packet filtering device may determine a cleartext domain name that corresponds to the eSNI ciphertext and enforce communication policies associated with the cleartext domain name.

[0018] Aspects of the present disclosure may also describe methods, devices, systems, and / or computer-readable media for protecting enterprise networks from threats such as malicious theft and enforcing enterprise communication policies, for example, when a domain name included in a communication is not encrypted. A cybersecurity application operating an in-line and / or in-transit packet filtering device may detect when a domain name is encrypted without using eSNI. The cybersecurity application and / or in-transit packet filtering device may determine whether eSNI is supported by the associated domain. If eSNI is supported, the cybersecurity application operating an in-line and / or in-transit packet filtering device may enforce communication policies associated with transmitting cleartext domain names, for example, by forcing the communication to use eSNI (if available).

[0019] Identification of communications associated with Internet threats is available from a number of cyber threat intelligence (CTI) provider organizations. The CTI reports may leverage a database of reports. These CTI reports may include indicators, or threat indicators, or Indicators-of-Compromise (IoCs), which are unique identifiers of Internet hosts or Internet-hosted resources (e.g., services, application instances, etc.) associated with malicious activity. CTIs may include Internet network addresses (in the form of IP addresses, 5-tuples (L3 host IP addresses, L4 ports, and / or associated L3 protocol types), hostnames / domain names, URIs, etc.) of resources that may be controlled / manipulated by a threat actor or otherwise associated with malicious activity. CTI indicators may also include identifiers of certificates and associated certificate authorities used to secure some TCP / IP communications (e.g., X.509 certificates used by the TLS protocol to secure sessions over HTTP). In addition to threat indicators, CTI reports may include additional information related to the threat, such as threat types, threat attributes and threat actors, characteristic behaviors, attack targets, geographic and geopolitical information, etc.

[0020] The present disclosure may describe methods, devices, systems, and / or computer-readable media for deriving packet filtering rules from domain name indicators received in a CTI. The present disclosure may also describe methods, devices, systems, and / or computer-readable media for enforcing the derived packet filtering rules on packets including TLS-secured communications (e.g., HTTPS communications). In this regard, an enterprise may receive a CTI indicator via a subscription to a cyber threat intelligence provider (CTIP). The enterprise may protect the enterprise network of the enterprise from Internet threats by creating a policy comprised of packet filtering rules derived from the CTI indicators, configuring a packet filtering device with the policy, and enforcing the policy on in-transit packets traversing the network boundary.

[0021] The use of eSNI to encrypt domain names in TLS-secured communications may be achieved through the joint participation of the communicating hosts and the Internet's Domain Name System (DNS). That is, a first host (e.g., an HTTP client, such as a web browser application running on an enterprise host) and a second host (e.g., an enterprise host, such as a web application server hosting a domain named www.web-domain-X.com) may encrypt domain names in TLS-secured communications. A first host (e.g., an HTTP server connected to the Internet) may support eSNI to establish TLS-secured communications between the two hosts. A second host (e.g., a web server) may publish a public key in the second host's associated DNS entry (e.g., www.web-domain-X.com). The client may use the public key to, for example, encrypt the domain name (e.g., www.web-domain-X.com) and other information (e.g., a ClientHello message, data and / or information within the ClientHello message, etc.) included in the SNI extension. Before communicating with the second host (e.g., www.web-domain-X.com), the first host (e.g., an HTTP client) may issue a query to the DNS to obtain (e.g., retrieve and decrypt) the IP address (e.g., 12.34.56.78 for www.web-domain-X.com) and the second host's eSNI public key. A first host (e.g., an HTTP client) may establish a TCP connection to a well-known port at 12.34.56.78 (e.g., port 443 (HTTPS)). The first host may use a public key to encrypt the FQDN (e.g., www.web-domain-X.com) included in the SNI extension. In some embodiments, the public key may be used to encrypt other data in addition to the FQDN, such as a ClientHello message and / or data and information included in the ClientHello message. After encrypting the FQDN and any additional data with the public key, the first host may insert the resulting eSNI ciphertext into a message, such as a ClientHello message. The message (e.g., a ClientHello message) may be encapsulated in a TCP packet having a destination port of 443. The TCP packet may be encapsulated in an IP packet having a destination IP address of 12.34.56.78. The IP packet may be sent (e.g., transmitted) over the connection (e.g., a TCP connection) to a second host (e.g., a web server).Upon receiving the ClientHello message, the second host (e.g., a web server) may decrypt the ciphertext using a private (e.g., secret) key associated with the public key to obtain (e.g., determine) the cleartext domain (e.g., www.web-domain-X.com) of the second host (e.g., domain) with which the first host (e.g., a web browser) wishes to communicate.

[0022] An application operating a packet filtering device may derive (e.g., determine) a plaintext domain name from the eSNI ciphertext by correlating the L3 destination IP address of in-flight packets (e.g., including ClientHello messages) with eSNI-related information. For example, a cybersecurity application operating a packet filtering device may correlate a cyber threat intelligence (CTI) database of domain name indicators with TCP / IP communications to identify potential threat communications and / or determine how to handle (e.g., block / drop or allow / forward) identified potential threat communications. The CTI database may include multiple domain names, and the contents of the CTI database may be dynamic. That is, new entries (e.g., domain names and any associated information) may be added to the CTI database, and existing entries may be continually deleted from the CTI database. This disclosure describes packet filtering techniques that may be computationally efficient such that in-flight packets are not dropped due to overflowing buffers and network security is not compromised due to latency. The applications and / or in-line packet filtering devices described herein may filter in-flight L2 / L3 packets on a packet-by-packet basis. That is, the L2 / L3 transparent device filters each in-flight packet in the order of arrival (e.g., FIFO queuing) or applies packet filtering rules to each in-flight packet and determines the disposition / action (e.g., block / drop, allow / forward, etc.) of each packet before filtering the next packet. It will be appreciated that a message such as a ClientHello message may be fragmented over several packets. The packet-by-packet processing described may be applied to messages, such as ClientHello messages, that are fragmented across multiple packets.

[0023] An eSNI Domain Name Correspondence List (EDCL) may be generated from the CTI database of domain names. The EDCL may be a data structure. The data structure may be a data organization, management, and / or storage format that allows for efficient access and / or modification. The data structure may be a collection of data values, relationships between these data values, and / or functions or operations that may be applied to the data. In some embodiments, the data structure may be a 2D table that includes at least two columns labeled {IP-address, cti-esni-domain-name-list} that are uniquely indexed by IP address. In other embodiments, the data structure may be a database. To generate the EDCL, each domain name (e.g., a fully qualified domain name (FQDN)) in the CTI database may be queried to a DNS. The DNS query may determine at least one of the IP address of the domain name and whether the associated domain supports eSNI. Determining whether the domain supports eSNI may include querying a resource record that includes an eSNI public key for encryption. If the associated domain supports eSNI, an entry (e.g., a row) in the EDCL may be created and / or updated by placing the IP address in the IP address column and the domain name in the cti-esni-domain-name-list column. Due to virtual domain technology where multiple domain names may resolve to the same IP address, there may be multiple domain names or lists of domain names associated with each IP address in the EDCL. For illustrative purposes, for the examples of this overview, it is assumed that there is only one domain name in the cti-esni-domain-name-list associated with a (unique) IP address in the EDCL. To quickly process in-transit packets so as to avoid buffer overflows and packet drops, and to minimize packet transmission latency, the EDCL may be organized as an efficient data structure, such as a hash table, to support fast lookups indexed by IP address that check for the existence of an EDCL entry and return a list of domain names associated with the IP address.

[0024] When the (in-line) packet filtering device inspects an in-transit packet including a ClientHello message with eSNI ciphertext, the packet filtering device may extract the destination IP address from the L3 packet and determine the cleartext domain name corresponding to the eSNI ciphertext by searching for the destination IP address in the EDCL. If the destination IP address security is not found in the EDCL, the cybersecurity application logic may determine to allow (e.g., forward) the packet toward the packet's destination since there is no CTI-based threat associated with the packet. If the destination IP address is found in the EDCL, the associated domain name may be the cleartext domain name corresponding to the eSNI ciphertext. To determine how to process the packet, the cybersecurity application may search one or more network security policies including multiple in-transit packet filtering rules (derived from the CTI database) for a rule having packet matching criteria corresponding to the cleartext domain name. The match rule may indicate a packet disposition (e.g., allow / forward / pass or block / drop / reject). The match rule may also indicate additional (network protection) actions for the packet, such as log, capture, mirror / redirect, forward to proxy, spoof tcp-rst, or a packet transformation function (PTF).

[0025] Multiple domain names may be associated with a single IP address in the EDCL. For example, domain hosting services often host many domains on a single IP address. Some of these many domains may contain privacy protection data. The domains may be in a CTI database or other cybersecurity-related database, such as a CTI database, law enforcement database, enterprise use policy database, etc. In addition, some of these domains may support eSNI. The plaintext domain name corresponding to the eSNI ciphertext may not be clearly determined from the associated IP address in the EDCL. The cybersecurity application may select among several different actions to disambiguate the plaintext domain name and / or otherwise mitigate potential threats. These actions may be based on the extended EDCL information, additional efficient data structures, TLS messages, etc. For example, the cybersecurity application may send a TCP RST to the client that tears down the TCP connection and terminates the TLS handshake session, send a TLS message to the client that terminates the TLS handshake session (e.g., a TLS alert protocol message with a "handshake failure" (code 40) alert), send a TLS message to the client that causes the client to use a TLS version that does not support eSNI (e.g., TLS v.1.2), send a TLS message to the client that causes the client to send the plaintext SNI instead of the encrypted SNI, etc.

[0026] An application operating a packet filtering device may inspect an in-flight packet containing a ClientHello message, determine that eSNI is being used, and determine that the packet's L3 destination IP address is within the EDCL. The eSNI ciphertext may correspond to a (plaintext) domain name of interest, such as one contained in a CTI database. There are several actions the application may take to disambiguate the plaintext domain name and / or otherwise mitigate the threat. For example, the application may drop packets containing the ClientHello message, spoof the intended host of the ClientHello message, or become a (transparent) proxy.

[0027] Additionally or alternatively, the security application may route the ClientHello message to a (transparent) TLS Man-In-The-Middle (MITM) proxy. The MITM proxy function may decrypt the application session secured by TLS, inspect the session in the clear, re-encrypt the session, and forward the TLS secured session to the destination of the session. Although the MITM proxy function may not be able to decrypt the eSNI ciphertext, the MITM proxy function may inspect (e.g., inspect) the decrypted application session and extract the cleartext domain name corresponding to the eSNI ciphertext from the contents of the session. For example, an HTTPS session may be decrypted by the MITM proxy function to expose the cleartext HTTP session. In this regard, an HTTP method request, such as GET, POST, PUT, etc., may include a domain name. The security application may extract the cleartext domain name from the cleartext and filter the cleartext domain name through any policies enforced by the packet filtering device.

[0028] In another embodiment, the security application may operate or otherwise access a system, DNS-QUERY-TRACKER, that may be used to disambiguate cleartext domain names corresponding to eSNI values. The DNS-QUERY-TRACKER system may monitor DNS queries originating from enterprise hosts that may also originate TLS sessions passing through a packet filtering device. The DNS-QUERY-TRACKER system may store, for example, in a table (e.g., a hash table) and / or database, records of data associated with any DNS queries for domain names that support eSNI. Each record may include the IP address of the host that originated the DNS query, the domain name, the resolved IP address of the domain name, and / or the time of the query. The DNS-QUERY-TRACKER system may monitor DNS queries originating from enterprise hosts that may also originate TLS sessions passing through a packet filtering device. The DNS-QUERY-TRACKER may provide an interface to tables and / or databases that store records with function calls that accept an IP address as input and return one or more records that correspond to the input IP address. In some embodiments, the DNS-QUERY-TRACKER may support DNS queries over HTTPS (DoH) (e.g., RFC8484) and / or DNS over Transport Layer Security (DoT) (e.g., RFC7858), among others. It may be configured to allow for the use of encrypted DNS protocols, which may encrypt DNS communications, such as DNS query requests and / or responses, i.e., the configuration may be such that the DNS-QUERY-TRACKER system may have access to the plaintext and / or cleartext of DoH and DoT communications.

[0029] Prior to initiating a TLS-secured session (e.g., HTTPS communication) associated with a domain name, the enterprise host may issue a DNS query to resolve the domain name to an IP address and obtain (e.g., retrieve, acquire) a public key (e.g., eSNI public key) for the domain. As described above, the public key may be used to encrypt the domain name and other data and / or information included in the ClientHello message. With the public key (e.g., eSNI public key), the DNS-QUERY-TRACKER system may insert a record of the public key (e.g., eSNI public key) into a table and / or database of the DNS-QUERY-TRACKER system. The packet filtering device may receive an L3 packet including a ClientHello message with eSNI ciphertext. A security application running on the packet filtering device may extract a destination IP address from the packet and query DNS-QUERY-TRACKER for one or more records indexed by the destination IP address. The query may be time-limited; i.e., the record may have been created and / or updated within a predefined time of receiving the L3 packet. Records that are time-correlated with the ClientHello message and / or match the originating host IP address with the source IP address of the L3 packet may include the cleartext domain name associated with the eSNI ciphertext. The security application may filter the cleartext domain name through any policies enforced by the packet filtering device. The DNS-QUERY-TRACKING systems and methods described above may be used in conjunction with, or as an alternative to, the EDCL-based systems and methods for estimating the cleartext domain name corresponding to the eSNI ciphertext.

[0030] In some instances, the EDCL may be generated from a database of domain names that may be associated with the application. For example, the database may be a collection of domain names for which law enforcement (LE) has authority to intercept, decrypt, and store the plaintext of associated communication sessions (e.g., HTTPS sessions) for a lawful intercept application. Because law enforcement may not have authority to intercept, decrypt, and / or store sessions that are not associated with a domain name, the EDCL may be generated from the lawful intercept database of domain names to determine whether the session may be associated with a plaintext domain name in the lawful intercept database. If the session is associated with a domain name in the lawful intercept database, the application may take appropriate action (e.g., intercept, decrypt, and store the plaintext of the associated communication).

[0031] In a Privacy Protection and Preservation (P3) application, the database may be a collection of domain names associated with encrypted communication sessions (e.g., HTTPS sessions) that should not be decrypted and stored in order to protect and preserve privacy. If a session secured by TLS uses eSNI, an EDCL may be generated from the P3 database of domain names to determine whether the session is associated with a cleartext domain name in the P3 database. If the domain name is If associated with a domain name in the P3 database, the application may take appropriate action to ensure that the session is not decrypted and / or stored.

[0032] In some embodiments, an enterprise may seek to enforce an eSNI usage policy that mitigates and / or prevents theft by malicious actors. eSNI usage policy enforcement may be used in conjunction with the EDCL-based eSNI security features and / or DNS-QUERY-TRACKER-based security features described above. In addition to having access to the EDCL, an application may have access to a data structure named DNS-ESNI that includes, for example, one or more elements of domain names registered in the DNS with associated domains that support eSNI. For example, an application operating a packet filtering device may detect a ClientHello message with an SNI value (e.g., a (cleartext) domain name) that is not in the CTI database but has an entry in the DNS-ESNI data structure. The domain name is being sent in the clear, even if the domain name can be sent as ciphertext. Additionally or alternatively, the application may query the DNS to decrypt the domain name and determine whether the domain supports eSNI. Based on the response to the query, the application may determine whether the domain name is an element or member of an abstract or actual DNS-ESNI data structure. If the application determines that the domain supports eSNI, the application may drop the packet containing the ClientHello message (with the cleartext domain name) and send a TLS message to the client that becomes a masquerading / transparent proxy to the host to which the ClientHello message is being sent and / or causes the client to use encrypted SNI instead of cleartext SNI.

[0033] In some embodiments, an enterprise may seek to enforce an eSNI usage policy that implements eSNI for TLS sessions. That is, enterprise hosts may access only domains that support eSNI. An application operating a packet filtering device may enforce such a policy, for example, by detecting a ClientHello message with an SNI value (e.g., a plaintext domain name that is not an element of DNS-ESNI) and sending a TLS message to the client that terminates the TLS handshake session and / or sending a TCP RST message to the client that terminates the associated TCP session. The filtering rules and / or enforcement policies described herein may find use in systems that perform rule-based network threat detection, for example, using techniques disclosed by the applicant in U.S. Patent Application No. 14 / 757,638, entitled "Rule-Based Network-Threat Detection for Encrypted Communications," filed December 23, 2015 (now U.S. Patent No. 9,917,856), which is incorporated herein by reference in its entirety.

[0034] FIG. 1 illustrates a system 100 of eSNI filtering for cybersecurity applications. The system 100 may include a network A 102 and a network B 104, which may be connected by one or more network links 106 that provide inter-network access and / or interconnection. The system 100 may also include one or more hosts. As used herein, a "host" (or "hosts") refers to any type of network device or node or computing device connected to a network, whose network interfaces are assigned L3 network addresses. The one or more hosts may be servers, desktop computers, laptop computers, tablet computers, and the like. The network interfaces may be computing devices and / or network devices, such as computers, mobile devices, smartphones, routers, gateways, proxies, firewalls, switches, access points, etc. In some embodiments, some computing devices may have network interfaces without a network address, such as PSG / ESNI G / W 120. A computing device without a network address may not be considered a host. A network interface without an assigned network address may be considered to be "transparent" with respect to the network level (e.g., L3 and / or L2).

[0035] Network A 102 may be one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), a Virtual Private Network (VPN), a Software-Defined Network (SDN), a WAN, ... Network B 104 may comprise one or more networks (e.g., a LAN, a WAN, a VPN, an SDN, or a combination thereof) that interface and / or interconnect Network A 102 with one or more other networks (not shown). For example, Network B 104 may comprise the Internet or a similar network, and / or portions thereof.

[0036] As shown in FIG. 1, network A 102 includes hosts 110, 112, and / or 114 and a packet security gateway (PSG ), and one or more packet filtering network gateway devices such as TLS clients, TLS tunnel terminations, etc. Hosts 110, 112, and / or 114 may be configured to function as TLS clients and / or TLS tunnel terminations. The PSGs may include eSNI-Gateway (ESNI-G / W) 120 functionality for processing in-transit packets associated with TLS-secured communications that may use eSNI. In some embodiments, eSNI gateway network devices (e.g., ESNI-G / W 120 or embedded PSGs in these eSNI gateway network devices) may not have L3 and / or L2 network addresses assigned to the network interfaces of these eSNI gateway network devices that input and / or output in-transit packets for which the eSNI gateway functions. The eSNI gateways (and embedded PSGs) may be L3 transparent.

[0037] Similarly, network B 104 may include or provide network access to hosts 130, 131, and / or 139. Hosts 130, 131, and / or 139 may be configured to function as TLS servers and / or TLS tunnel terminals. Hosts 130, 131, and / or 139 may host one or more domains and may register associated domain names in a DNS (e.g., DNS 160). Hosts 130, 131, and / or 139 may also associate eSNI support for the domain on the Internet DNS (e.g., create a resource record for the domain that includes an eSNI public key for encryption). Network B 104 may also include or provide network access to systems 140, 142, and / or 144. Systems 140, 142, and / or 144 may be collections of networked hosts configured to provide various services. For example, the CTIP 140 may be one or more CTI providers (CTIPs) that provide CTI reports to subscribers (such as the SPMS 150) that include network threat indicators (e.g., domain names). The LEI 142 and P3IP 144 may provide intelligence reports to subscribers (such as a Security Policy Management Server (SPMS) 150) that include network indicators (e.g., domain names). In addition to the application, other application intelligence providers (not shown) may also provide intelligence reports to subscribers that include network indicators in the form of domain names.

[0038] The security policy management server (SPMS) 150 may be a system that creates and distributes policies including one or more packet filtering rules. The one or more packet filtering rules may be derived from a CTI provided by the CTIP 140, from an LEI provided by the LEIP 142, from a P3I provided by the P3IP 144, etc. These policies may be distributed to subscribers such as the ESNI-G / W 120. The SPMS 150 may also be a system that creates and distributes data to subscribing eSNI gateways (e.g., the ESNI-G / W 120) that support eSNI gateway functionality. For example, the EDCL-SYS 152 may represent a module, device, system, or subsystem of the SPMS 150 that creates and distributes EDCLs derived from domain name indicators included in the CTI, LEI, P3I, etc., to the subscribing eSNI gateways ESNI-G / W 120. In another embodiment, CTI-POLICY-SYS 154 may be a module, device, system, or subsystem of SPMS 150 that creates policies including one or more packet filtering rules derived from CTI indicators (including domain name indicators). In yet another embodiment, DNS-ESNI-SYS 156 may represent a module, device, system, or subsystem of SPMS 150 that creates and distributes a set data structure (e.g., tables, databases, etc., and associated functions) that includes DNS registered domain names for domains that support eSNI. For example, law enforcement policy creation systems associated with law enforcement applications (e.g., LEI-POLICY-SYS (not shown)), privacy policy creation systems associated with P3 applications (e.g., P3I-POLICY-SYS (not shown)), and other policy creation systems may be similar to CTI-POLICY-SYS 154, but may differ in source and / or type of intelligence that may include domain name indicators.

[0039] Domain Name Server (DNS) 160 may be one or more computers that comprise the Internet Domain Name System (DNS). DNS 160 may be used by various hosts to resolve domain names to IP addresses. Additionally or alternatively, DNS 160 may be used to obtain (e.g., retrieve, acquire) cryptographic keys (e.g., public cryptographic keys) for use in creating the eSNI ciphertext included in the TLS ClientHello message.

[0040] ESNI-G / W 120 may be located at or near a network boundary interfacing between a first network (e.g., network A 102) and a second network (e.g., network B 104). For example, ESNI-G / W 120 may connect (e.g., interface) network 102, or one or more hosts located within network 102, with network 104, or one or more hosts located within network 102. As described above, network B 104 may include hosts 130, 131, and / or 139. Hosts 130, 131, and / or 139 may host one or more networked application servers and / or associated domains. The one or more application servers and / or associated domains may be connected to (or connected to) a network 104. The ESNI-G / W 120 may be inserted in-line on the network link 106 and may filter packets in-flight to enforce policies associated with domain names associated with TLS-secured communications. In some embodiments, the ESNI-G / W 120 may be a subcomponent or subfunction of a more general packet filtering gateway system, such as a packet security gateway (PSG), to enforce policies on all TCP / IP packet communications between hosts associated with network A 102 and hosts associated with network B 104. The PSG may be an interface between a protected network, such as network A 102, and an unprotected network connected to the protected network, such as network B 104. One or more PSGs may be located at one or more boundaries of a protected network and may filter (e.g., apply policies consisting of packet filtering rules) in-flight packets that cross one or more boundaries in either direction. As shown in Figure 1, a PSG may incorporate an ESNI-G / W 120. The ESNI-G / W 120 functionality of the PSG may be applied to one or more packets associated with a communication secured by TLS using eSNI.

[0041] Although not shown, it will be understood that additional network components may be present in FIG. 1. These network components may include devices such as network firewalls and associated network address translation (NAT) functions, proxies, etc. located at or near the network boundary that may modify packet header information. Altering the header information may affect the methods, devices, systems, and / or computer-readable media described herein. As described in more detail below, the systems, components, functions, data, etc. described in connection with CTI-based applications may be applied to other applications, such as law enforcement (LE) applications, privacy protection and preservation (P3) applications, etc. These applications (e.g., LE applications, P3 applications, etc.) may be substituted for and / or operated simultaneously with the CTI-based network protection applications. The methods, devices, systems, and / or computer-readable media described herein may be implemented in any suitable system that may determine a correspondence between eSNI ciphertext included in a TLS ClientHello message / packet in transit and a plaintext / cleartext domain name associated with the application and communication. Based on the determination of the correspondence between the eSNI ciphertext and the plaintext domain name, the system may process the packet according to packet filtering rules.

[0042] FIG. 2 illustrates one embodiment of an ESNI-G / W 120 for enforcing policies on communications between network A 102 and network B 104. The communications may be TLS secured communications with encrypted hostnames (e.g., encrypted SNI values ​​that may be included in eSNI ciphertext). The ESNI-G / W 120 may include a processor and main memory (CPU-w / MEM) 121 that may execute logic to configure and operate the ESNI-G / W 120, the network interface NTWK-I / F 127, and the management interface MGMT-I / F 129. The CPU-w / MEM 121 may execute logic to configure and operate the ESNI-G / W 120 according to one or more communication policy enforcement applications. These applications may include a TLS-secured ESNI-G / W 120, a network interface NTWK-I / F 127, and a management interface MGMT-I / F 129. The applications may be executed simultaneously and cooperatively / cooperatively. Additionally or alternatively, the processor and main memory (CPU-w / MEM) 121 may execute logic to configure and operate a collection of systems and services, such as PKT-FILTER 122, EDCL-SVC 123, DNS-ESNI-SVC 124, DNS-QUERY-TRACKER 125, and / or TLS-MITM-PROXY 126, that may support the operation of the ESNI-G / W 120 and its associated applications. These components may communicate using a BUS 128. The BUS 128 may be used to transfer data, including packets, between the components of the ESNI-G / W 120. The BUS 128 may provide a data communication channel between the components of the ESNI-G / W 120. In some embodiments, BUS 128 may be an on-chip silicon bus connecting processor logic (e.g., processor and main memory (CPU-w / MEM) 121) with on-chip cache memory, thereby providing fast and compact processing. Additionally or alternatively, BUS 128 may be a network connection (e.g., a TCP / IP network), such as network A 102 or network B 104. In further embodiments, BUS 128 may be an integrated / embedded device on a printed circuit board (PCB). BUS 128 may include a data bus, a parallel data cable connecting computers and / or peripherals, a serial optical cable connecting ports and / or interfaces of network switches and routers, an L2 / L3 switched network, an L3 routed network, etc., as well as any combination thereof. BUS 128 may be silicon, wired, wireless, physical, logical, virtual, software defined, etc.

[0043] The ESNI-G / W 120 may be in-line with the network link 106 that may interconnect the network A 102 and the network B 104 via the network interface port NTWK-I / F 127. In some embodiments, the network interface port NTWK-I / F 127 may be transparent in L3 and / or L2. That is, the network interface port NTWK-I / F 127 may not have an IP address and / or a MAC address assigned to these network interface ports. According to these examples, in-transit L2 / L3 packets may pass through the ESNI-G / W 120 without modifying the L2 / L3 packet headers. The in-transit packet processing logic of the ESNI-G / W 120 may provide time-efficient and memory-efficient packet processing that allows packet filtering at the peak packet transmission rate of the link 106, for example, without dropping packets due to internal buffer overflows caused by latency. In some examples, the management interface MGMT-I / F 129 may be assigned an L3 / IP address. The management interface MGMT-I / F 129 may enable the ESNI-G / W 120 to communicate with hosts that provide services such as the SPMS 150 and / or the DNS 160.

[0044] The PKT-FILTER 122 system may apply policies, including one or more packet filtering rules, to in-flight packets traversing the ESNI-G / W 120. The policies may be provided by a server and / or service, such as the SPMS 150. The packet filtering rules of the policies may be derived from indicators contained in various types of intelligence reports, e.g., CTI reports, LEI reports, P3I reports, etc. The PKT-FILTER 122 may be configured to simultaneously support one or more different cybersecurity applications, such as CTI-based network protection, lawful interception, privacy protection and preservation.

[0045] The EDCL-SVC 123 service may manage queries for information associated with one or more EDCLs. EDCLs are managed by the EDCL-SYS 152 (MGM The EDCL-SVC 123 may provide a query to the ESNI-G / W 120 (via the TI / F 129). The EDCL-SYS 152 may be part of the SPMS 150. The EDCL-SVC 123 may service queries from the ESNI-G / W 120. The EDCL-SVC 123 may receive one or more query requests from one or more applications running on the ESNI-G / W 120. The one or more query requests may be received via the BUS 128. The query requests may include an IP address. The EDCL-SVC 123 may transmit a query response to the application. The query response may include ESNI-related information associated with the IP address stored in one or more EDCLs managed by the EDCL-SVC 123.

[0046] The DNS-ESNI-SVC124 service may manage queries for eSNI support information associated with domain names that may be registered in the Internet DNS160. The EDCL-SVC123 may receive one or more query requests from one or more applications running on the ESNI-G / W120. The query requests may be received via the BUS128. The query requests may include a domain name. The EDCL-SVC123 may transmit a query response to the one or more applications. The query response may include information indicating whether the domain associated with the domain name supports eSNI. The DNS-ESNI-SVC124 may determine whether the domain name supports eSNI by determining whether the domain name is a member of a DNS-ESNI set managed by the DNS-ESNI-SVC. The DNS-ESNI set may be provided by the DNS-ESNI-SYS156 via the MGMT-I / F129, for example. The DNS-ESNI-SYS156 may be a component of the SPMS150. Additionally or alternatively, DNS-ESNI-SVC124 may determine whether the domain name supports eSNI by querying DNS160 to determine whether the domain name is associated with any resource records for eSNI support.

[0047] The DNS-QUERY-TRACKER 125 system may manage information associated with DNS queries that may have been issued by hosts connected to the network A 102. Additionally or alternatively, the DNS-QUERY-TRACKER 125 system may service queries for information associated with DNS queries that may have been issued by hosts connected to the network A 102. The DNS-QUERY-TRACKER 125 may observe DNS query requests and responses to resolve domain names to IP addresses. For each DNS query, the DNS-QUERY-TRACKER 125 may store a record for the query in an efficient data structure, such as a table (e.g., a hash table) or a database. The record may include (1) the IP address of the host that originated the DNS query, (2) the domain name, (3) the resolved IP address of the domain name, (4) the time of the query, and / or (5) additional information for managing and / or improving the system and / or service. For example, the additional information may include eSNI support information associated with the domain name. DNS-QUERY-TRACKER 125 may assist in disambiguating cleartext domain names that may correspond to the eSNI ciphertext. For example, an eSNI gateway application may process an in-flight packet that includes a ClientHello message that includes the eSNI ciphertext. The application may query EDCL-SVC 123 and determine that multiple domain names may correspond to the eSNI ciphertext. To disambiguate which of the multiple domain names may correspond to the eSNI ciphertext, the application may query DNS-QUERY-TRACKER 125 for records that correspond to the L3 source IP address and / or L3 destination IP address of the packet. To service the query, DNS-QUERY-TRACKER 125 queries DNS-QUERY-TRACKER 125 for one or more records where either the source IP address of the packet matches the originating host IP address of the record and / or the destination IP address of the packet matches the decrypted IP address of the record. The application may search a data structure (e.g., a table and / or a database) of the ER 125. Any such records may be included in a query response sent to the application. The application may then determine a cleartext domain name corresponding to the eSNI ciphertext from the latest record. Based on the determined cleartext domain name, the application may send the packet and the domain name to the PKT-FILTER 122 for filtering and processing.

[0048] The TLS-MITM-PROXY 126 (transparent) proxy system may be used by an eSNI gateway application to perform deeper inspection of packets and / or associated communications. For example, the TLS-MITM-PROXY 126 may decrypt TLS-secured communications, examine the plaintext of the TLS-secured communications, and re-encrypt the TLS-secured communications. An application may use this man-in-the-middle approach to determine a plaintext domain name that corresponds to an eSNI ciphertext associated with a TLS-secured communication. For example, an application may receive an in-flight packet that includes an encrypted hostname (e.g., a ClientHello message that includes eSNI ciphertext). To determine whether there is a correspondence between a plaintext domain name associated with the application and the eSNI ciphertext, the application may invoke EDCL-SVC 123 and / or DNS-QUERY-TRACKER 125. However, EDCL-SVC 123 and / or DNS-QUERY-TRACKER 125 may not determine a plaintext domain name that corresponds to an encrypted hostname (e.g., a domain name). In some embodiments, EDCL-SVC 123 and / or DNS-QUERY-TRACKER 125 may not be able to determine the cleartext domain name within a certain degree of certainty. The application may then forward the TLS-secured communication to TLS-MITM-PROXY 126. TLS-MITM-PROXY 126 may decrypt the TLS-secured communication to obtain (e.g., determine) the cleartext domain name corresponding to the eSNI ciphertext. As described in more detail below, one or more ESNI-G / W applications, such as LE applications and P3 applications, may use TLS-MITM-PROXY 126 to obtain the cleartext of a TLS-secured communication session.

[0049] FIG. 3 illustrates a representative embodiment of an eSNI Domain Name Correspondence List (EDCL) 300. The EDCL data structure may be represented as a two-dimensional table. The EDCL 300 may be used by an eSNI gateway (e.g., ESNI-G / W 120) to determine whether an encrypted hostname (e.g., eSNI ciphertext) corresponds to a cleartext domain name in a database of domain names associated with cybersecurity applications, such as CTI-based network protection, law enforcement (LE), privacy protection and preservation (P3), etc. The determination of whether an encrypted hostname (e.g., encrypted domain name) corresponds to one or more cleartext domain names in the database may be a factor in how the eSNI gateway (e.g., ESNI-G / W 120) processes an in-transit packet that includes an encrypted domain name (e.g., a ClientHello message with eSNI ciphertext). As discussed herein, the EDCL 300 may be used with one or more cybersecurity applications associated with CTI-based network protection, as well as one or more applications, such as law enforcement (LE) applications and / or privacy protection and preservation (P3) applications.

[0050] EDCL 300 may include multiple columns. A first column 301, labeled "IP-Address," may include one or more unique IP addresses that index each row and / or entry in the table. Each IP address in first column 301 may include an eSNI. The elements in second column 302 may correspond to DNS records (e.g., Internet DNS A (IPv4) or AAAA (IPv6)) for one or more domain names in the CTI database that are associated with the supporting domain. A second column 302, labeled "CTI-ESNI-Domain", may contain domain names in the CTI database that support eSNI. The elements in second column 302 are names of domains hosted at the corresponding IP addresses in first column 301. For example, the domain {pgorlzex.cn,x-advice.onln,bmb27.com} in the (311,302) element location of EDCL 300 may be hosted at IP address 40.07.25.13, as indicated by the (311,301) element location. For example, if the ESNI-G / W 120 detects an encrypted hostname (e.g., eSNI ciphertext in a ClientHello message) and the L3 destination IP address of the associated packet is 40.07.25.13, the EDCL 300 may indicate that one of the plaintext domain names {pgorlzex.cn, x-advice.onln, bmb27.com} may correspond to the encrypted hostname (e.g., eSNI ciphertext). There may be additional domains hosted at the same IP address 40.07.25.13 that have domain names that may correspond to the eSNI ciphertext. However, those domain names may not be listed in elements (311, 302) because they are either not in the CTI database or do not support eSNI.

[0051] The remaining columns in EDCL 300 are exemplary and may be used by ESNI-G / W 120 for decision support on how to process packets containing encrypted hostnames (e.g., ClientHello messages with eSNI ciphertext). A third column 303, labeled "#CTI-ESNI-Domains", may contain a count of domain names "CTI-ESNI-Domains" in the second column 302. For example, the three domain names represented in element (311,302) may define element (311,303) as 3. A fourth column 304, labeled "#CTI-Domains", may contain a count of domain names in the CTI database that are hosted at the corresponding IP addresses in the first column 301. For example, element (313,304) can be 15, meaning that 15 domain names in the CTI database are hosted at IP address 6203:7400:3340:8618:46ef (e.g., element (313,301)). Although 15 domain names may be hosted at IP address 6203:7400:3340:8618:46ef, there are 6 domains in the CTI database hosted at IP address 6203:7400:3340:8618:46ef that do not support eSNI. This can be shown in element (313,303), which can indicate the number of domain names that support eSNI at a given IP address. A fifth column 305, labeled "#Reverse-IP-Lookup-Domains," can include a count of all domains hosted by an IP address according to the reverse IP lookup service. In some embodiments, there may be additional columns in the EDCL 300 that the ESNI-G / W 120 may use for decision support.

[0052] As shown by the example illustrated in row 314, ESNI-G / W 120 may receive a communication having an encrypted hostname (e.g., a ClientHello message having an eSNI ciphertext). ESNI-G / W 120 may use a network address (e.g., source IP address, destination IP address, etc.) to determine with a high degree of certainty a plaintext domain name that corresponds to the received eSNI ciphertext. As shown, ESNI-G / W 120 may determine that the plaintext domain associated with the received eSNI ciphertext is toplipts.com. In this regard, ESNI-G / W 120 may query EDCL 300 using IP address 22.74.02.18 to determine a plaintext domain name that corresponds to the eSNI ciphertext. ESNI-G / W 120 logic may determine that #CTI-ESNI-Domain(314,303)=1 and #CTI-Domain(314,304)=2. )=1, and #Reverse-IP-Lookup-Domains(314,305)=1, so it may be determined that (314,302)=toplipts.com and the received encrypted hostname (e.g., eSNI ciphertext) corresponds to toplipts.com.

[0053] In another example, ESNI-G / W 120 may receive a communication with an encrypted hostname (e.g., a ClientHello message with eSNI ciphertext). ESNI-G / W 120 may determine that additional methods may be needed to determine cleartext domain names that correspond to the encrypted hostname using network addresses (e.g., source IP address, destination IP address, etc.). As shown in the example illustrated by line 312, ESNI-G / W 120 may query EDCL 300 using IP address 14.99.65.22 to determine one or more cleartext domain names that correspond to the encrypted hostname (e.g., eSNI ciphertext). The ESNI-G / W 120 logic may determine that the domain hosted at IP address 14.99.65.22 supports eSNI because #CTI-ESNI-Domains (312, 303) = 5, and #CTI-Domains (312, 304) = 5, and #Reverse-IP-Lookup-Domains (312, 305) = 20. Additionally, the ESNI-G / W 120 may determine that the cleartext domain name corresponding to the eSNI ciphertext is likely not in the CTI database. In this regard, the ESNI-G / W 120 may decide to use an additional method to determine the cleartext domain name corresponding to the encrypted hostname (e.g., eSNI ciphertext).

[0054] As shown by the example illustrated in row 310, ESNI-G / W 120 may receive a communication having an encrypted hostname (e.g., a ClientHello message having eSNI ciphertext). ESNI-G / W 120 may use the network address (e.g., source IP address, destination IP address, etc.) to determine that the communication may be malicious. ESNI-G / W 120 may query EDCL 300 using IP address 102.2.18.81 to determine one or more cleartext domain names associated with the encrypted hostname (e.g., eSNI ciphertext). The ESNI-G / W 120 logic may determine that the IP address was assigned to a malicious actor that has taken measures and actions to disrupt its Internet presence because #CTI-ESNI-Domains (310,303) = 8, and #CTI-Domains (310,304) = 8, and #Reverse-IP-Lookup-Domains (310,305) = 0. Based on this determination, the ESNI-G / W 120 may determine that the communication is most likely malicious.

[0055] As shown by the example illustrated in row 311, ESNI-G / W 120 may receive a communication having an encrypted hostname (e.g., a ClientHello message having an eSNI ciphertext). ESNI-G / W 120 may use the network address (e.g., source IP address, destination IP address, etc.) to determine that the communication may be malicious. ESNI-G / W 120 may query EDCL 300 using IP address 40.07.25.13 to determine one or more cleartext domain names associated with the encrypted hostname (e.g., the eSNI ciphertext). ESNI-G / W 120 logic may determine that the communication is directed to an IP address assigned to a content delivery and / or adware service operator that does not actively censor or monitor clients of that IP address because #CTI-ESNI-Domain(311,303)=3, and #CTI-Domain(311,304)=3, and #Reverse-IP-Lookup-Domain(311,305)=3. ESNI-G / W 120 may determine that the communication is most likely malicious.

[0056] 4A and 4B illustrate an example of a process 400 of a system (e.g., EDCL-SYS 152) that creates, distributes, and maintains an EDCL. In some embodiments, the system (e.g., EDCL-SYS 152) may be integrated with or comprise a subsystem of the SPMS 150 that creates, distributes, and maintains a policy of packet filtering rules derived from a CTI database and / or other intelligence databases. The CTI database may include multiple threat indicators, including multiple threat indicators in the form of domain names. Additionally, the CTI database may be continuously updated, for example, by a cyber threat intelligence provider (e.g., CTIP 140) that generates new threat intelligence reports and / or associated network threat indicators. CTI-derived policies and EDCLs may be created and / or managed by individual eSNI gateways. Additionally or alternatively, EDCLs and / or CTI-derived security policies may be created and / or managed by a centralized server, such as a CTIP.

[0057] In step 405, the system (e.g., EDCL-SYS 152) creates a database (e.g., CTI-FQDN-DB) by accessing a current CTI indicator database (e.g., CTI-INDICATOR-DB) of SPMS 150, extracting fully qualified domain names (FQDNs) from the current CTI indicator database (e.g., CTI-INDICATOR-DB), and inserting the FQDNs into the database (e.g., CTI-FQDN-DB). In step 410, the system may initialize an EDCL, which may be associated with metadata including creation time, SPMS identification information, CTI-INDICATOR-DB and CTI-FQDN-DB identifiable information, etc. Once the EDCL is initialized, the system may begin a looping or iterative process through each FQDN in the CTI-FQDN-DB to populate the EDCL.

[0058] In step 415, the system queries the DNS (e.g., the Internet DNS 160) to find a resource record (RR) for the current FQDN associated with the eSNI. In step 420, the system may determine whether the , it may determine whether the resource record indicates whether the associated domain supports eSNI. If the resource record indicates that the associated domain does not support eSNI, process 400 returns to step 415 to query the DNS for the next entry in the CTI-FQDN-DB. However, if the resource record indicates that the associated domain supports eSNI, process 400 proceeds to step 425, during which the system may query the DNS for domain records (e.g., resp. A and AAAA records) for the FQDN. The system may receive a response. The response may include an IPv4 IP address and / or an IPv6 IP address associated with the FQDN. In some embodiments, if both an A (IPv4) record and an AAAA (IPv6) record exist for the FQDN, step 425 may be repeated if the domain name has both an IPv4 IP address and an IPv6 IP address.

[0059] In step 430, the system may determine whether the IP address exists in the EDCL. For example, the system may search for a record / row / entry indexed by the IP address. If the entry does not exist, the system creates a new record in the EDCL in step 435. The entries may be indexed by the IP address.

[0060] After creating a new entry for the IP address or finding that an entry already exists, the system may append the FQDN to the list of FQDNs in the CTI-ESNI-Domain 302 field in step 440. In step 445, the system may increment the #CTI-ESNI-Domain 303 field to indicate the new IP address associated with the entry. In step 450, the system may determine whether there are more FQDNs to process in the CTI-FQDN-DB. If there are more FQDNs to process, process 400 returns to step 415 to repeat the process with the next FQDN in the CTI-FQDN-DB. If there are no more FQDNs, process 400 proceeds to step 455.

[0061] In step 455, the system may populate additional fields and / or columns in the EDCL. Additional fields and / or columns may be added to IP address 301, CTI-ESNI-Domain 302, and #CTI-ESNI-Domain 303. Continuing with the example discussed above with respect to FIG. 3, row 313 may be indexed by IP address 6203:7400:3340:8618:46ef in element (313,301). Row 313 may have 9 domain names (values ​​of element (313,303)) that are in the CTI database and associated with domains that support eSNI. Element (313,305)=15 is the number of domains hosted at IP address 6203:7400:3340:8618:46ef according to some reverse-IP-lookup service. In step 460, the system (e.g., SPMS 150) may distribute the EDCL to one or more ESNI-G / Ws (e.g., ESNI-G / W 120). In some embodiments, the ESNI-G / Ws may have a subscription to receive the EDCL. Process 400 may be repeated to change, modify, alter, or otherwise update the EDCL.

[0062] Process 400 may be performed in a different order and / or in different combinations than described above. The dynamics of CTI, eSNI support, and / or mapping of domain names to IP addresses suggest that process 400 may be performed frequently, or even continuously, to minimize delays and / or synchronization issues. In this regard, process 400 may use a continuous dynamic update model. Additionally or alternatively, process 400 may update the EDCL using batch processing. Although process 400 has been described with respect to cybersecurity applications for CTI-based network protection, it will be appreciated that other applications, such as lawful interception and privacy protection and preservation applications, may use process 400 to update the EDCL or its equivalent.

[0063] FIG. 5 illustrates one embodiment of a process 500 for a system (e.g., CTI-POLICY-SYS 154) that creates, distributes, and maintains a policy that includes one or more packet filtering rules derived from a CTI database. CTI-based policies can be distributed to a packet security gateway (PSG) that sits at a network boundary and applies the policy to one or more packets crossing the boundary in either direction. When a PSG is configured with a CTI-derived policy, such as a policy created by CTI-POLICY-SYS 156, the PSG acts as a threat intelligence gateway (TIG). The ESNI-G / W 120 may be a subsystem, subcomponent, or subfunction of the TIG tasked with filtering only packets associated with TLS-secured communications or TLS-secured communications using eSNI. The PKT-FILTER 122 may be used by the TIG or PSG to filter packets against the plaintext domain name that corresponds to the eSNI ciphertext. Packets may be filtered based on the above CTI derived indicators (e.g., IP address, 5-tuple, domain name, URI, etc.). Policies created by CTI-POLICY-SYS 154 may be used directly, commonly, and concurrently by ESNI-G / W 120 and systems that integrate ESNI-G / W 120, such as TIGs and / or PSGs. In some embodiments, a system (e.g., CTI-POLICY-SYS 154) may be integrated with or comprise a subsystem of SPMS 150, which creates, distributes, and / or maintains policies derived from the CTI database.

[0064] In step 510, the system may begin the CTI-POLICY creation process by accessing the current CTI indicator database CTI-INDICATOR-DB of the SPMS 150. It will be appreciated that the system may be adapted to other applications (e.g., law enforcement, privacy protection and preservation, etc.) and databases associated with other applications. Once the CTI-POLICY is initialized, the system may begin a looping or iterative process through each indicator in the CTI-INDICATOR-DB to create the CTI-POLICY.

[0065] In step 520, the system may create a packet filtering rule having the current indicator as a matching criterion. In step 530, the system may insert the rule into the CTI-POLICY. In terms of a typical packet filtering rule syntax, such as the OpenBSD PF syntax, the rule may specify at least one action and at least one packet matching criterion. The action or disposition may include allowing (e.g., passing, forwarding, etc.) a packet (e.g., a L2 / L3 packet in transit) to its intended destination. Alternatively, the action may include blocking (e.g., rejecting, dropping, etc.) a packet (e.g., a L2 / L3 packet in transit) from reaching its intended destination. The packet matching criterion may include L3, L4, and / or application layer packet field values ​​corresponding to the CTI indicator (e.g., IP address, 5-tuple, hostname / FQDN, URI, etc.). Depending on the capabilities and purpose (e.g., network security) of the target packet filtering device (e.g., PSG, TIG, and ESNI-G / W), additional rule components may be specified. These rule components may include packet transformation functions (PTFs) and metadata, etc. PTFs may include logging, capturing, mirroring, redirection, tunneling, etc. Additionally or alternatively, PTFs may include proxy functions. For example, PTF "tcp-rst" may transparently spoof the destination host of a TCP packet by creating and forwarding a TCP RST packet to the source host, which causes the source host to drop the TCP connection. Metadata may be used to inform the application logic of the packet filtering device and / or gateway of properties associated with the packet that cannot be derived directly from the packet's contents. Metadata may include, for example, information derived from the indicator's associated CTI report, the CTI provider that supplied the indicator, the type of attack associated with the indicator, attributes, etc.

[0066] In step 540, the system may determine whether there are more indicators in the CTI-INDICATOR-DB. If there are more indicators in the CTI-INDICATOR-DB, the process may return to step 520 to process the additional indicators in the CTI-INDICATOR-DB. If there are no additional indicators in the CTI-INDICATOR-DB, the process 500 may proceed to step 550, where the system may organize the rules in the CTI-POLICY. Additionally or alternatively, the system may The system may encode rules in the CTI-POLICY to satisfy constraints and / or improve performance of a packet filtering application (executed by a PSG / TIG / ESNI-G / W) that applies the CTI-POLICY to packets in transit. For example, duplicate rules may be removed, rules may be merged, and / or order dependencies may be identified. Additionally, rules may be reordered and / or grouped and ordered to support fast search by the packet filtering application. Step 550 may be performed by the target packet filtering device / gateway. In some embodiments, steps 550 and 530 may be combined. In step 560, the system (e.g., SPMS 150) may distribute the CTI-POLICY to one or more subscribing ESNI-G / Ws 120. Process 500 may be repeated to change, modify, alter, or otherwise update the CTI-POLICY.

[0067] Process 500 may be performed in a different order and / or in different combinations than described above. The dynamics of CTI suggest that process 500 be performed frequently or continuously to minimize delays and / or synchronization issues. In this regard, process 500 may use a continuous dynamic update model. Additionally or alternatively, process 500 may update the CTI-POLICY using batch processing. Although process 500 has been described in terms of a cybersecurity application for CTI-based network protection, it will be appreciated that other applications, such as lawful interception and privacy protection and storage applications, may use process 500 to update the CTI-POLICY or its equivalent.

[0068] FIG. 6 illustrates an embodiment of a process 600 of a system (e.g., DNS-ESNI-SYS 156) that creates, distributes, and maintains a DNS-ESNI set data structure. In some embodiments, the DNS-ESNI-SYS 156 system may be integrated with or comprise a subsystem of the SPMS 150 that creates, distributes, and maintains a policy of packet filtering rules derived from the CTI database. The DNS-ESNI set data structure may include entries for DNS-registered domain names that support eSNI. The DNS-ESNI data structure may determine whether a domain name registered in the Internet DNS is associated with a domain that supports eSNI. The DNS-ESNI set may be derived from a dynamic database that includes registered domain names in the Internet DNS and from dynamic eSNI support information derived from querying the DNS for eSNI support status for registered domain names. The ESNI-G / W may create and / or maintain the DNS-ESNI. Additionally or alternatively, a centralized approach, for example via an SPMS (e.g., SPMS 150), may be employed to create and / or manage DNS-ESNI.

[0069] The DNS-ESNI set data structure may be a Bloom filter (B / F), a Cuckoo filter (C / F), and / or any suitable set data structure. These types of filters may efficiently store elements of a dataset, insert elements into a dataset, and determine whether an element is a member of a set. In particular, a Cuckoo filter may support time-efficient deletion or removal of elements from a set. It will be appreciated that similar set data structures having properties similar to those of a Bloom filter or a Cuckoo filter may be used.

[0070] In step 610, the system (e.g., DNS-ESNI-SYS 156) may generate a database (e.g., DNS-REG-DB) by collecting and / or aggregating lists of domain names registered in the DNS. Sources of these lists may include, for example, DNS registry operator organizations and / or associated delegates. Zone files, domain list aggregator services, country code domains (CCDs) found by the DNS and / or authoritative name servers The DNS-ESNI may be generated through a third-party service, such as an ISP, an ISP, or an ISP. Once the DNS-registered domain name is obtained (e.g., determined), the system may begin a looping or iterative process to generate the DNS-ESNI.

[0071] In step 620, the system may query the DNS (e.g., Internet DNS 160) for the presence of an eSNI resource record (RR) for each domain in the database DNS-REG-DB. The RR may indicate that the associated domain supports eSNI. In step 630, the system may determine whether an RR associated with eSNI exists for the current domain name. If the system determines that the domain does not support eSNI, the process 600 returns to step 620 to query the DNS for the next domain name entry in the database DNS-REG-DB. If the system determines that the domain supports eSNI, the system may insert the domain name into the set DNS-ESNI in step 640. In step 650, the system may determine whether there are more domain names to process in the DNS-REG-DB. If there are, the process 600 returns to step 620 to process the next entry in the DNS-REG-DB. If there are no more domain names, the system may proceed to step 660, where the system (e.g., SPMS 150) may distribute the DNS-ESNI to one or more subscribing ESNI-G / Ws 120. Process 600 may be repeated to change, modify, alter, or otherwise update the DNS-ESNI.

[0072] Process 600 may be performed in a different order and / or in different combinations than described above. The dynamics of DNS and eSNI indicate that process 600 may be performed frequently or continuously to minimize delay and / or synchronization issues. In this regard, process 600 may use a continuous dynamic update model. In some embodiments, an ESNI-G / W (e.g., ESNI-G / W 120) may determine the information included in the DNS-ESNI as needed by directly querying the DNS for eSNI support status when the ESNI-G / W observes a clear-text SNI included in an in-flight packet.

[0073] 7 illustrates one embodiment of a process 700 for a system (e.g., SPMS 150) that creates, distributes, and maintains EDCL, CTI-derived policies, and / or DNS-ESNI set data structures. While the embodiment described below relates to a CTI-based network protection application, it will be understood that the system and method described below may be incorporated into the operation of SPMS 150 and / or an associated ESNI-G / W.

[0074] In step 710, the system (e.g., SPMS 150) may collect CTI reports from multiple CTI providers 140 and create a database of these reports (e.g., CTI-REPORT-DB). The CTI reports may include one or more network threat indicators in the form of IP addresses, 5-tuples, domain names, URIs, etc. The threat indicators may identify network hosts and / or resources associated with the threat, as well as additional information associated with the threat, such as threat attack type, attributes, etc. The CTI reports may include network threat indicators that indicate domain names that may be threats.

[0075] In step 720, the system (e.g., SPMS 150) extracts network threat indicators from the reports in CTI-REPORT-DB and stores them in a database C The CTI provider may create a CTI-INDICATOR-DB. The CTI-INDICATOR-DB may be, for example, the input described above in steps 405 and 510. The CTI provider may create new CTI reports and / or update existing CTI reports. In this regard, the system (e.g., SPMS 150) may return to step 710 after completing step 720.

[0076] In step 725, the system (e.g., SPMS 150) may operate EDCL-SYS 152. In step 730, the system (e.g., SPMS 150) may operate CTI-POLICY-SYS 154. In step 735, the system (e.g., SPMS 150) may operate DNS-ESNI-SYS 156. Steps 725, 730, and / or 735 may operate simultaneously. In step 725, the system may distribute EDCL-SYS 152 to one or more subscribing ESNI-G / W 120 via MGMT-I / F 129. In step 730, the system may distribute CTI-POLICY to one or more subscribing ESNI-G / W 120 via MGMT-I / F 129. In step 735, the system may distribute DNS-ESNI to one or more subscribing ESNI-G / W 120 via MGMT-I / F 129. Each of the one or more subscribing ESNI-G / Ws may receive the EDCL, CTI-POLICY, and DNS-ESNI and forward the data (e.g., via BUS 128) to the EDCL-SVC 123, PKT-FILTER 122, and DNS-ESNI-SVC 124, respectively.

[0077] 8A and 8B show one embodiment of a process for configuring an ESNI-G / W120 with one or more packet filtering policies and an EDCL, and executing a network threat protection application based on the one or more packet filtering policies and the EDCL derived from one or more CTI indicators.

[0078] In step 805, the SPMS 150 may deliver at least one of a CTI-derived packet filtering policy (e.g., CTI-POLICY) and an associated CTI-derived EDCL to the ESNI-G / W 120. The SPMS 150 may also deliver the DNS-ESNI to the ESNI-G / W 120. Based on at least one of the CTI-derived packet filtering policy (e.g., CTI-POLICY), the associated CTI-derived EDCL, and / or the DNS-ESNI, the ESNI-G / W 120 may configure the PKT-FILTER 122, the EDCL-SVC 123, and / or the DNS-ESNI-SVC 124 of the ESNI-G / W 120.

[0079] In step 810, a user of a web browser running on HOST-1 110 may attempt to access site SRVR-0 130. DNS 130 may host a domain (e.g., www.legitimate-non-CTI-site.net) that supports eSNI. That is, the DNS entry for the domain may include a public encryption key. A user may enter the domain into a browser window as part of a URI (e.g., https: / / www.legitimate-non-CTI-site.net / ). The browser may query DNS 160 for the IP address of the domain (e.g., www.legitimate-non-CTI-site.net). In response to the query, the browser may receive the IP address (e.g., 87.65.43.21) and the public encryption key (e.g., SITE-0-KEY). In some embodiments, the DNS query may be captured by a DNS-QUERY-TRACKER 125 instance (not shown). After receiving the IP address and the public encryption key, the browser establishes a TCP connection to port 443 (HTTPS) of 87.65.43.21. To establish a TLS-secured session, the browser may generate a ClientHello message, encrypt the domain name and / or other portions of the message using the key in SITE-0-KEY, encapsulate the message in a TCP packet and IP packet PKT-0 with the (L3 / IP) destination IP address field set to 87.65.43.21, and forward packet PKT-0 toward SRVR-0 130.

[0080] In step 815, ESNI-G / W 120 may intercept packet PKT-0. ESNI-G / W 120 may examine the ClientHello message and determine that the message includes an encrypted hostname (e.g., eSNI ciphertext). In response to detecting the encrypted hostname (e.g., encrypted domain name), ESNI-G / W 120 may extract the (L3 / IP) destination IP address (e.g., 87.65.43.21) from PKT-0 and search the EDCL for an entry indexed by 87.65.43.21 by querying EDCL-SVC 123. If the search returns no results, ESNI-G / W 120 may determine that the cleartext domain name (e.g., www.legitimate-non-CTI-site.net) is not associated with any domain name threat indicators in the associated policy CTI-POLICY. ESNI-G / W 120 may make this determination even though ESNI-G / W 120 does not know the clear domain name that corresponds to the encrypted hostname (e.g., encrypted domain name). At the conclusion of step 815, ESNI-G / W 120 may allow PKT-0 to proceed toward PKT-0's destination 87.65.43.21 (SRVR-0 130). In step 820, a TLS tunnel between HOST-1 110 and SRVR-0 130 may be established, and an HTTP session (secured by TLS) (e.g., HTTPS) may take place. Once the HTTP session is complete, the TLS tunnel and TCP connection may be torn down.

[0081] In step 825, a user of a web browser running on HOST-1 110 may attempt to access site SRVR-1 131. DNS 131 may host a second domain (e.g., toplipts.com) that supports eSNI. As discussed above, the DNS entry for the second domain may include a second public encryption key for the second domain name. A user may enter the second domain into a browser window as part of a URI (e.g., https: / / toplipts.com / ). The browser may query DNS 160 for an IP address of the second domain (e.g., toplipts.com). In response to the query, the browser may receive a second IP address (e.g., 22.74.02.18) and a second public encryption key (e.g., SITE-1-KEY). Similar to the first query above, the DNS query may be captured by a DNS-QUERY-TRACKER 125 instance (not shown). After receiving the second IP address and the second public encryption key, the browser may establish a TCP connection with the second IP address (e.g., 22.74.02.18) on port 443 (HTTPS). To establish a TLS-secured session, the browser may generate a ClientHello message, encrypt the second domain name (e.g., toplipts.com) and / or one or more portions of the message using the second public encryption key (e.g., SITE-1-KEY), encapsulate the message in a TCP packet with a (L3 / IP) destination IP address field set to the second IP address (e.g., 22.74.02.18) and IP packet PKT-1, and forward packet PKT-1 toward SRVR-1 131.

[0082] In step 830, ESNI-G / W 120 may intercept packet PKT-1. ESNI-G / W 120 may examine the ClientHello message and determine that the message includes eSNI ciphertext. ESNI-G / W 120 may receive the (L3 / IP) The ESNI-G / W 120 may search the EDCL for an entry indexed by 22.74.02.18 by extracting the destination IP address (e.g., 22.74.02.18) and querying the EDCL-SVC 123. The search may return an entry from the EDCL. For example, the search may return line 314 from EDCL 300 discussed above with respect to FIG. 3. After examining the contents of the entry, the ESNI-G / W 120 may determine that the eSNI ciphertext corresponds to the plaintext domain name toplipts.com. The ESNI-G / W 120 may invoke the PKT-FILTER 122 system. As discussed above, the PKT-FILTER 122 may be configured with the CTI-POLICY in step 805. The ESNI-G / W 120 may search for a packet filtering rule in the CTI-POLICY that matches the criteria "toplipts.com". According to this embodiment, a match rule with a (network protection) "block" action may be found to process the match packet (PKT-1). Additionally or alternatively, the match rule may include a packet transformation function (PTF) "tcp-rst". ESNI-G / W 120 may impersonate SRVR-1 131 or be a transparent proxy and send a TLS alert protocol message with a (fatal) alert code (e.g., code 40 "handshake failure") to HOST-1 110, which causes HOST-1 110 to close the TLS session. A TCP RST may cause HOST-1 110 to tear down the TCP connection. Alternatively, ESNI-G / W 120 may send a TCP RST, which closes the TLS session without signaling. In this regard, ESNI-G / W 120 may not want to provide HOST-1 110 with any data and / or information that may be compromised.

[0083] In step 835, a user of a web browser running on HOST-1 110 may attempt to access site SRVR-2 132. HOST-1 132 may host a third domain name (e.g., kottoqui.ga) that supports eSNI. That is, the DNS entry for the third domain name may include a public encryption key. A user may enter the third domain name into a browser window as part of a URI (e.g., https: / / kottoqui.ga / ). A browser on HOST-1 110 may query DNS 160 for a third IP address (e.g., 102.2.18.81) and a third public encryption key (e.g., SITE-2-KEY) for the third domain name (e.g., kottoqui.ga). As described above, the DNS query may be captured by DNS-QUERY-TRACKER 125 (not shown). After receiving the third IP address and the third public encryption key, the browser may establish a TCP connection with port 443 (HTTPS) of 102.2.18.81. To establish a TLS-secured session, the browser may generate a ClientHello message, encrypt one or more other portions of the message using the third domain name (e.g., kottoqui.ga) and / or the third public encryption key (e.g., SITE-2-KEY), encapsulate the message in a TCP packet and IP packet PKT-2 with the (L3 / IP) destination IP address field set to 102.2.18.81, and forward packet PKT-2 toward SRVR-2 132.

[0084] In step 840, ESNI-G / W 120 may intercept packet PKT-2. ESNI-G / W 120 may examine the ClientHello message and determine that the message contains an encrypted hostname (e.g., eSNI ciphertext). ESNI-G / W 120 may extract the (L3 / IP) destination IP address (e.g., 102.2.18.81) and look up the EDCL for an entry indexed by 102.2.18.81 by querying EDCL-SVC 123. The lookup may return an entry from the EDCL. For example, the lookup may return row 310 from EDCL 300 discussed above with respect to FIG. 3. After examining the contents of the entry, ESNI-G / W 120 may: It may be determined that the clear text domain name corresponding to the eSNI ciphertext cannot be determined from the EDCL. The ESNI-G / W 120 may determine that all domains hosted at IP address 102.2.18.81 are in the CTI indicator database and associated CTI-POLICY and have domain names that support eSNI. Any of the eight domain names in element {row 310, column 302} of the EDCL 300 may be the clear text domain name corresponding to the eSNI ciphertext. The ESNI-G / W 120 may select any one of the eight domain names as a possible communication partner and then proceed. Additionally or alternatively, the ESNI-G / W 120 may check whether the DNS-QUERY-TRACKER 125 has an entry that may determine the communication partner. In this example, the ESNI-G / W 120 may check the DNS-QUERY-TRACKER 125 to determine that the third domain name (e.g., kottoqui.ga) is likely to be the communication partner. ESNI-G / W 120 may call PKT-FILTER 122 system configured with CTI-POLICY in step 805 to search for packet filtering rules in CTI-POLICY with matching criteria "kottoqui.ga". It may find a match rule with (network protection) "block" action and packet transformation function (PTF) "tcp-rst" to process the match packet (PKT-2). ESNI-G / W 120 may impersonate SRVR-2 132 or be a transparent proxy. Additionally or alternatively, ESNI-G / W 120 may send a TLS alert protocol message with a (fatal) alert code (e.g., code 40 "handshake failure") to HOST-1 110. The TLS alert protocol message may cause HOST-1 110 to close the TLS session. Additionally or alternatively, ESNI-G / W 120 may send a TCP RST to HOST-1 110, tearing down the TCP connection.

[0085] Referring to FIG. 8B, a user of a web browser running on HOST-1 110 may attempt to access site SRVR-3 133 in step 845. SRVR-3 133 may host a fourth domain name (e.g., cakbacon.cn) that supports eSNI. Similar to the above example, the DNS entry for the fourth domain name may include a public encryption key. The user may enter the fourth domain name into a browser window as part of the URI (e.g., https: / / cakbacon.cn / ). The browser may query DNS 160 for a fourth IP address (e.g., 14.99.65.22) and a fourth public encryption key (e.g., SITE-3-KEY). The DNS query may be captured by a DNS-QUERY-TRACKER 125 instance (not shown). The browser may establish a TCP connection to port 443 (HTTPS) of 14.99.65.22. To establish a TLS-secured session, the browser may generate a ClientHello message, encrypt one or more portions of the message using the fourth domain name (e.g., cakbacon.cn) and / or the fourth public encryption key (e.g., SITE-3-KEY), encapsulate the message in a TCP packet and IP packet PKT-3 with the (L3 / IP) destination IP address field set to 14.99.65.22, and forward packet PKT-3 toward SRVR-3 133.

[0086] In step 850, ESNI-G / W 120 may intercept packet PKT-3 and examine the ClientHello message. ESNI-G / W 120 may determine that the message contains an encrypted hostname (e.g., eSNI ciphertext). ESNI-G / W 120 may extract the (L3 / IP) destination IP address 14.99.65.22 and look up the EDCL for an entry indexed by 14.99.65.22 by querying EDCL-SVC 123. The lookup may return an entry such as row 312 in EDCL 300 described above in FIG. 3. After examining the contents of row 312, ESNI-G / W 120 may determine that the message contains an encrypted hostname (e.g., eSNI ciphertext). ESNI-G / W 120 may extract the (L3 / IP) destination IP address 14.99.65.22 and look up the EDCL for an entry indexed by 14.99.65.22 by querying EDCL-SVC 123. The lookup may return an entry such as row 312 in EDCL 300 described above in FIG. 3. ESNI-G / W 120 may determine that it is unable to determine from the EDCL the clear domain name that corresponds to the encrypted hostname (e.g., eSNI ciphertext). ESNI-G / W 120 may determine that there are one or more domains hosted on 14.99.65.22 that are not within the CTI. Additionally or alternatively, ESNI-G / W 120 may determine that it should decrypt the clear domain name that corresponds to the encrypted hostname (e.g., eSNI ciphertext) to properly enforce policies associated with the communication. ESNI-G / W 120 may spoof SRVR-3 133 or be a transparent proxy. ESNI-G / W 120 may send a TLS message to HOST-1 110. The TLS message may cause HOST-1 110 to issue a ClientHello that does not encrypt the SNI. The TLS message may include a TLS Alert protocol message with a (fatal) alert code (e.g., code 70 “Protocol Version”). The TLS Alert protocol message may also cause HOST-1 110 to use a TLS version, such as TLS 1.2, that does not support encrypted SNI. Additionally or alternatively, ESNI-G / W 120 may send a TLS message that causes HOST-1 110 to not use the encrypted SNI option.

[0087] In step 860, the browser on HOST-1 110 may generate a ClientHello message with the SNI extension field set to (cleartext) cakbacon.cn, encapsulate the message in a TCP packet and IP packet PKT-3.1 with the (L3 / IP) destination IP address field set to 14.99.65.22, and forward packet PKT-3.1 toward SRVR-3 133. In step 865, ESNI-G / W 120 may intercept packet PKT-3.1 and examine the ClientHello message. ESNI-G / W 120 may determine that the message includes the cleartext SNI value cakbacon.cn. ESNI-G / W 120 may invoke the PKT-FILTER 122 system configured with CTI-POLICY in step 805 to look up the packet filtering rules in CTI-POLICY with the matching criteria "cakbacon.cn." According to this embodiment, a match rule may be found with a (network protection) "block" action for processing the match packet (PKT-3.1) and a packet transformation function (PTF) "tcp-rst". The ESNI-G / W 120 may impersonate the SRVR-3 133 or be a transparent proxy and send a TLS alert protocol message with a (fatal) alert code (e.g., code 40 "handshake failure") to HOST-1 110. The TLS alert protocol message may cause HOST-1 110 to close the TLS session. Additionally or alternatively, the ESNI-G / W 120 may send a TCP RST to HOST-1 110, causing HOST-1 110 to tear down the TCP connection.

[0088] In step 870, a user of a web browser running on HOST-1 110 may attempt to access site SRVR-4 134. HOST-1 134 may host a fifth domain name (e.g., not-a-CTI-threat-site.net) that supports eSNI. Similar to the previous discussion, the DNS entry may include a fifth public encryption key. The fifth domain name may not be listed in the CTI database and / or the associated CTI-POLICY. A user may enter the fifth domain name in a browser window as part of a URI (e.g., https: / / not-a-CTI-threat-site.net / ). The browser on HOST-1 110 may query DNS 160 for the IP address (e.g., 14.99.65.22) and fifth public encryption key (e.g., SITE-4-KEY) of the fifth domain name (e.g., not-a-CTI-threat-site.net). DNS 160 may return an entry such as row 312 from EDCL 300 shown in FIG. 3. The DNS query may be performed by a DNS-QUERY-TRACKER 125 instance (not shown). After receiving the response to the DNS query, the browser on HOST-1 110 may establish a TCP connection to 14.99.65.22 on port 443 (HTTPS). To establish a TLS-secured session, the browser may generate a ClientHello message, encrypt one or more additional parts of the message using the domain name (e.g., not-a-CTI-threat-site.net) and / or a fifth public encryption key (e.g., SITE-4-KEY), encapsulate the message in a TCP packet and IP packet PKT-4 with the (L3 / IP) destination IP address field set to 14.99.65.22, and forward packet PKT-4 toward SRVR-4 134.

[0089] In step 875, ESNI-G / W 120 may intercept packet PKT-4. ESNI-G / W 120 may examine the ClientHello message and determine that the message includes an encrypted hostname (e.g., eSNI ciphertext). ESNI-G / W 120 may extract the (L3 / IP) destination IP address 14.99.65.22 and search the EDCL for an entry indexed by 14.99.65.22. Searching the EDCL may include querying EDCL-SVC 123 using the IP address 14.99.65.22. The search may return an entry from the EDCL. The entry may be row 312 of EDCL 300 discussed above with respect to FIG. 3. After examining the contents of row 312, ESNI-G / W 120 may determine that a cleartext domain name corresponding to the eSNI ciphertext cannot be determined from the EDCL. Additionally or alternatively, ESNI-G / W 120 may determine that there are multiple domains hosted on 14.99.65.22 that are not within the CTI. ESNI-G / W 120 may determine that it should decrypt the clear domain name that corresponds to the encrypted hostname (e.g., eSNI ciphertext) to properly enforce one or more policies associated with the communication. ESNI-G / W 120 may send a TLS message to HOST-1 110 that may spoof SRVR-4 134 or be a transparent proxy and cause HOST-1 110 to issue a ClientHello that does not encrypt the SNI. For example, ESNI-G / W 120 may send a TLS Alert protocol message to HOST-1 110 with a (fatal) alert code (e.g., code 70 “Handshake Failed”). The TLS Alert message may cause HOST-1 110 to use a TLS version that does not support encrypted SNI (e.g., TLS 1.2). Additionally or alternatively, ESNI-G / W 120 may send a TLS message to HOST-1 110 that does not cause HOST-1 110 to use the encrypted SNI option.

[0090] In step 880, the browser on HOST-1 110 may generate a ClientHello message with the SNI extension field set to (cleartext) not-a-CTI-threat-site.net, encapsulate the message in a TCP packet and IP packet PKT-4.1 with the (L3 / IP) destination IP address field set to 14.99.65.22, and forward packet PKT-4.1 toward SRVR-4 134. In step 885, ESNI-G / W 120 may intercept packet PKT-4.1 and inspect the ClientHello message. Based on inspecting the ClientHello message, ESNI-G / W 120 may determine that the message includes the cleartext SNI value not-a-CTI-threat-site.net. ESNI-G / W 120 may invoke PKT-FILTER 122 system configured with CTI-POLICY in step 805 to search for packet filtering rules in CTI-POLICY with matching criteria "not-a-CTI-threat-site.net". The search may return no results. ESNI-G / W 120 may allow PKT-4.1 to proceed toward its destination 14.99.65.22 (SRVR-4 134). In step 890, ESNI-G / W 120 may allow PKT-4.1 to proceed toward PKT-4.1's destination 14.99.65.22 (SRVR-4 134). ESNI-G / W 120 may then allow PKT-4.1 to proceed toward PKT-4.1's destination 14.99.65.22 (SRVR-4 134). A (TLS-secured) HTTP session can take place. Once the HTTP session is complete, the TLS tunnel and the TCP connection can be torn down.

[0091] In some embodiments, an organization may have a policy that does not allow the use of eSNI technology because the organization wants to track and regulate external sites that its internal users access and / or attempt to access. In this embodiment, the policy may be enforced by an ESNI-G / W application that performs a process similar to that described above in steps 870-890, but does not use EDCL and / or uses a different policy than CTI-POLICY. For example, if the ESNI-G / W application determines that the ClientHello message contains eSNI ciphertext in step 875, the application may skip looking through the EDCL and have the ESNI-G / W 120 spoof SRVR-4 134 in step 875. As described above, the ESNI-G / W may send a TLS message to HOST-1 110 that may cause HOST-1 110 to issue a ClientHello that does not contain an encrypted SNI. Step 880 may be performed without modification, but step 885 may apply a different policy than CTI-POLICY. If the policy applied in step 885 allows the communication session to proceed, step 890 may be performed without modification.

[0092] FIG. 9 illustrates one embodiment of a process for configuring an ESNI-G / W 120 with packet filtering operations to support one or more applications. The one or more applications may include, for example, a law enforcement (LE) application, such as lawful interception, or (2) a privacy protection and preservation (P3) application. For an LE application, a packet filtering policy and / or EDCL may be derived from an LEI indicator. Similarly, a packet filtering policy and / or EDCL may be derived from a P3 indicator (P3I) for a P3 application. Such LE and P3 applications may include logic that relies on observing a domain name associated with a communication. If the communication is associated with a domain name included in any LEI and / or P3I database, the application may act on the communication.

[0093] This illustration of Figure 9 is similar in form and functionality to the CTI application described in Figures 8A and 8B. For example, the CTI and / or associated CTI-POLICY and EDCL of Figures 8A and 8B may be similar to the LEI and / or associated LEI-POLICY and LEI-EDCL of Figure 9. The TLS-MITM-PROXY 126 may be used differently in Figure 9 than in the examples discussed above. CTI and P3, as well as other applications, may use the TLS-MITM-PROXY 126 component for reasons similar to those of the LEI application, including, for example, (1) decrypting the communication ciphertext to cleartext so that the application can further examine the communication to determine the domain name that corresponds to the eSNI ciphertext and then process accordingly (e.g., invoke PKT-FILTER 122 on the associated cleartext packet), and (2) further examining the cleartext for other information other than the domain name, such as a user ID, in order to decrypt the communication and make communication processing decisions (e.g., whether to capture / store the cleartext communication).

[0094] In step 910, the SPMS 150 may distribute the LEI-derived packet filtering policy (e.g., LEI-POLICY) and the associated LEI-derived LEI-EDCL to the ESNI-G / W 120. Additionally or alternatively, the SPMS 150 may distribute the DNS-ESNI. The ESNI-G / W 120 may, for example, distribute the LEI-derived packet filtering policy (e.g., LEI-POLICY) and the associated LEI-derived LEI-EDCL to the ESNI-G / W 120. , LEI-POLICY), the associated LEI-derived LEI-EDCL, and / or DNS-ESNI, and / or the PKT-FILTER 122, EDCL-SVC 123, and / or DNS-ESNI-SVC 124 of the ESNI-G / W 120. In some embodiments, the SPMS 150 may distribute additional LEI data, including, for example, one or more lists of user IDs.

[0095] In step 920, a user of a web browser running on HOST-2 112 may attempt to access site SRVR-6 136. HOST-2 136 may host a seventh domain name (e.g., LEI-watchlist-site.net) that supports eSNI. That is, the DNS entry for the seventh domain may include the seventh public encryption key. A user may enter the seventh domain name into a browser window as part of a URI (e.g., https: / / LEI-watchlist-site.net / ). The browser may query DNS 160 for the seventh IP address (e.g., 21.43.65.87) and the seventh public encryption key (e.g., SITE-6-KEY) of LEI-watchlist-site.net. The DNS query may be captured by a DNS-QUERY-TRACKER 125 instance (not shown). After receiving a response from DNS 160, the browser on HOST-2 112 may establish a TCP connection to port 443 (HTTPS) of 21.43.65.87. To establish a TLS-secured session, the browser may generate a ClientHello message, encrypt one or more parts of the message using the domain name and / or a seventh public encryption key (e.g., SITE-6-KEY), encapsulate the message in a TCP packet and IP packet PKT-6 with the (L3 / IP) destination IP address field set to 21.43.65.87, and forward packet PKT-6 toward SRVR-6 136.

[0096] In step 930, ESNI-G / W120 may intercept packet PKT-6 and examine the ClientHello message included in packet PKT-6. ESNI-G / W120 may determine that the message includes an encrypted hostname (e.g., eSNI ciphertext). ESNI-G / W120 may extract the (L3 / IP) destination IP address 21.43.65.87 and look up the LEI-EDCL for an entry indexed by 21.43.65.87 by querying LEI-EDCL-SVC123. The lookup may return an entry in the LEI-EDCL (indexed by 21.43.65.87). Based on the lookup results, ESNI-G / W120 may determine (decrypt) the (cleartext) domain name as "LEI-watchlist-site.net". The ESNI-G / W 120 may invoke the PKT-FILTER 122 system configured with the LEI-POLICY in step 910 to search for packet filtering rules in the LEI-POLICY with the matching criteria "LEI-watchlist-site.net". It may find a match rule indicating an "Allow" action for processing the match packet (PKT-6) and the packet transformation function (PTF) "tls-mitm-proxy". The PTF "tls-mitm-proxy" may signal the ESNI-G / W 120 to forward PKT-6 and subsequent packets associated with the same flow / communication as PKT-6 to the TLS-MITM-PROXY 126. After passing through the TLS-MITM-PROXY 126, PKT-6 may be forwarded by the ESNI-G / W 120 towards the SRVR-6 136. In some embodiments, the proxy version of PKT-6 may be forwarded to the SRVR-6 136.

[0097] In step 940, a TLS tunnel between HOST-2 112 and SRVR-6 136 can be established and an HTTP session (secured by TLS) can take place. The packet containing the session is marked with TLS-MITM-PROXY 126, the application may capture and store the decrypted cleartext message / packet. The application may also check the cleartext for additional information, e.g., user ID, to determine if capturing and storing the cleartext is acceptable. If not, it may terminate the capture and storage functions, erase the stored data, and / or otherwise make it inaccessible. When the HTTP session is complete, the TLS tunnel and TCP connection may be torn down.

[0098] 10 illustrates one embodiment of packet filtering by ESNI-G / W 120 to minimize interception. A first application may enforce the use of eSNI whenever eSNI is available. A second application may enforce the use of eSNI for all TLS-secured communications. That is, the second application may allow only TLS-secured communications that support eSNI and may use eSNI to access those sites.

[0099] In step 1005, the SPMS 150 may deliver the DNS-ESNI to the ESNI-G / W 120. The DNS-ESNI may be an updated version of the DNS-ESNI. The ESNI-G / W 120 may configure the DNS-ESNI-SVC 124 with the DNS-ESNI. The ESNI-G / W 120 may run a first application (e.g., that enforces the use of eSNI whenever eSNI is available).

[0100] In step 1010, a user of a web browser running on HOST-4 114 may attempt to access site SRVR-7 137. SRVR-7 137 may host an eighth domain name that does not support eSNI (e.g., non-eSNI-site.net). The user may enter the eighth domain name into a browser window as part of a URI (e.g., https: / / non-eSNI-site.net / ). In response to receiving the eighth domain name, the browser may query DNS 160 for an IP address (e.g., 78.56.34.12) of the eighth domain name (e.g., non-eSNI-site.net). Upon receiving the IP address, the browser may establish a TCP connection with port 443 (HTTPS) of 78.56.34.12. To establish a TLS-secured session, the browser may generate a ClientHello message with the SNI field set to the plaintext “non-eSNI-site.net”, encapsulate the message in a TCP packet and IP packet PKT-7 with the (L3 / IP) destination IP address field set to 78.56.34.12, and forward packet PKT-7 toward SRVR-7 137.

[0101] In step 1015, ESNI-G / W 120 may intercept packet PKT-7 and examine the ClientHello message contained in packet PKT-7. ESNI-G / W 120 may determine that the message contains a cleartext SNI value "non-eSNI-site.net". ESNI-G / W 120 may query DNS-ESNI-SVC 124 and determine that the domain "non-eSNI-site.net" does not support eSNI. ESNI-G / W 120 may allow PKT-7 to proceed toward PKT-7's destination 78.56.34.12 (SRVR-7 137). In step 1020, a TLS tunnel between HOST-4 114 and SRVR-7 137 may be established and an HTTP session (secured by TLS) may take place. Once the HTTP session is complete, the TLS tunnel and the TCP connection may be torn down.

[0102] In step 1025, a user of a web browser running on HOST-4 114 may attempt to access site SRVR-8 138. SRVR-8 138 may host a ninth domain name (e.g., supports-eSNI-site.net) that supports eSNI. The user may enter the ninth domain name into a browser window as part of a URI (e.g., https: / / supports-eSNI-site.net / ). The browser may then query DNS 160 for an IP address (e.g., 12.34.43.21) of the ninth domain (e.g., supports-eSNI-site.net). Upon receiving the IP address, the browser may establish a TCP connection with port 443 (HTTPS) of 12.34.43.21. To establish a TLS-secured session, the browser may generate a ClientHello message with the SNI field set to the plaintext "supports-eSNI-site.net", encapsulate the message in a TCP packet and IP packet PKT-8 with the (L3 / IP) destination IP address field set to 12.34.43.21, and forward packet PKT-8 toward SRVR-8 138.

[0103] In step 1030, ESNI-G / W 120 may intercept packet PKT-8 and examine the ClientHello message included in packet PKT-8. ESNI-G / W 120 may determine that the message includes a cleartext SNI value "supports-eSNI-site.net". ESNI-G / W 120 may query DNS-ESNI-SVC 124 to determine that the domain "supports-eSNI-site.net" supports eSNI. Because the first application requires that eSNI be used when it is available, ESNI-G / W 120 may spoof SRVR-8 138 or be a transparent proxy. ESNI-G / W 120 may send a TLS message to HOST-4 114 that may cause HOST-4 114 to issue a ClientHello using eSNI. The TLS messages may include a TLS Alert protocol message signaling to HOST-4 114 that eSNI is required.

[0104] In step 1035, a browser running on HOST-4 114 may query DNS 160 for a public encryption key (e.g., SITE-8-KEY) for the domain "supports-eSNI-site.net." The browser may generate a ClientHello message, encrypt the domain name "supports-eSNI-site.net" and / or one or more other portions of the message using the public encryption key (e.g., SITE-8-KEY), encapsulate the message in a TCP packet and IP packet PKT-8.1 with the (L3 / IP) destination IP address field set to 12.34.43.21, and forward packet PKT-8.1 toward SRVR-8 138.

[0105] In step 1040, ESNI-G / W 120 may intercept packet PKT-8.1 and examine the ClientHello message contained in packet PKT-8.1. ESNI-G / W 120 may determine that the message contains eSNI ciphertext. ESNI-G / W 120 may allow PKT-8.1 to proceed by forwarding PKT-8.1 toward its destination 12.34.43.21 (SRVR-8 138).

[0106] In step 1045, a TLS tunnel between HOST-4 114 and SRVR-8 138 can be established and an HTTP session (secured by TLS) can take place. Once the HTTPS session is complete, the TLS tunnel and TCP connection can be torn down.

[0107] During steps 1050 and 1055, the ESNI-G / W 120 may be running a second application that only allows access to sites that support eSNI and that requires eSNI use.

[0108] In step 1050, a user of a web browser running on HOST-4 114 may attempt to access site SRVR-7 137. SRVR-7 137 may host a tenth domain name that does not support eSNI (e.g., non-eSNI-site.net). The user may enter the domain name into a browser window as part of the URI (e.g., https: / / non-eSNI-site.net / ). The browser may query DNS 160 for an IP address for non-eSNI-site.net (e.g., 78.56.34.12). Upon receiving the IP address, the browser may establish a TCP connection to port 443 (HTTPS) of 78.56.34.12. To establish a TLS-secured session, the browser may create a ClientHello message with the SNI field set to the plaintext "non-eSNI-site.net", encapsulate the message in a TCP packet and IP packet PKT-9 with the (L3 / IP) destination IP address field set to 78.56.34.12, and forward packet PKT-9 toward SRVR-7 137.

[0109] In step 1055, ESNI-G / W 120 may intercept packet PKT-9 and examine the ClientHello message contained in packet PKT-9. ESNI-G / W 120 may determine that the message contains a cleartext SNI value of "non-eSNI-site.net." ESNI-G / W 120 may query DNS-ESNI-SVC 124 and determine that the domain "non-eSNI-site.net" does not support eSNI. Because the second application may only be allowed to access sites that support eSNI, ESNI-G / W 120 may query DNS-ESNI-SVC 124 and determine that the domain "non-eSNI-site.net" does not support eSNI. 137 or may be a transparent proxy. The second application may run similarly to the first application described above when accessing a site that supports eSNI. The ESNI-G / W 120 may send a TLS alert protocol message with a (fatal) alert code (e.g., code 40 "handshake failure") to HOST-4 114. The TLS alert protocol message may cause HOST-4 114 to close the TLS session. Additionally or alternatively, the ESNI-G / W 120 may send a TCP RST to HOST-4 114. The TCP RST may cause HOST-4 114 to tear down the TCP connection.

[0110] As described above, the packet filtering system may receive a packet including ciphertext that includes an encrypted Server Name Indicator (SNI) value. The packet filtering system may determine a cleartext hostname associated with the encrypted hostname to determine whether the cleartext hostname is associated with one or more threats. FIG. 11 illustrates one embodiment of a process 1100 for determining whether encrypted network traffic is associated with one or more threats. Some or all of the steps of the process 1100 may be performed using one or more computing devices, such as the packet security gateway 120.

[0111] In step 1110, the packet filtering device may receive one or more threat indicators. For example, the packet filtering device may receive threat indicators (e.g., raw threat indicators) directly from one or more cyber threat intelligence providers (CTIPs) and create one or more packet filtering rules. The packet filtering rules may be configured to be managed by a security policy manager. In one embodiment, the packet filtering device may receive one or more policies from a network management server (SPMS). Additionally or alternatively, the one or more threat indicators may be received indirectly as matching criteria in a packet filtering rule. In a further embodiment, the packet filtering device may receive one or more policies comprised of packet filtering rules derived from the threat indicators. The one or more policies may include an enterprise communications policy, a privacy, protection, and retention policy, a law enforcement policy, or equivalents. The packet filtering device may be at a boundary interfacing between a first network and a second network. In this regard, the packet filtering device may be a gateway, a firewall, a router, or any other type of edge device. Additionally or alternatively, the packet filtering device may be a pass-through device located on one or more network segments. As discussed above, the one or more threat indicators may include multiple domain names (e.g., host names) associated with the one or more threats. Additionally or alternatively, the one or more threat indicators may include multiple network addresses (e.g., IP addresses) associated with the one or more threats.

[0112] At step 1120, the packet filtering device may receive a plurality of packets including ciphertext that includes an encrypted Server Name Indication (SNI) value. The plurality of packets may be associated with a single communication and / or message, such as a ClientHello message. As described above, the plurality of packets may include ciphertext that includes an encrypted Server Name Indication (SNI) value.

[0113] In step 1130, the packet filtering device may determine whether the cleartext hostname can be deciphered from the encrypted hostname (e.g., encrypted SNI (eSNI)). The packet filtering device may use one or more of the techniques described above with respect to FIG. 8A and FIG. 8B. For example, the packet filtering device may determine a destination network address (e.g., IP address) associated with the multiple packets. The packet filtering device may query a data structure indexed by the destination network address to determine a cleartext hostname associated with or corresponding to the encrypted hostname. Based on the query, the packet filtering device may receive a response including a cleartext hostname associated with the encrypted hostname. The queried data structure may be an eSNI Domain Name Correspondence List (EDCL), as discussed above. In some embodiments, the response may include multiple cleartext hostnames that may correspond to the encrypted hostname. That is, multiple hostnames may be associated with the destination network address. The packet filtering device may indicate that the encrypted hostname corresponds to one of the multiple hostnames associated with the destination network address. Additionally, there may be other domain names hosted at the destination network address that have domain names that may correspond to the ciphertext. However, these domain names may not be listed in the EDCL because either they are not in the CTI database or they do not support eSNI.

[0114] In another example, the packet filtering device may receive a DNS query request from the first device and may receive a corresponding DNS query response from the DNS. The DNS query request and / or response may be received prior to receiving the plurality of packets. The DNS query request and / or response may be stored in a data structure. In response to receiving the plurality of packets, the packet filtering device may query the data structure to determine a cleartext hostname based on receiving the plurality of packets having the encrypted hostname from the first device. In this regard, the packet filtering device may determine that the encrypted hostname corresponds to the cleartext hostname that was the subject of the DNS query. do.

[0115] In some embodiments, the packet filtering device may determine a destination network address associated with the plurality of packets. In the above embodiments, the packet filtering device may query the data structure to determine a cleartext hostname associated with the encrypted hostname using the destination network address. In response to the query, the packet filtering device may receive a response that the destination network address could not be found in the data structure. The packet filtering device may transmit the response to the first device. The response may request a retransmission of the plurality of packets having the cleartext hostname (e.g., an unencrypted Server Name Indication (SNI)). The packet filtering device may receive a retransmission of the plurality of packets having the cleartext hostname (e.g., an SNI).

[0116] In step 1140, the packet filtering device may determine whether the cleartext hostname matches one or more threat indicators. The determination may be based on at least one of the following: a cleartext hostname decrypted from an encrypted server name indication (eSNI) value, a cleartext hostname associated with a destination network address, a DNS query, etc. As discussed above, the multiple cleartext hostnames may be associated with one or more threat indicators. As discussed above, for example, if multiple domains are hosted on a network destination address, the multiple cleartext hostnames may be determined from ciphertext including the encrypted server name indication (eSNI) value. In this regard, the packet filtering device may compare each of the multiple hostnames with one or more threat indicators. If one of the multiple cleartext hostnames is associated with one or more threat indicators, the packet filtering device may determine that the multiple packets are associated with one or more threat indicators. If the cleartext hostname does not match at least one of the one or more threat indicators, the packet filtering device may forward the multiple packets toward their destination in step 1150. In some embodiments, allowing the communications to proceed toward their destination may enable a secure communications channel (e.g., TLS) to be established between the first device and the hostname. If the cleartext hostname matches one or more threat indicators, the packet filtering device may apply a packet filtering action to the packets. The packet filtering action may include blocking the packets from continuing toward their intended destination. Additionally or alternatively, the packet filtering device may allow the packets to continue toward their intended destination while forwarding copies of the packets to the first proxy system for monitoring. Additionally or alternatively, the packet filtering device may forward the packets to a second proxy for further processing and / or analysis.

[0117] In some instances, enterprise hosts may be required to use encrypted hostnames when communicating with destinations that support ciphertext containing encrypted Server Name Indicator (SNI) values. Figure 12 illustrates one embodiment of a process 1200 for enforcing a policy using encrypted hostnames, according to one or more embodiments described herein. Some or all of the steps of process 1200 may be performed using one or more computing devices, such as packet security gateway 120.

[0118] In step 1210, the packet filtering device may receive one or more policies, such as those described above with respect to Figure 9. The packet filtering device may be configured with multiple packet filtering rules.

[0119] In step 1220, the packet filtering device may receive a first plurality of packets from the first device intended for a destination. The first plurality of packets may be associated with a communication or message, such as a ClientHello message. The first plurality of packets may include a clear text hostname.

[0120] In step 1230, the packet filtering device may determine whether the destination supports eSNI. For example, the packet filtering device may query a domain name service to determine whether an entry for the destination includes a public key. If the entry includes a public key, the packet filtering device may determine that the destination supports eSNI. Additionally or alternatively, the packet filtering device may query a data structure (e.g., a table, a database, etc.) to determine whether the destination supports eSNI. The packet filtering device may determine that the destination supports eSNI if an entry for the destination exists in the data structure. If the destination does not support eSNI, the packet filtering device may forward the plurality of packets to the destination in step 1235. The plurality of packets may include one or more communications associated with creating a secure communication channel (e.g., TLS) between the first device and the destination. If the destination supports eSNI, the packet filtering device may transmit a message including an indication that the first device uses eSNI in step 1240.

[0121] At step 1250, the packet filtering device may receive a second plurality of packets from the first device intended for the destination. The second plurality of packets may include ciphertext (e.g., eSNI ciphertext) including an encrypted Server Name Indication (SNI) value. In some embodiments, the packet filtering device may perform the analysis discussed above with respect to FIG. 11 to determine the cleartext hostname and whether the cleartext hostname is associated with one or more threat indicators. The policy enforcement and filtering aspects may be performed simultaneously or sequentially. In some embodiments, the packet filtering device may store the cleartext hostname from the first plurality of packets and correlate the cleartext hostname with the eSNI ciphertext in the second plurality of packets. As described above, if the destination is not associated with one or more threat indicators, the packet filtering device may forward the second plurality of packets toward the destination at step 1260. Additionally or alternatively, the second plurality of packets may be forwarded in response to a determination that the second plurality of packets includes an encrypted SNI (e.g., eSNI ciphertext). The second plurality of packets may include one or more communications associated with creating a secure communications channel (eg, TLS) between the first device and a destination.

[0122] The packet filtering device may store one or more packets according to a policy, such as an enterprise policy (e.g., data retention policy, regulatory compliance policy, etc.), a law enforcement policy, or a privacy, protection, and retention (P3) policy. Figure 13 shows one embodiment of a process 1300 for storing packets. Some or all of the steps of the process 1300 may be performed using one or more computing devices, such as the packet security gateway 120.

[0123] In step 1310, the packet filtering device may receive one or more policies. The packet filtering device may be configured with a plurality of packet filtering rules. The one or more policies may include an enterprise communications policy, a privacy, protection and retention policy, a law enforcement policy, or the like. In step 1320, the packet filtering device may receive one or more policies. The packet filtering device may be configured with a plurality of packet filtering rules. The one or more policies may include an enterprise communications policy, a privacy, protection and retention policy, a law enforcement policy, or the like. The packet filtering device may receive a plurality of encrypted packets, each of which may include an encrypted hostname (e.g., an eSNI ciphertext). As described above, the packet filtering device may perform the analysis discussed above with respect to FIG. 11 to determine the cleartext hostname and whether the cleartext hostname is associated with one or more threat indicators.

[0124] In step 1330, the packet filtering device may decrypt the encrypted packets to obtain cleartext packets. The packet filtering device may forward the encrypted packets to a (transparent) TLS man-in-the-middle (MITM) proxy function. The MITM proxy function may decrypt the TLS-secured application session, inspect the session in the clear, re-encrypt the session, and forward the TLS-secured session to its destination. In step 1340, the packet filtering device (e.g., MITM proxy function) may inspect (e.g., examine) the cleartext packets. In some embodiments, the packet filtering device may extract a cleartext domain name corresponding to the eSNI ciphertext in the content of the session. In some cases, the packet filtering device may use the extracted cleartext domain name to perform the analysis discussed above with respect to FIG. 11.

[0125] In step 1350, the packet filtering device may determine whether to allow the multiple packets to be captured and stored. The determination may be based on policies such as an enterprise communications policy, a privacy, protection, and retention policy, a law enforcement policy, or the like. In this regard, the enterprise communications policy may require logging and / or archiving of communications to comply with regulatory schemes (i.e., HIPAA, Sarbanes-Oxley, etc.). In another embodiment, the law enforcement policy may be based on whether law enforcement has the authority to store the communications. If there is a basis to store the multiple packets, the packet filtering device may store copies of the multiple decrypted packets in step 1360. After the decrypted packets are stored, the process 1300 may proceed to step 1370. If the multiple decrypted packets are not permitted to be stored or after storing the decrypted packets, the packet filtering device may forward the multiple encrypted packets to its destination. As described above, the multiple encrypted packets may enable a secure communication channel (e.g., TLS) between the first device and the destination.

[0126] The techniques described herein enable a packet filtering device to decrypt a clear-text hostname from an encrypted hostname. The clear-text hostname may be used to determine whether the network traffic is malicious in nature. This allows the packet filtering device to prevent malware from using a secure communication channel to bypass the packet filtering device when attempting to communicate with a malicious host. Furthermore, the techniques described herein enable the packet filtering device to monitor encrypted network traffic for known threats. This provides improved network monitoring and reduces the spread of malware. Additionally, enforcing eSNI when supported by the destination reduces threats of privacy violations, such as from malicious interception. Furthermore, the techniques described herein may make communications compliant with privacy laws and / or regulations. Finally, the techniques described herein may assist law enforcement in their monitoring of encrypted network traffic.

[0127] One or more features discussed herein may be implemented using one or more programs executed by one or more computers or other devices as described herein. The program modules may be embodied in computer usable or readable data and / or computer executable instructions, such as program modules. Program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. Modules may be written in source code programming languages ​​that are later compiled for execution, or may be written in scripting languages, such as (but not limited to) HTML or XML. Computer executable instructions may be stored in computer readable media, such as hard disks, optical disks, removable storage media, solid state memory, RAM, etc. The functionality of the program modules may be combined or distributed as desired. In addition, the functionality may be, in whole or in part, stored in firmware, or in hard disk drives, such as integrated circuits, field programmable gate arrays (FPGAs), etc. Certain data structures may be used to more effectively implement one or more features discussed herein, and such data structures are contemplated as falling within the scope of the computer-executable instructions and computer-usable data described herein. Various features described herein may be embodied as methods, computing devices, systems, and / or computer program products.

[0128] While the present disclosure has been described with respect to various embodiments, many additional modifications and variations will be apparent to those skilled in the art. In particular, any of the various processes described above may be performed in alternative orders and / or in parallel (on different computing devices) to achieve similar results in a manner that is more appropriate to the requirements of a particular application. It should therefore be understood that the present disclosure may be implemented otherwise than as specifically described without departing from the scope and spirit of the present disclosure. Although several examples have been described above, the features and / or steps of those examples may be combined, divided, omitted, rearranged, modified, and / or enhanced in any desired manner. The present disclosure should therefore be considered in all respects as illustrative and not restrictive. The scope of the present disclosure should therefore be determined not by the embodiments but by the appended claims and their equivalents.

Claims

1. receiving, by a packet filtering device, one or more policies including a plurality of packet filtering rules, the plurality of packet filtering rules being generated based on one or more network threat indicators including a plurality of domain names associated with one or more threats; receiving a plurality of packets from a first device, the plurality of packets including ciphertext that includes an encrypted Server Name Indication (eSNI) value; determining whether a cleartext hostname is resolvable from the ciphertext without decrypting the ciphertext; determining whether the cleartext hostname matches at least one domain name of the plurality of domain names associated with one or more threats based on a determination that the cleartext hostname is resolvable from the ciphertext; and applying a packet filtering operation to the plurality of packets based on a determination that the cleartext hostname matches a first domain name indicated by a first packet filtering rule of a plurality of packet filtering rules.

2. determining a destination network address associated with the plurality of packets; querying a data structure using the destination network address to determine a cleartext hostname associated with the ciphertext; 2. The method of claim 1, further comprising: receiving a response based on a query to the data structure, the response including a hostname of the plaintext associated with the ciphertext.

3. determining a destination network address associated with the plurality of packets; querying a data structure using the destination network address to determine a cleartext hostname associated with the ciphertext; 2. The method of claim 1, further comprising: receiving a response based on a query to the data structure, the response including a plurality of host names associated with the destination network address, the plurality of host names including the clear-text host name.

4. determining a destination network address associated with the plurality of packets; querying a data structure using the destination network address to determine a cleartext hostname associated with the ciphertext; receiving a response based on a query to the data structure that the clear-text host name cannot be resolved from the destination network address; sending a response to a first device that sent the plurality of packets, together with a clear Server Name Indication (SNI), indicating a retransmission of the plurality of packets; 2. The method of claim 1, further comprising the step of: receiving retransmissions of a plurality of packets including the cleartext SNI.

5. receiving a DNS query request and an associated DNS query response prior to receiving the plurality of packets; storing the DNS query in a data structure; and querying the data structure to determine a hostname of the cleartext based on receiving a plurality of packets including the ciphertext from the first device.

6. The packet filtering operation includes blocking the packets from continuing toward their intended destination, and further comprising:

10. The method of claim 1, further comprising: sending a response to the plurality of packets to the first device, wherein the response comprises at least one of a TCP Reset (RST) message or a TLS handshake proxy message.

7. receiving a second plurality of packets, the second plurality of packets including a second ciphertext that includes a second eSNI value; determining whether a second plaintext hostname is resolvable from the second ciphertext; determining whether the second plaintext hostname matches at least one domain name of a plurality of domain names associated with one or more threats based on a determination that the second plaintext hostname is resolvable from the second ciphertext; 2. The method of claim 1, further comprising allowing the second plurality of packets to continue toward an intended destination based on a determination that the second cleartext hostname does not match a domain name indicated by any of the plurality of packet filtering rules.

8. 8. The method of claim 7, wherein the second plurality of packets includes one or more communications for creating a secure communications channel with the intended destination.

9. The method of claim 1 , wherein the packet filtering device is at a boundary that is an interface between a protected network and an unprotected network.

10. 2. The method of claim 1, wherein the packet filtering operation includes at least one of the following: blocking said plurality of packets from continuing towards their intended destination; allowing the packets to continue to their intended destination and forwarding a copy of the packets to a first proxy for monitoring; or Forwarding the plurality of packets to a second proxy.

11. one or more processors; When executed by the one or more processors, the packet filtering device and a memory storing instructions for carrying out the method according to any one of claims 1 to 10.

12. A non-transitory computer readable medium having stored thereon instructions which, when executed, cause a packet filtering device to perform the method of any one of claims 1 to 10.

13. receiving, by a packet filtering device, intelligence data from a server external to a network protected by the packet filtering device, the intelligence data including one or more domain names; receiving, by the packet filtering device, a plurality of encrypted packets from a first device, the plurality of encrypted packets including an encrypted Server Name Indication (eSNI) value; determining whether a plaintext hostname is resolvable from the eSNI value; determining whether the clear-text hostname corresponds to one or more domain names based on a determination that the clear-text hostname is resolvable from the eSNI value; querying a data structure to determine whether law enforcement is authorized to intercept traffic corresponding to the cleartext hostname; and storing the plurality of encrypted packets in a lawful intercept database based on a determination that the cleartext hostname corresponds to the one or more domain names and based on a determination that the law enforcement has authority to intercept traffic corresponding to the cleartext hostname.

14. The method of claim 13 , wherein the plurality of encrypted packets is associated with establishing a secure communications channel.

15. 14. The method of claim 13, wherein the plurality of encrypted packets associated with establishing a secure communication channel includes at least one of a ClientHello message or one or more handshake messages.

16. 14. The method of claim 13, wherein the packet filtering device resides at an interface or border between a protected network and an unprotected network.

17. 14. The method of claim 13, wherein the intelligence data further comprises at least one of the following: (a) one or more user identifiers; (b) one or more host identifiers;

18. 20. The method of claim 17, wherein determining whether a clear-text hostname is resolvable from the eSNI value further comprises the steps of: decrypting, by a proxy function of the packet filtering device, the plurality of encrypted packets to obtain a plurality of plaintext packets after one or more communications have been exchanged to establish a secure communication channel; and inspecting the plurality of plaintext packets to determine one or more first user identifiers within the plurality of plaintext packets, wherein storing the plurality of encrypted packets in the lawful intercept database is further based on the one or more first user identifiers corresponding to the one or more user identifiers indicated in the intelligence data.

19. 20. The method of claim 17, wherein the step of determining whether the clear-text hostname is resolvable from the eSNI value further comprises the steps of: decrypting the encrypted packets to obtain a plurality of plaintext packets after one or more communications have been exchanged to establish a secure communication channel by a proxy function of the packet filtering device; and inspecting the plurality of plaintext packets to determine one or more first host identifiers within the plurality of plaintext packets, wherein storing the plurality of encrypted packets in the lawful intercept database is further based on the one or more first host identifiers corresponding to one or more host identifiers indicated in the intelligence data.

20. receiving a second plurality of encrypted packets, the second plurality of encrypted packets including a second eSNI value; determining whether a second clear-text hostname is resolvable from the second eSNI value; determining whether the second plaintext hostname corresponds to one or more domain names based on a determination that the second plaintext hostname is resolvable from the second eSNI value; querying the data structure to determine whether law enforcement is authorized to intercept traffic corresponding to the second cleartext hostname; 14. The method of claim 13, further comprising the step of forwarding the second plurality of encrypted packets to an intended destination based on a determination that law enforcement does not have authority to intercept traffic corresponding to the second cleartext hostname.

21. decrypting the encrypted packets to obtain a plurality of plaintext packets after one or more communications have been exchanged to establish a secure communication channel by a proxy function of the packet filtering device; 14. The method of claim 13, further comprising: storing the plurality of cleartext packets in a lawful intercept database based on a determination that the cleartext hostname corresponds to the one or more domain names and based on a determination that law enforcement is permitted to intercept traffic corresponding to the cleartext hostname.

22. 14. The method of claim 13, wherein the data structure comprises at least one of the following: Database; Table ; A hash table; or eSNI Domain Name Conformance List (EDCL).

23. one or more processors; and a memory storing instructions which, when executed by said one or more processors, cause the packet filtering device to perform a method according to any one of claims 13 to 22.

24. A non-transitory computer readable medium comprising instructions which, when executed, cause a packet filtering device to perform the method of any one of claims 13 to 22.

25. receiving, by the packet filtering device, intelligence data from a server external to a network protected by the packet filtering device, the intelligence data including one or more domain names; receiving, by the packet filtering device, a plurality of encrypted packets from a first device, the plurality of encrypted packets including an encrypted Server Name Indication (eSNI) value; decrypting the encrypted packets to obtain a plurality of plaintext packets after one or more communications are exchanged to establish a secure communication channel by a proxy function of the packet filtering device; inspecting the plurality of cleartext packets to determine whether a cleartext hostname associated with an eSNI value corresponds to the one or more domain names; querying the data structure to determine whether law enforcement is authorized to intercept traffic corresponding to the cleartext hostname; and storing the plurality of cleartext packets in a lawful intercept database based on a determination that the cleartext hostname corresponds to the one or more domain names and based on a determination that law enforcement is permitted to intercept traffic corresponding to the cleartext hostname.

26. re-encrypting the plaintext packets using a proxy function of the packet filtering device; 26. The method of claim 25, further comprising the step of: forwarding the re-encrypted packets to an intended destination.

27. receiving a second plurality of encrypted packets, the second plurality of encrypted packets including a second eSNI value; decrypting, by the proxy function, the second plurality of encrypted packets to obtain a second plurality of plaintext packets; inspecting the second plurality of cleartext packets to determine whether a second cleartext hostname associated with the second eSNI value corresponds to one or more domain names; querying said data structure to determine whether law enforcement is authorized to intercept traffic corresponding to the cleartext hostname; 26. The method of claim 25, further comprising: forwarding the second plurality of encrypted packets to an intended destination based on a determination that law enforcement does not have authority to intercept traffic corresponding to the second cleartext hostname.

28. A packet filtering device comprising one or more processors and a memory storing instructions which, when executed by the one or more processors, cause the packet filtering device to perform a method according to any one of claims 25 to 27.

29. A non-transitory computer readable medium comprising instructions which, when executed, cause a packet filtering device to perform the method of any one of claims 25 to 27.

Images