Method and system for efficient encrypted SNI filtering for network security applications

Abstract

The present application relates to methods and systems for efficient encrypted SNI filtering for network security applications. The packet filtering systems described herein can be configured to filter a filtered packet having an encrypted hostname in accordance with one or more packet filtering rules. The packet filtering systems can resolve a plaintext hostname from ciphertext that includes an encrypted server name indication (eSNI) value. The packet filtering systems can resolve the plaintext hostname using a variety of techniques. Once the plaintext hostname is resolved, the packet filtering systems can then use the plaintext hostname to determine whether the packet is associated with one or more threat indicators. If the packet filtering systems determine that the packet is associated with one or more threat indicators, the packet filtering systems can apply a packet filtering operation associated with the packet filtering rules to the packet.

Description

[0001] This application is a divisional application of the application with the application date of 2021-07-14, the application number of 202110795885.9, and the invention name of "Method and system for efficient encrypted SNI filtering for network security applications". TECHNICAL FIELD

[0002] Aspects described herein generally relate to computer hardware and software and network security. In particular, one or more aspects of the present disclosure generally relate to computer hardware and software for efficient packet filtering of transport layer security (TLS) handshake messages containing ciphertext corresponding to server name indication (SNI) (e.g., encrypted SNI (eSNI)) values related to network security applications and, more generally, network communication policy enforcement applications. BACKGROUND

[0003] With the continuous development of the information age, network security is becoming increasingly important. Network threats / attacks can take many forms (e.g., unauthorized requests or data transfers, viruses, malware, large amounts of traffic intended to flood resources (e.g., DDoS), etc.). Many of these threats use the Internet to access and attack enterprise computer resources and / or assets. For example, enterprise hosts, such as desktop computers, mobile devices, pre-installed or cloud enterprise application servers, public-facing web servers, etc., can be directly connected (e.g., attached) to a private network (e.g., TCP / IP network) owned and / or operated and managed by an enterprise, such as a business enterprise, a government, a nation, etc. These enterprise networks, in turn, are directly connected to the Internet, such that the enterprise's hosts can access, for example, other publicly addressed Internet-attached hosts (e.g., public-facing web servers, application servers, etc.). However, in some cases, an enterprise host can be accessing a malicious Internet-attached host or Internet host, for example, when an operator / user of the enterprise host has clicked on a phishing email link on a social engine that communicates with the malicious Internet host. In other cases, an enterprise host can be communicating with an Internet host in violation of the enterprise's network communication policies.

[0004] An enterprise can attempt to protect its network from malicious actors, or otherwise enforce network communication policies, for example, by installing network packet filtering devices at a 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) across the boundary. These packet filtering devices can determine whether the communications are malicious in nature, or otherwise violate the enterprise communication policies. If so, then policies are enforced to protect the enterprise network from threats or disruptions (e.g., by dropping associated IP packets to block the communications). Enterprises can also use such network devices to enforce the enterprise’s communication policies, for example, by controlling and / or monitoring access to certain Internet hosts. One method of enforcing such policies can be to have the network packet filtering devices inspect or filter in-transit packets of the communications that are associated with packet filtering rules in the policies for instances of domain names (e.g., fully qualified domain names (FQDNs)), such as a malicious adware site web. If a match is found between the packets and the rules, then the network packet filtering devices can drop the packets. The popular HTTP protocol used for many web, e-commerce, social media, etc. communications often includes such Internet host domain names in HTTP messages. Filtering in-transit packets for domain names included in HTTP messages is one policy enforcement technique. Similarly, other application layer protocols (e.g., DNS, SMTP, SIP, etc.) can include domain names that can be used during policy enforcement. Enterprise communication policies can also include privacy protection & preservation (P3) policies that can be defined by the enterprise itself, or by external entities (e.g., HIPAA, PCI DSS, etc.) that have regulatory or compliance authority over the enterprise, for example. Enterprise communication policies can also include support for law enforcement (LE) applications, such as lawful intercept.

[0005] Network traffic in transit can be protected by encryption, for example, using the Transport Layer Security (TLS) protocol. A secure, encrypted connection or tunnel can first be established between two hosts connected over a network (e.g., a TCP / IP network) using the TLS handshake protocol. The TLS record protocol can be used to securely transmit application layer data, including communications over the tunnel. When an HTTP session is protected by TLS, the combination is labeled "HTTPS" and is generally considered an extension of HTTP. The application layer of an HTTPS packet in transit contains an encrypted HTTP message (which is encapsulated in a TLS record protocol packet). An observer cannot read the cleartext HTTP message contained in an HTTPS packet in transit, nor any domain names. This can protect the HTTP session from malicious parties that can be eavesdropping, but can also hinder non-malicious / legitimate packet filtering devices and associated applications from reading any domain names contained in the HTTP message. This can hinder enterprises from enforcing their communication policies and protecting their networks.

[0006] However, the TLS handshake protocol ClientHello message can contain a (cleartext) domain name or hostname related to the application (e.g., HTTP) session to be protected / encrypted in the Server Name Indication (SNI) extension (RFC 6066) of the ClientHello message. Enterprise packet filtering devices and associated applications, as well as eavesdroppers, can continue to read and possibly act on the domain name associated with the TLS-secured session by examining the cleartext SNI field of the ClientHello message contained in a packet in transit. However, to further secure TLS, one or more extensions to TLS are being developed to support encryption of the SNI value in transit. Skilled artisans will generally understand such extensions and related techniques as "ESNI." The primary purpose of ESNI is to reduce the risk of eavesdropping on domain names by malicious parties. However, when ESNI is used, enterprises that protect their networks and enforce their communication policies by reading and possibly acting on the cleartext domain name contained in the SNI extension of a packet in transit can no longer do so, as the domain name is encrypted.

[0007] Thus, enterprises need a way to protect their networks and enforce communication policies using cleartext (unencrypted) domain names when their hosts use ESNI when establishing TLS-secured communications. SUMMARY

[0008] The following presents a simplified summary in order to provide a basic understanding of some aspects of the present disclosure. This summary is not an extensive overview of the present disclosure and is not intended to identify key or critical elements of the present disclosure. The following summary merely presents some concepts of the present disclosure in a simplified form as a prelude to the more detailed description below.

[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, for example, in some cases where domain names contained in packets in transit are encrypted (e.g., encrypted server name indication (eSNI) extension in TLS handshake protocol messages, encrypted TLS protocol messages, etc.). A cybersecurity application can detect encrypted hostnames in one or more packets. Based on detecting encrypted hostnames (e.g., domain names), the cybersecurity application can resolve plaintext hostnames (e.g., domain names) corresponding to the encrypted hostnames. The cybersecurity application can use the plaintext hostnames to determine whether the plaintext hostnames are associated with any communication policies. For example, a cybersecurity application protecting a network from threats identified in a report (e.g., a network threat intelligence report) can use the plaintext hostnames to determine whether the plaintext hostnames are associated with one or more threat indicators. When the plaintext hostnames are associated with one or more threat indicators, the cybersecurity application can apply one or more packet filtering rules to the one or more packets. By resolving plaintext hostnames from encrypted hostnames, the cybersecurity application can, for example, protect enterprise networks from threats (e.g., internet threats) and privacy breaches (such as malicious eavesdropping), enforce enterprise communication policies, and / or assist law enforcement.

[0010] There are many possible variations of the above process, some of which are detailed in the DETAILED DESCRIPTION section below.

[0011] The present application provides the following:

[0012] 1) A method comprising:

[0013] receiving, by a packet filtering device, one or more threat indicators from an intelligence provider, wherein the one or more threat indicators comprise a plurality of domain names associated with one or more threats;

[0014] determining a plurality of packet filtering rules associated with each of the one or more threat indicators, wherein the one or more threat indicators comprise matching criteria for the plurality of packet filtering rules;

[0015] receiving a plurality of packets from a first device, wherein the plurality of packets comprise ciphertext comprising an encrypted server name indication (eSNI) value;

[0016] determining whether a plaintext hostname can be resolved from the ciphertext;

[0017] based on determining that the plaintext host name can be resolved from the ciphertext, determining whether the plaintext host name matches at least one of the one or more threat indicators; and

[0018] based on determining that the plaintext host name matches at least one of the one or more threat indicators, applying a packet filtering operation associated with one or more of the plurality of packet filtering rules to the plurality of packets, wherein the packet filtering operation comprises at least one of: blocking the plurality of packets from continuing toward their intended destination, allowing the plurality of packets to continue to their intended destination, and forwarding a copy of the plurality of packets to a first proxy for monitoring, or forwarding the plurality of packets to a second proxy.

[0019] 2) The method of 1), wherein the packet filtering operation comprises blocking the plurality of packets from continuing toward their intended destination, and the method further comprises:

[0020] sending a response to the plurality of packets to the first device, wherein the response comprises at least one of: a TCP RST message or a TLS handshake proxy message.

[0021] 3) The method of 1), wherein the packet filtering device resides at a boundary between a protected network and an unprotected network.

[0022] 4) The method of 1), wherein determining whether the plaintext host name can be resolved from the ciphertext further comprises:

[0023] determining a destination network address associated with the plurality of packets;

[0024] querying a data structure using the destination network address to determine the plaintext host name associated with the ciphertext; and

[0025] based on querying the data structure, receiving a response containing the plaintext host name associated with the ciphertext.

[0026] 5) The method of 4), wherein the data structure comprises an eSNI Domain Name Correspondence List (EDCL).

[0027] 6) The method of 1), wherein determining whether the plaintext host name can be resolved from the ciphertext further comprises:

[0028] determining a destination network address associated with the plurality of packets;

[0029] querying a data structure using the destination network address to determine the plaintext host name associated with the ciphertext; and

[0030] based on querying the data structure, receiving a response that the destination network address cannot be located in the data structure;

[0031] 7) The method of 1), wherein determining whether the plaintext host name can be resolved from the ciphertext further comprises:

[0032] receiving, by the packet filtering device and prior to receiving the plurality of packets, a DNS query request and an associated DNS query response;

[0033] storing the DNS query in a data structure; and

[0034] based on receiving the plurality of packets with the ciphertext from the first device, querying the data structure to determine the plaintext host name.

[0035] 8) The method of 1), wherein determining whether the plaintext host name can be resolved from the ciphertext further comprises:

[0036] determining a destination network address associated with the plurality of packets;

[0037] querying a data structure using the destination network address to determine the plaintext host name associated with the ciphertext;

[0038] based on querying the data structure, receiving a response that the destination network address cannot be located in the data structure;

[0039] transmitting a response to a first device that sent the plurality of packets, the response indicating a retransmission of the plurality of packets with a plaintext server name indication (SNI); and

[0040] receiving, by the packet filtering device, the retransmission of the plurality of packets with the plaintext SNI.

[0041] 9) The method of 1), comprising:

[0042] receiving, by the packet filtering device, a second plurality of packets, wherein the second plurality of packets includes a second ciphertext, the second ciphertext including a second eSNI value;

[0043] determining whether a plaintext host name can be resolved from the ciphertext;

[0044] based on determining that the plaintext host name can be resolved from the ciphertext, determining whether the plaintext host name matches at least one of the one or more threat indicators; and

[0045] allowing the second plurality of packets to continue toward their intended destination based on a determination that the plaintext host name does not match at least one of the one or more threat indicators.

[0046] 10) The method of 9), wherein the second plurality of packets comprises one or more communications associated with creating a secure communication channel between the intended destination and the first device.

[0047] 11) A method comprising:

[0048] receiving, by a packet filtering device from a first device, a first plurality of packets intended for a destination, wherein the first plurality of packets comprises a plaintext host name;

[0049] determining whether the destination supports ciphertext comprising an encrypted server name indication (eSNI) value;

[0050] transmitting, by the packet filtering device to the first device, a message comprising an indication for the first device to encrypt the first plurality of packets based on a determination that the destination supports ciphertext using the eSNI value;

[0051] receiving, by the packet filtering device from the first device, a second plurality of packets intended for the destination, wherein the second plurality of packets comprises ciphertext comprising the eSNI value; and

[0052] forwarding, by the packet filtering device to the destination, the second plurality of packets based on a determination that the second plurality of packets comprises ciphertext comprising the eSNI value.

[0053] 12) The method of 11), wherein the second plurality of packets comprises one or more communications associated with creating a secure communication channel between the first device and the destination.

[0054] 13) The method of 11), wherein determining whether the destination supports ciphertext comprising the eSNI value further comprises:

[0055] querying, by the packet filtering device, a domain name service to determine whether an entry for the destination comprises a public key; and

[0056] determining that the destination supports ciphertext comprising the eSNI value when the entry for the destination comprises a public key.

[0057] 14) The method of 11), wherein determining whether the destination supports ciphertext comprising the eSNI value further comprises:

[0058] querying, by the packet filtering device, a data structure to determine whether the destination supports ciphertext comprising the eSNI value; and

[0059] determining that the destination supports cipher including the eSNI value when an entry for the destination exists in the data structure.

[0060] 15) The method of 11), wherein transmitting the message including the indication of the cipher used by the first device further comprises:

[0061] determining that a policy indicates that cipher is to be used whenever a destination supports cipher including the eSNI value.

[0062] 16) The method of 11), comprising:

[0063] receiving, by the packet filtering device, a third plurality of packets from the first device intended for a second destination, wherein the third plurality of packets includes a second plaintext host name;

[0064] determining whether the second destination supports cipher including an eSNI value; and

[0065] based on determining that the second destination does not support cipher including the eSNI value, forwarding the third plurality of packets to the second destination.

[0066] 17) The method of 16), wherein the third plurality of packets includes one or more communications associated with creating a secure communication channel between the first device and the second destination.

[0067] 18) A method, comprising:

[0068] receiving, by a packet filtering device configured with a plurality of packet filtering rules, one or more policies;

[0069] receiving, by the packet filtering device, a plurality of encrypted packets, wherein the plurality of encrypted packets includes cipher including an encrypted server name indication (eSNI) value;

[0070] decrypting the plurality of encrypted packets to obtain a plurality of plaintext packets;

[0071] inspecting the plurality of plaintext packets;

[0072] determining whether the packet filtering device is permitted to capture and store the plurality of plaintext packets;

[0073] based on determining that the packet filtering device is permitted to capture and store the plurality of plaintext packets, storing a copy of the plurality of plaintext packets; and

[0074] Based on an inspection of the plurality of plaintext packets, applying packet filtering operations associated with one or more of the plurality of packet filtering rules to the plurality of encrypted packets.

[0075] 19) The method of 18), wherein the packet filtering operations comprise at least one of:

[0076] preventing the plurality of encrypted packets from continuing toward their intended destinations;

[0077] allowing the plurality of encrypted packets to continue to their intended destinations and storing copies of the plurality of plaintext packets; or

[0078] allowing the plurality of encrypted packets to continue to their intended destinations without storing copies of the plurality of plaintext packets.

[0079] 20) The method of 18), wherein the one or more policies comprise at least one of:

[0080] a corporate communications policy;

[0081] a privacy protection and preservation policy; or

[0082] a law enforcement policy. BRIEF DESCRIPTION OF DRAWINGS

[0083] The disclosure is described in example terms and is not limited by the drawings, in which like reference numerals represent similar elements and in which:

[0084] Figure 1 An illustrative environment for a TLS secure communication and associated enterprise network threat protection and policy enforcement system in accordance with one or more aspects of the disclosure is shown.

[0085] Figure 2 An illustrative efficient eSNI packet filtering gateway for enforcing network security applications in accordance with one or more aspects of the disclosure is shown.

[0086] Figure 3 A representative eSNI Domain Name Correspondence List (EDCL) that a network security application uses to determine correspondence between eSNI ciphertext and plaintext domain names is shown.

[0087] Figure 4A and Figure 4B A flowchart of an illustrative process for creating, distributing, and maintaining an EDCL is shown.

[0088] Figure 5A flow diagram illustrating an exemplary process for creating, distributing, and maintaining a policy comprised of grouping filter rules derived from a CTI database is shown.

[0089] Figure 6 A flow diagram illustrating an exemplary process for creating, distributing, and maintaining a DNS-ESNI set data structure containing elements that are eSNI-enabled DNS-registered domain names is shown.

[0090] Figure 7 A flow diagram illustrating an exemplary process for creating, distributing, and maintaining EDCLs, CTI-derived policies, and DNS-ESNI set data structures is shown.

[0091] Figure 8A and Figure 8B A method for configuring and operating an efficient eSNI gateway is shown in accordance with one or more examples described herein.

[0092] Figure 9 A method for configuring and operating an efficient eSNI gateway is shown in accordance with one or more aspects described herein.

[0093] Figure 10 A method for configuring and operating an efficient eSNI gateway is shown in accordance with one or more examples described herein.

[0094] Figure 11 An example of a process for determining whether encrypted network traffic is associated with one or more threats is shown.

[0095] Figure 12 An example of a process for performing a policy using encrypted hostnames is shown in accordance with one or more examples described herein.

[0096] Figure 13 An example of a method for storing packets is shown in accordance with one or more examples described herein. DETAILED DESCRIPTION

[0097] In the following description of various example embodiments, reference is made to the accompanying drawings which form a part hereof, and in which are shown by way of illustration various embodiments in which aspects of the disclosure can be practiced. It is to be understood that other embodiments can be utilized and structural and functional modifications can be made without departing from the scope of the present disclosure. Furthermore, the disclosure applies to other applications, protocols, and embodiments, as would be understood by one of ordinary skill in the art. It is to be understood that features mentioned herein can be combined, substituted, deleted, modified, or supplemented as would be understood by one of ordinary skill in the art.

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

[0099] The present disclosure describes techniques for network security applications that act on domain names contained in in-transit packets that make up a TLS secure communication when the domain names can be encrypted. Some network security applications of networks enforce TCP / IP communication policies composed of packet filtering rules that include plaintext domain names as rule matching criteria. If the domain names contained in in-transit packets are encrypted, for example, encrypted Server Name Indication (SNI) extension field values in TLS ClientHello messages, these policies cannot be enforced. Additionally or alternatively, network security applications can selectively enforce encrypted SNI usage, for example, to block eavesdropping associated with plaintext domain names.

[0100] Throughout this specification, the term "domain name" can 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. Those skilled in the art will appreciate the interchangeability of the term. Also, "domain name" can be used interchangeably with host name, fully qualified domain name (FQDN), and the like, the exact meaning being defined by the context. For example, a domain name observed in a structured field of an in-transit L2 / L3 packet can be a FQDN. Similarly, a domain name as a CTI indicator can also be a FQDN.

[0101] As used herein, encrypted server name indication (“eSNI”) can generally refer to techniques and logic associated with encrypted SNI, rather than to a particular protocol, implementation, or standard. Further, “eSNI ciphertext” can 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 communication channel between two or more parties. The one or more encrypted portions can include SNI values as well as other portions of the message (e.g., ClientHello message), including, for example, the entire message (e.g., ClientHello message). Applicants recognize that the eSNI protocol is currently being developed by the Internet Engineering Task Force (IETF), and it has not yet been finalized and / or categorized as part of a standard as to which portions of the message will be encrypted. Those of ordinary skill in the art will recognize that the processes, methods, techniques, devices, apparatuses, and / or systems described herein can be applied to detecting threats (e.g., internet threats), protecting enterprise networks, mitigating privacy leaks, enforcing enterprise communication policies, and / or assisting law enforcement in communications involving encrypted server name indication (eSNI), regardless of which portions of such communications are encrypted.

[0102] 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, where domain names contained in packets in transit of communications are encrypted. An application operating in-line (such as a network security application) and / or a packet filtering device in transit can detect when eSNI is used to encrypt domain names. Based on detecting use of eSNI, the application and / or packet filtering device in transit can determine the plaintext domain name corresponding to the eSNI ciphertext and enforce communication policies associated with the plaintext domain name.

[0103] Aspects of the present disclosure can also describe methods, devices, systems, and / or computer-readable media for protecting enterprise networks from threats (such as malicious eavesdropping) and enforcing enterprise communication policies, for example, where domain names contained in communications are not encrypted. A network security application operating in-line and / or a packet filtering device in transit can detect when eSNI is not used to encrypt domain names. The network security application and / or packet filtering device in transit can determine whether the relevant domain supports eSNI. If eSNI is supported, the network security application operating in-line and / or packet filtering device in transit can enforce communication policies associated with transmitting plaintext domain names, for example, by causing the communications to use eSNI if available.

[0104] Identification of communications associated with internet threats can utilize a database of CTI reports available from a number of cyber threat intelligence (CTI) provider organizations. These CTI reports can include indicators or indicators-of-compromise (IoCs), which are unique identifiers of internet hosts or internet host resources (e.g., services, application instances, etc.) associated with malicious activity. CTI indicators can include internet network addresses of resources, in the form of IP addresses, 5-tuples (host / resource identifiers specifying L3 host IP addresses, L4 ports, and / or related L3 protocol types), hostnames / domains, URIs, etc., that can be controlled and / or operated by a threat actor, or that can otherwise be associated with malicious activity. CTI indicators can also include identifiers of certificates and related certificate authorities used to secure certain TCP / IP communications (e.g., X.509 certificates used by the TLS protocol to secure HTTP intermediary sessions). In addition to threat indicators, CTI reports can also include additional information related to threats, such as threat types, threat attribution and threat actors, characteristic behaviors, attack targets, geolocation and geopolitical information, etc.

[0105] The present disclosure can describe methods, devices, systems, and / or computer-readable media for deriving packet filtering rules from domain name indicators received in CTI. The present disclosure can also describe methods, devices, systems, and / or computer-readable media for performing the derived packet filtering rules on packets including TLS secure communications (e.g., HTTPS communications). In this regard, an enterprise can receive CTI indicators by subscribing to a cyber threat intelligence provider (CTIP). The enterprise can create policies consisting of packet filtering rules derived from the CTI indicators, configure packet filtering devices using the policies, and protect its enterprise network from internet threats by performing the policies on in-transit packets crossing the network boundary.

[0106] The use of eSNI encryption domain names in TLS secure communications can be achieved through the joint participation of a communicating host and the Internet Domain Name System (DNS). That is, a first host (e.g., an HTTP client, such as a web browser application executing on an enterprise host) and a second host (e.g., an Internet-attached HTTP server, such as a web application server hosting a domain named www.web-domain-X.com) can support eSNI to establish TLS secure communications between the two hosts. The second host (e.g., a web server) can publish a public key in its associated DNS entry (e.g., www.web-domain-X.com). The client can use the public key to encrypt a domain name (e.g., www.web-domain-X.com) and other information (e.g., a ClientHello message, data and / or information in the ClientHello message, etc.) contained in, for example, an SNI extension. Prior to communicating with the second host (e.g., www.web-domain-X.com), the first host (e.g., an HTTP client) can issue a query to the DNS to obtain (e.g., retrieve, resolve) an IP address (e.g., 12.34.56.78 for www.web-domain-X.com) and the eSNI public key of the second host. The first host (e.g., an HTTP client) can establish a TCP connection to a well-known port (e.g., port 443 (HTTPS)) of 12.34.56.78. The first host can use the public key to encrypt the FQDN (e.g., www.web-domain-X.com) contained in an SNI extension. In some examples, in addition to the FQDN, the public key can be used to encrypt other data, such as a ClientHello message and / or data and information contained therein. After encrypting the FQDN and any additional data using the public key, the first host can insert the resulting eSNI ciphertext into a communication, such as a ClientHello message. The communication (e.g., a ClientHello message) can be encapsulated in a TCP packet with a destination port of 443. The TCP packet can be encapsulated in an IP packet with a destination IP address of 12.34.56.78. The IP packet can be sent (e.g., transmitted) to the second host (e.g., a web server) via a connection (e.g., a TCP connection). Upon receiving the ClientHello message, the second host (e.g., a web server) can use a private key (e.g., a secret key) associated with the public key to decrypt the ciphertext to obtain (e.g., determine) the plaintext domain (e.g., www.web-domain-X.com) of the second host (e.g., a domain) that the first host (e.g., a web browser) wants to communicate with.

[0107] Applications operating the packet filtering device can derive (e.g., determine) the plaintext domain name from the eSNI ciphertext by associating the L3 destination IP address of the in-transit packet (e.g., containing the ClientHello message) with the eSNI-related information. For example, a cybersecurity application operating the packet filtering device can associate a cyber threat intelligence (CTI) database of domain name indicators with the TCP / IP communication to identify potentially threatening communications and / or decide how to handle the identified potentially threatening communications (e.g., block / drop or allow / forward the communication). The CTI database can contain a plurality of domain names, and the contents of the CTI database can be dynamic. That is, new entries (e.g., domain names and any related information) can be added to the CTI database, and existing entries can be continually removed from the CTI database. The present disclosure describes packet filtering techniques that can be computationally efficient such that in-transit packets are not dropped due to buffer overflow and cybersecurity is not compromised due to lag. The applications and / or inline packet filtering devices described herein can filter in-transit L2 / L3 packets on a per-packet basis. That is, the L2 / L3 transparent device filters or applies packet filtering rules to each in-transit packet in the order of arrival (e.g., FIFO queuing) and determines a disposition / operation for each packet (e.g., block / drop, allow / forward, etc.) before filtering the next packet. It should be appreciated that a communication such as a ClientHello message can be segmented across multiple packets. As described herein, the per-packet processing can be applied to a communication such as a ClientHello message that is segmented across multiple packets.

[0108] An eSNI domain name correspondence list (EDCL) can be generated from a CTI database of domain names. The EDCL can be a data structure. A data structure can be a data organization, management, and / or storage format that enables efficient access and / or modification. A data structure can be a collection of data values, relationships among them, and / or functions or operations that can be applied to the data. In some examples, the data structure can be a two-dimensional table including at least two (2) columns labeled {IP-address, cti-esni-domain-names-list} that is uniquely indexed by IP address. In other examples, the data structure can be a database. To generate the EDCL, a DNS can be queried for each domain name (e.g., fully qualified domain name (FQDN)) in the CTI database. The DNS query can determine at least one of: an IP address of the domain name and whether the associated domain supports eSNI. Determining whether the domain supports eSNI can include querying for a resource record that includes an eSNI public key for encryption. If the associated domain supports eSNI, an entry (e.g., row) in the EDCL can be created and / or updated by placing the IP address in the IP address column and the domain name in the cti-esni-domain-names-list column. Due to virtual domain technology, multiple domain names can resolve to the same IP address, so there can be multiple domain names or domain name lists associated with each IP address in the EDCL. For exemplary purposes, assume for this summary example that there is only one domain name in the cti-esni-domain-names-list associated with the (unique) IP address in the EDCL. To quickly process in-transit packets to avoid buffer overflow and packet loss and to minimize packet transmission latency, the EDCL can be organized as an efficient data structure, such as a hash table, to support fast searching by IP address to check for the existence of an EDCL entry and return the list of domain names associated with the IP address.

[0109] When the (on-line) packet filtering device inspects an in-transit packet containing a ClientHello message with eSNI ciphertext, the packet filtering device can determine the plaintext domain name that the eSNI ciphertext corresponds to by extracting the destination IP address from the L3 packet and searching the EDCL for the destination IP address. If the destination IP address is not found in the EDCL, the network security application logic can decide to allow (e.g., forward) the packet to its destination because there is no CTI-based threat associated with the packet. If the destination IP address is found in the EDCL, the associated domain name can be the plaintext domain name that the eSNI ciphertext corresponds to. To determine how to handle the packet, the network security application can search one or more network security policies for a rule with packet matching criteria that correspond to the plaintext domain name, including a plurality of in-transit packet filtering rules (which are derived from a CTI database). The matching rule can indicate a packet disposition (e.g., allow / forward / pass or block / drop / refuse). The matching rule can also indicate additional (network protection) actions or packet transformation functions (PTFs) for the packet, such as logging, capturing, mirroring / redirection, forwarding to a proxy, spoof-tcp-rst, etc.

[0110] A plurality of domain names can be associated with a single IP address in the EDCL. For example, domain hosting services often host multiple domains on a single IP address. Some of these many domains can be located in a CTI database or other network security related database, such as a privacy protection database, law enforcement database, corporate usage policy database, etc. In addition, some of these domains can support eSNI. The plaintext domain name that the eSNI ciphertext corresponds to can not be unambiguously determinable from the associated IP address in the EDCL. The network security application can select among several different actions to disambiguate the plaintext domain name and / or otherwise mitigate potential threats. These actions can be based on enhanced EDCL information, additional efficient data structures, TLS messages, etc. For example, the network security application can: send a TCP RST to the client, which breaks the TCP connection and terminates the TLS handshake session; send a TLS message (e.g., a TLS alert protocol message with a "handshake failure" (code 40) alert) to the client, which terminates the TLS handshake session; send a TLS message to the client, which 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, which causes the client to send a plaintext SNI instead of an encrypted SNI; etc.

[0111] An application operating the packet filtering device can inspect packets in transit containing a ClientHello message, determine that eSNI is being used, and determine that the L3 destination IP address of the packets is in the EDCL. The eSNI ciphertext can correspond to a (plaintext) domain name of interest, such as a domain name contained in a CTI database. There are several actions that the application can take to disambiguate the plaintext domain name and / or otherwise mitigate the threat. For example, the application can drop the packets containing the ClientHello message and spoof (transparently) the intended host of the ClientHello message.

[0112] Additionally or alternatively, the security application can forward the ClientHello message to a (transparent) intermediary TLS man-in-the-middle (MITM) proxy function. The MITM proxy function can decrypt the TLS secure application session, inspect the session in the clear, re-encrypt the session, and forward the TLS secure session to its destination. While the MITM proxy function can not be able to decrypt the eSNI ciphertext, the MITM proxy function can inspect (e.g., investigate) the decrypted application session and extract the plaintext domain name corresponding to the eSNI ciphertext from the session content. For example, an HTTPS session can be decrypted by the MITM proxy function to expose a plaintext HTTP session. In this regard, HTTP method requests, such as GET, POST, PUT, etc., can contain domain names. The security application can extract the plaintext domain name from the plaintext and filter the plaintext domain name through any policies performed by the packet filtering device.

[0113] In another example, a security application can operate or otherwise access a system DNS-QUERY-TRACKER, which can be used to disambiguate plaintext domain names corresponding to eSNI values. The DNS-QUERY-TRACKER system can monitor DNS queries originating from enterprise hosts that can also initiate TLS sessions through the packet filtering device. The DNS-QUERY-TRACKER system can store data records associated with any DNS queries for eSNI-enabled domain names in, for example, a table (e.g., a hash table) and / or a database. Each record can include an IP address of a host that initiated the DNS query, a domain name, an IP address resolved for the domain name, and / or a time of the query. The DNS-QUERY-TRACKER system can provide an interface to the table and / or database that stores records through a function call that accepts an IP address as input and returns one or more records corresponding to the input IP address. In some examples, the DNS-QUERY-TRACKER can be configured to account for DNS protocols that use encryption, such as DNS over HTTPS (DoH) (e.g., RFC 8484) and / or DNS over Transport Layer Security (DoT) (e.g., RFC 7858). These protocols can encrypt DNS communications, such as DNS query requests and / or replies. That is, the configuration can be such that the DNS-QUERY-TRACKER system can access plaintext (and / or cleartext) of DoH and DoT communications.

[0114] Before initiating a TLS secure session (e.g., HTTPS communication) associated with a domain name, an enterprise host can 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 can be used to encrypt the domain name and other data and / or information included in a ClientHello message. If the public key (e.g., eSNI public key) exists, the DNS-QUERY-TRACKER system can insert a record for the public key (e.g., eSNI public key) in its table and / or database. A packet filtering device can receive an L3 packet that includes a ClientHello message with eSNI ciphertext. A security application executing on the packet filtering device can extract the destination IP address from the packet and query the DNS-QUERY-TRACKER to obtain one or more records indexed by the destination IP address. The query can be time limited. That is, the record can have been created and / or updated within a predetermined time of receiving the L3 packet. The record matching the ClientHello message time and / or the original host IP address to the source IP address of the L3 packet can contain the plaintext domain name associated with the eSNI ciphertext. The security application can filter the plaintext domain name by any policy executed by the packet filtering device. The above-described DNS-QUERY-TRACKING system and method can be used in conjunction with or as an alternative to the EDCL-based system and method for estimating the plaintext domain name corresponding to the eSNI ciphertext.

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

[0116] In a privacy protection and preservation (P3) application, the database can be a set of domain names associated with encrypted communication sessions (e.g., HTTPS sessions) that should not be decrypted and stored to protect and preserve privacy. When a TLS secure session uses eSNI, an EDCL can be generated from the P3 database of domain names to determine whether a session is associated with a plaintext domain name in the P3 database. If the domain name is associated with a domain name in the P3 database, the application can take appropriate action to ensure that the session is not decrypted and / or stored.

[0117] In some examples, an enterprise can seek to enforce an eSNI usage policy to mitigate and / or prevent eavesdropping by malicious actors. The eSNI usage policy enforcement can be used in conjunction with the EDCL-based eSNI security functionality described above and / or the DNS-QUERY-TRACKER-based security functionality. In addition to accessing the EDCL, the application can also access, for example, a data structure named DNS-ESNI that includes one or more elements of domain names registered in DNS that are associated with domains that support eSNI. For example, an application operating a packet filtering device can detect a ClientHello message with an SNI value (e.g., a (plaintext) domain name) that is not in the CTI database but has an entry in the DNS-ESNI data structure. When the domain name can be sent as ciphertext, it is sent in unencrypted form. Additionally or alternatively, the application can query DNS to resolve the domain name and determine whether the domain supports eSNI. Based on the response to the query, the application can determine whether the domain name is an element or member of the abstract or actual DNS-ESNI data structure. If the application determines that the domain supports eSNI, the application can drop the packet containing the ClientHello message (with plaintext domain name), spoof / transparencly proxy the host to which the ClientHello message is being sent, and / or send a TLS message to the client to cause the client to use an encrypted SNI instead of a plaintext SNI.

[0118] In some examples, an enterprise can seek to enforce an eSNI usage policy that implements eSNI for TLS sessions. That is, enterprise hosts can only access domains that support eSNI. An application operating a packet filtering device can enforce such a policy by, for example, 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 can be applied in a system that performs rule-based network-threat detection, such as a system that uses the technology disclosed in Applicant’s U.S. Serial No. 14 / 757,638 (now U.S. Patent No. 9,917,856), entitled “Rule-Based Network-Threat Detection for Encrypted Communications,” filed December 23, 2015, the entire contents of which are incorporated by reference herein.

[0119] Figure 1A system 100 for eSNI filtering for network security applications is illustrated. System 100 may include network A 102 and network B 104, which may be connected via one or more network links 106 providing Internet access and / or interconnection. System 100 may also include one or more hosts. As used herein, a “host” (or “multiple hosts”) means any type of network device or node or computing device connected to the network with an L3 network address assigned to its network interface. One or more hosts may be computing devices and / or network devices such as servers, desktop computers, laptop computers, tablet computers, mobile devices, smartphones, routers, gateways, proxies, firewalls, switches, access points, etc. In some examples, some computing devices may have network interfaces without network addresses, such as PSG / ESNI G / W 120. Computing devices without network addresses may not be considered hosts. Network interfaces without assigned network addresses may be considered “transparent” relative to the network level (e.g., L3 and / or L2).

[0120] Network A 102 may include one or more networks (e.g., local area network (LAN), wide area network (WAN), virtual private network (VPN), software-defined network (SDN), or combinations thereof) associated with one or more individuals and / or entities (e.g., governments, companies, service providers, etc.). Network B 104 may include one or more networks (e.g., LAN, WAN, VPN, SDN, or combinations thereof) that connect and / or interconnect Network A 102 with one or more other networks (not shown). For example, Network B 104 may include the Internet or a similar network and / or portions thereof.

[0121] like Figure 1 As shown, network A 102 may include hosts 110, 112, and / or 114, and one or more packet filtering network gateway devices, such as packet security gateways (PSGs). Hosts 110, 112, and / or 114 may be configured to act as TLS clients and / or TLS tunneling endpoints. The PSG may include eSNI-Gateway (ESNI-G / W) 120 functionality for handling in-transit packets associated with TLS secure communication that can utilize eSNI. In some embodiments, eSNI-Gateway network devices (e.g., ESNI-G / W 120 or PSGs combined with them) may not be assigned L3 and / or L2 network addresses to the network interfaces on which in-transit packets enter and / or leave the network to which the eSNI-Gateway operates. The eSNI gateway (and the combined PSG) may be L3 transparent.

[0122] Similarly, network B 104 can include or provide network access to hosts 130, 131, and / or 139. Hosts 130, 131, and / or 139 can be configured to function as TLS servers and / or TLS tunnel termini. Hosts 130, 131, and / or 139 can host one or more domains and can register associated domain names with a DNS (e.g., DNS 160). Hosts 130, 131, and / or 139 can also associate eSNI support to domains on the internet DNS (e.g., create resource records for domains that include eSNI public keys for encryption). Network B 104 can also include or provide network access to systems 140, 142, and / or 144. Systems 140, 142, and / or 144 can be a collection of networked hosts configured to provide various services. For example, CTIP 140 can be one or more CTI providers (CTIPs) that provide CTI reports including network threat indicators (e.g., domain names) to subscribers such as SPMS 150. Similarly, law enforcement intelligence providers (LEIP) 142 and protection and preservation intelligence providers (P3IP) 144 can provide intelligence reports including network indicators (e.g., domain names) to subscribers such as security policy management servers (SPMS) 150. In addition to CTI, LE, and P3 applications, intelligence providers for other applications (not shown) can also provide intelligence reports including network indicators in the form of domain names to subscribers.

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

[0124] A domain name server (DNS) 160 can be one or more computers that comprise the Internet Domain Name System (DNS). Various hosts can use DNS 160 to resolve domain names to IP addresses. Additionally or alternatively, DNS 160 can be used to obtain (e.g., retrieve, acquire) encryption keys (e.g., public encryption keys) for use in creating eSNI ciphertext contained in a TLS ClientHello message.

[0125] The ESNI-G / W 120 can be located at or near a network boundary between a first network (e.g., network A 102) and a second network (e.g., network B 104). For example, the ESNI-G / W 120 can connect (interface) network 102 or one or more hosts located therein with network 104 or one or more hosts located therein. As noted above, network B 104 can include hosts 130, 131, and / or 139. Hosts 130, 131, and / or 139 can host one or more networked application servers and / or associated domains. The one or more application servers and / or associated domains can be configured to support TLS secure communications. Network A 102 can include hosts 110, 112, and / or 114. Hosts 110, 112, and / or 114 can host network application clients (e.g., web browsers) and can be configured to support TLS secure communications. The ESNI-G / W 120 can be inline on network link 106 and can filter in-transit packets to enforce policies associated with domain names associated with TLS secure communications. In some embodiments, the ESNI-G / W 120 can 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 can be an interface between a protected network, such as network A 102, and an unprotected network, such as network B 104, connected to the protected network. One or more PSGs can be located at one or more boundaries of the protected network and filter (e.g., apply policies containing packet filtering rules to) in-transit packets passing in either direction through the one or more boundaries. As Figure 1 indicated, the PSG can incorporate the ESNI-G / W 120. The PSG's ESNI-G / W 120 functionality can apply to one or more packets associated with TLS secure communications using eSNI.

[0126] Although not shown, it should be understood that Figure 1Additional network components can be present in the network. These network components can include devices located at or near the network perimeter, such as network firewalls and associated network address translation (NAT) functionality, proxies, etc., that can alter packet header information. Altering packet header information can impact the methods, devices, systems, and / or computer- readable media described herein. As will be described in greater detail below, the systems, components, functions, data, etc. described with respect to the CTI-based application can 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.) can replace and / or run concurrently with the CTI-based network protection application. The methods, devices, systems, and / or computer-readable media described herein can be implemented in any suitable system that can determine a correspondence between an eSNI ciphertext contained in a TLS ClientHello message / packet in a transmission and a plaintext domain name associated with an application and a communication. Based on the determination of the correspondence between the eSNI ciphertext and the plaintext domain name, the system can process the packet in accordance with a packet filtering rule.

[0127] Figure 2An example of an ESNI-G / W 120 for enforcing policies on communications between network A 102 and network B 104 is shown. The communications can be TLS secure communications with encrypted hostnames (e.g., encrypted SNI values that can be included in eSNI ciphertext). The ESNI-G / W 120 can include a processor and main memory (CPU-w / MEM) 121 that can execute logic for configuring and operating the ESNI-G / W 120, network interface NTWK-I / F 127, management interface MGMT-I / F 129. The CPU-w / MEM 121 can execute logic for configuring and operating the ESNI-G / W 120 according to one or more communication policies enforcement applications. These applications can execute concurrently and cooperatively / collaboratively. Additionally or alternatively, the processor and main memory (CPU-w / MEM) 121 can execute logic for configuring and operating a system and service set (such as PKT-FILTER (PKT-FILTER) 122, EDCL-SVC 123, DNS-ESNI-SVC 124, DNS-QUERY-TRACKER (DNS-QUERY-TRACKER) 125, and / or TLS-MITM-PROXY (TLS-MITM-PROXY) 126) that can support the operation of the ESNI-G / W 120 and its related applications. These components can communicate using a bus (BUS) 128. The bus 128 can be used to transfer data, including packets, between the components of the ESNI-G / W 120. The bus 128 can provide a data communication channel between the components of the ESNI-G / W 120. In some examples, the bus 128 can be on-chip silicon connecting processor logic (e.g., processor and main memory (CPU-w / MEM) 121) with on-chip cache memory, which provides fast and compact processing. Additionally or alternatively, the bus 128 can be a network connection (e.g., TCP / IP network), such as network A 102 or network B 104. In further examples, the bus 128 can include an integrated / embedded data bus on a printed circuit board (PCB), a parallel data cable connecting computers and / or peripheral devices, a serial optical cable connecting ports and / or interfaces of network switches and routers, an L2 / L3 switching network, an L3 routing network, and the like, as well as any combination thereof. The bus 128 can be silicon, wired, wireless, physical, logical, virtual, software-defined, and the like.

[0128] ESNI-G / W 120 can be co-located with network link 106, which can interconnect network A 102 and network B 104 via network interface port NTWK-I / F 127. In some embodiments, network interface port NTWK-I / F 127 can be transparent at L3 and / or L2. That is, network interface port NTWK-I / F 127 can not have IP addresses and / or MAC addresses assigned to them. In accordance with these examples, in-transit L2 / L3 packets can pass through ESNI-G / W 120 without modification of the L2 / L3 packet headers. In-transit packet processing logic of ESNI-G / W 120 can provide time and memory efficient packet processing that allows for packet filtering at the peak packet transmission rate of link 106 without dropping packets, e.g., due to internal buffer overflow caused by latency. In some examples, management interface MGMT-I / F 129 can be assigned an L3 / IP address. Management interface MGMT-I / F 129 can allow ESNI-G / W 120 to communicate with service providing hosts such as SPMS 150 and / or DNS 160.

[0129] PKT-FILTER 122 system can apply policies including one or more packet filtering rules to in-transit packets passing through ESNI-G / W 120. Policies can be provided by servers and / or services, such as SPMS 150. Packet filtering rules of policies can be derived from indicators contained in various types of intelligence reports (e.g., CTI reports, LEI reports, P3I reports, etc.). PKT-FILTER 122 can be configured to support one or more different network security applications, such as CTI-based network protection, lawful interception, privacy protection and preservation, etc., concurrently.

[0130] EDCL-SVC 123 service can manage queries for information associated with one or more EDCLs. EDCLs can be provided by EDCL-SYS 152 (via MGMT-I / F 129). EDCL-SYS 152 can be part of SPMS 150. EDCL-SVC 123 can serve queries from ESNI-G / W 120. EDCL-SVC 123 can receive one or more query requests from one or more applications executing on ESNI-G / W 120. The one or more query requests can be received via bus 128. Query requests can include IP addresses. EDCL-SVC 123 can send query responses to applications. Query responses can include ESNI-related information associated with IP addresses stored in one or more EDCLs managed by EDCL-SVC 123.

[0131] The DNS-ESNI-SVC 124 service can manage queries for eSNI support information associated with domain names that can be registered in the Internet DNS 160. The EDCL-SVC 123 can receive one or more query requests from one or more applications executing on the ESNI-G / W 120. The query requests can be received via the bus 128. The query requests can include a domain name. The EDCL-SVC 123 can send a query response to the one or more applications. The query response can include information indicating whether a domain associated with the domain name supports eSNI. The DNS-ESNI-SVC 124 can determine whether a domain name supports eSNI by determining whether the domain name is a member of a DNS-ESNI set managed by the DNS-ESNI-SVC. For example, the DNS-ESNI set can be provided by the DNS-ESNI-SYS 156 via the MGMT-I / F 129. The DNS-ESNI-SYS 156 can be a component of the SPMS 150. Additionally or alternatively, the DNS-ESNI-SVC 124 can determine whether a domain name supports eSNI by querying the DNS 160 to determine whether the domain name is associated with any resource records for eSNI support.

[0132] The DNS-QUERY-TRACKER 125 system can manage information associated with DNS queries that can have been issued by hosts connected to network A 102. Additionally or alternatively, the DNS-QUERY-TRACKER 125 system can serve queries for information associated with DNS queries that can have been issued by hosts connected to network A 102. The DNS-QUERY-TRACKER 125 can observe DNS query requests and responses for resolving domain names to IP addresses. For each DNS query, the DNS-QUERY-TRACKER 125 can store a record of the query in an efficient data structure, such as a table (e.g., hash table) or database. The record can include: (1) the IP address of the host that initiated the DNS query; (2) the domain name; (3) the IP address that the domain name resolved to; (4) the number of queries; and / or (5) additional information for managing and / or improving the system and / or service. For example, the additional information can include eSNI support information associated with the domain name. The DNS-QUERY-TRACKER 125 can help disambiguate the plaintext domain name that can correspond to an eSNI ciphertext. For example, an eSNI-Gateway application can process an in-transit packet that contains a ClientHello message that includes an eSNI ciphertext. The application can query the EDCL-SVC 123 and determine that multiple domain names can correspond to the eSNI ciphertext. To disambiguate which of the multiple domain names can correspond to the eSNI ciphertext, the application can query the DNS-QUERY-TRACKER 125 for a record that corresponds to the L3 source IP address and / or L3 destination IP address of the packet. To serve the query, the DNS-QUERY-TRACKER 125 can search its data structure (e.g., table and / or database) for one or more records that match the source IP address of the packet to the source host IP address of the record and / or match the destination IP address of the packet to the resolved IP address of the record. Any such record can be included in the query response sent to the application. The application can then determine the plaintext domain name that corresponds to the eSNI ciphertext from the most recent record. Based on the determined plaintext domain name, the application can send the packet and domain name to the PKT-FILTER 122 for filtering and processing.

[0133] The eSNI-Gateway application can use the TLS-MITM-PROXY 126 (transparent) proxy system to perform deeper inspection of the packet and / or associated communications. For example, the TLS-MITM-PROXY 126 can decrypt the TLS secure communication, inspect the plaintext of the TLS secure communication, and re-encrypt the TLS secure communication. The application can use this man-in-the-middle approach to determine the plaintext domain name corresponding to the eSNI ciphertext associated with the TLS secure communication. For example, the application can receive an in-transit packet containing an encrypted hostname (e.g., a ClientHello message containing an eSNI ciphertext). To determine whether there is a correspondence between the plaintext domain name associated with the application and the eSNI ciphertext, the application can call the EDCL-SVC 123 and / or the DNS-QUERY-TRACKER 125. However, the EDCL-SVC 123 and / or the DNS-QUERY-TRACKER 125 can be unable to determine the plaintext domain name corresponding to the encrypted hostname (e.g., domain name). In some examples, the EDCL-SVC 123 and / or the DNS-QUERY-TRACKER 125 can be unable to determine the plaintext domain name within a certain degree of certainty. The application can then forward the TLS secure communication to the TLS-MITM-PROXY 126. The TLS-MITM-PROXY 126 can decrypt the TLS secure communication to obtain (e.g., determine) the plaintext domain name corresponding to the eSNI ciphertext. As will be discussed in greater detail below, one or more ESNI-G / W applications, such as LE and P3 applications, can use the TLS-MITM-PROXY 126 to obtain the plaintext of a TLS secure communication session.

[0134] Figure 3 A representative example of an eSNI domain name correspondence list (EDCL) 300 is shown. The EDCL data structure can be represented as a two-dimensional table. An eSNI gateway (e.g., ESNI-G / W 120) can use the EDCL 300 to determine whether an encrypted hostname (e.g., eSNI ciphertext) corresponds to a plaintext domain name in a database of domain names associated with a network security application, such as CTI-based network protection, law enforcement (LE), privacy protection and preservation (P3), etc. Determining whether an encrypted hostname (e.g., encrypted domain name) corresponds to one or more plaintext domain names in a database can be a factor in how an eSNI gateway (e.g., ESNI-G / W 120) processes an in-transit packet containing an encrypted domain name (e.g., a ClientHello message with an eSNI ciphertext). As discussed herein, the EDCL 300 can be used with one or more network security applications associated with CTI-based network protection and one or more applications such as law enforcement (LE) applications and / or privacy protection and preservation (P3) applications.

[0135] EDCL 300 can include multiple columns. A first column 301 labeled "IP-Address" can contain one or more unique IP addresses, which index a table of each row and / or entry. Each IP address in the first column 301 can correspond to a DNS record (e.g., Internet DNS A (IPv4) or AAAA (IPv6)) of one or more domain names associated with eSNI-enabled domains in the CTI database. A second column 302 labeled "CTI-ESNI-Domains" can contain domain names in the CTI database that support eSNI. The elements in the second column 302 are the names of domains hosted at the corresponding IP address in the first column 301. For example, the domains {pgorlzex.cn, x-advice.onln, bmb27.com} in the (311, 302) element location of the EDCL 300 can be hosted at the IP address 40.07.25.13, as indicated in 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 can indicate that one of the plaintext domain names {pgorlzex.cn, x-advice.onln, bmb27.com} can correspond to the encrypted hostname (e.g., eSNI ciphertext). There can be other domains hosted on the same IP address 40.07.25.13, whose domain names can correspond to eSNI ciphertext. However, these domain names can not be listed at element (311, 302) because these domain names either are not in the CTI database or do not support eSNI.

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

[0137] As shown in the example illustrated in line 314, ESNI-G / W 120 can receive a communication with an encrypted hostname (e.g., a ClientHello message with eSNI ciphertext). ESNI-G / W 120 can use a network address (e.g., source IP address, destination IP address, etc.) to determine with high probability the plaintext domain name corresponding to the received eSNI ciphertext. As shown, ESNI-G / W 120 can determine that the plaintext domain associated with the received eSNI ciphertext is toplipts.com. In this regard, ESNI-G / W 120 can query EDCL 300 using IP address 22.74.02.18 to determine the plaintext domain name corresponding to the eSNI ciphertext. ESNI-G / W 120 logic can decide that because #CTI-ESNI-Domains (314, 303) = 1 and #CTI-Domains (314, 304) = 1 and #Reverse-IP-Lookup-Domains (314, 305) = 1, then (314, 302) = toplipts.com, the received encrypted hostname (e.g., eSNI ciphertext) corresponds to toplipts.com.

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

[0139] As shown in the example illustrated in line 310, ESNI-G / W 120 can receive a communication with an encrypted hostname (e.g., a ClientHello message with eSNI ciphertext). ESNI-G / W 120 can use a network address (e.g., source IP address, destination IP address, etc.) to determine that the communication can be malicious. ESNI-G / W 120 can query EDCL 300 using IP address 102.2.18.81 to determine one or more plaintext domain names associated with the encrypted hostname (e.g., eSNI ciphertext). ESNI-G / W 120 logic can decide that because #CTI-ESNI-Domains (310, 303) = 8 and #CTI-Domains (310, 304) = 8 and #Reverse-IP-Lookup-Domains (310, 305) = 0, ESNI-G / W 120 can determine that the IP address has been assigned to a malicious principal that takes measures and actions to obfuscate its internet presence. Based on this determination, ESNI-G / W 120 can determine that the communication is likely malicious.

[0140] As shown in the example illustrated in line 311, ESNI-G / W 120 can receive a communication with an encrypted hostname (e.g., a ClientHello message with eSNI ciphertext). ESNI-G / W 120 can use a network address (e.g., source IP address, destination IP address, etc.) to determine that the communication can be malicious. ESNI-G / W 120 can query EDCL 300 using IP address 40.07.25.13 to determine one or more plaintext domain names associated with the encrypted hostname (e.g., eSNI ciphertext). ESNI-G / W 120 logic can decide that because #CTI-ESNI-Domains (311, 303) = 3 and #CTI-Domains (311, 304) = 3 and #Reverse-IP-Lookup-Domains (311, 305) = 3, ESNI-G / W 120 can determine that the communication is directed to an IP address that has been assigned to a content delivery and / or advertising software service operator that does not actively review or monitor its customers. ESNI-G / W 120 can determine that the communication is likely malicious.

[0141] Figure 4A and Figure 4BAn example of a process 400 showing the creation, distribution, and maintenance of a system of EDCLs (e.g., EDCL-SYS 152) is shown. In some embodiments, the system (e.g., EDCL-SYS 152) can be integrated with or the system can include a subsystem of the SPMS 150 that creates, distributes, and maintains policies of grouping filtering rules derived from CTI databases and / or other intelligence databases. The CTI databases can include a plurality of threat indicators, including a plurality of threat indicators in the form of domain names. Further, the CTI databases can be continuously updated, e.g., by a network threat intelligence provider (e.g., CTIP 140) producing new threat intelligence reports and / or associated network threat indicators. The CTI-derived policies and EDCLs can be created and / or managed by individual eSNI gateways. Additionally or alternatively, the EDCLs and / or CTI-derived security policies can be created and / or managed by a central server, such as the CTIP.

[0142] 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 the SPMS 150, extracting fully qualified domain names (FQDNs) from the current CTI indicator database (e.g., CTI-INDICATOR-DB), and inserting the FQDNs into a database (e.g., CTI-FQDN-DB). In step 410, the system can initialize an EDCL, which can be associated with metadata including a creation time, an SPMS identity, CTI-INDICATOR-DB and CTI-FQDN-DB identifiable information, etc. Once the EDCL is initialized, the system can initiate a loop or iteration process through each FQDN in the CTI-FQDN-DB to populate the EDCL.

[0143] In step 415, the system can query the DNS (e.g., the Internet DNS 160) to determine whether the current FQDN has a resource record (RR) associated with eSNI. In step 420, the system can 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, the 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, the process 400 proceeds to step 425 during which the system can query the DNS for the domain record (e.g., the corresponding A and AAAA records) of the FQDN. The system can receive a response. The response can include an IPv4 IP address and / or an IPv6 IP address associated with the FQDN. In some examples, if both A (IPv4) and AAAA (IPv6) records exist for the FQDN, then step 425 can be repeated if the domain name has both an IPv4 IP address and an IPv6 IP address.

[0144] In step 430, the system can determine whether the IP address exists in the EDCL. For example, the system can 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 entry can be indexed by the IP address.

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

[0146] In step 455, the system can populate additional fields and / or columns in the EDCL. The additional fields and / or columns can be in addition to the IP address 301, the CTI-ESNI-Domains 302, and the #CTI-ESNI-Domains 303. Continuing with the above example, the EDCL can include the following fields and / or columns: Figure 3In the example at issue, row 313 can be indexed by IP address 6203:7400:3340::8618:46ef in element (313, 301). Row 313 can have nine (9) domain names (values of element (313, 303)) that are in the CTI database and that are associated with eSNI-enabled domains. Element (313, 305) = 15 is the number of domains hosted at IP address 6203:7400:3340::8618:46ef, according to certain reverse IP lookup services. In step 460, the system (e.g., SPMS 150) can distribute the EDCL to one or more ESNI-G / Ws (e.g., ESNI-G / W 120). In some examples, the ESNI-G / Ws can subscribe to receive the EDCL. Process 400 can be repeated to change, modify, alter, or otherwise update the EDCL.

[0147] Process 400 can be performed in a different order and / or different combinations than described above. The dynamic nature of the CTI, eSNI support, and / or domain name to IP address mapping suggests that process 400 can be performed frequently or even continuously in order to minimize lag and / or synchronization issues. In this regard, process 400 can use a continuous dynamic update model. Additionally or alternatively, process 400 can use batch processing to update the EDCL. While process 400 is described in terms of a network security application for CTI-based network protection, it should be appreciated that other applications, such as lawful interception as well as privacy protection and preservation applications, can use process 400 to update the EDCL or its equivalent.

[0148] Figure 5An example of a process 500 of a system (e.g., CTI-POLICY-SYS 154) that creates, distributes, and maintains policies that include one or more packet filtering rules derived from a CTI database is shown. CTI-based policies can be distributed to a packet security gateway (PSG) that sits at a network border and applies these policies to one or more packets that cross the border in either direction. When a PSG is configured with CTI-derived policies (such as those created by CTI-POLICY-SYS 156), the PSG can be identified as a threat intelligence gateway (TIG). The ESNI-G / W 120 can be a subsystem, subcomponent, or subfunction of a TIG whose task is to filter only packets associated with TLS secure communications or TLS secure communications that use eSNI. The PKT-FILTER 122 (which can be used by the ESNI-G / W 120 to filter packets for plaintext domain names that correspond to eSNI ciphertext) can be used by a TIG or PSG to filter packets based on one or more CTI-derived indicators (e.g., IP address, 5-tuple, domain name, URI, etc.). The policies created by the CTI-POLICY-SYS 154 can be used directly, jointly, and simultaneously by the ESNI-G / W 120 and systems that integrate the ESNI-G / W 120 (such as TIGs and / or PSGs). In some examples, a system (e.g., CTI-POLICY-SYS 154) can integrate or include subsystems of a SPMS 150 that create, distribute, and / or maintain policies derived from a CTI database.

[0149] In step 510, the system can initiate the CTI-POLICY creation process by accessing the current CTI indicators database CTI-INDICATOR-DB of the SPMS 150. It should be understood that the system can be adapted for other applications (e.g., law enforcement, privacy protection and preservation, etc.) and databases associated therewith. Once the CTI-POLICY is initialized, the system can initiate a loop or iteration process through each indicator in the CTI-INDICATOR-DB to create the CTI-POLICY.

[0150] In step 520, the system can create a packet filtering rule with the current indicator as the matching criteria. In step 530, the system can insert the rule into the CTI-POLICY. In terms of typical packet filtering rule syntax, such as OpenBSD PF syntax, the rule can specify at least one action and at least one packet matching criteria. The action or disposition can include allowing (e.g., passing, forwarding, etc.) the packet (e.g., in-transit L2 / L3 packet) to its intended destination. Alternatively, the action can include blocking (e.g., rejecting, dropping, etc.) the packet (e.g., in-transit L2 / L3 packet) from reaching its intended destination. The packet matching criteria can 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.). Additional rule components can be specified depending on the capabilities and purpose (e.g., network security) of the target packet filtering device (e.g., PSG, TIG, and ESNI-G / W). These rule components can include, such as: packet transformation functions (PTF) and metadata. PTFs can include logging, capturing, mirroring, redirecting, tunneling, etc. Additionally or alternatively, PTFs can include proxying functions. For example, the PTF “tcp-rst” can transparently spoof the destination host of a TCP packet by creating a TCP RST packet and forwarding it to the source host, causing the source host to drop the TCP connection. Metadata can be used to inform the application logic of the packet filtering device and / or gateway of attributes associated with the packet that cannot be directly derived from the content of the packet. Metadata can include, for example, information derived from the relevant CTI report for the indicator, the CTI provider providing the indicator, the type of attack related to the indicator, attribution, etc.

[0151] In step 540, the system can determine whether there are more indicators in the CTI-INDICATOR-DB. If there are more indicators in the CTI-INDICATOR-DB, the process returns to step 520 to process additional indicators in the CTI-INDICATOR-DB. If there are no additional indicators in the CTI-INDICATOR-DB, the process 500 proceeds to step 550, in which the system can manage the rules in the CTI-POLICY. Additionally or alternatively, the system can encode the rules in the CTI-POLICY to satisfy constraints and / or improve performance of packet filtering applications (performed by PSGs / TIGs / ESNI-G / Ws) that apply the CTI-POLICY to packets in transit. For example, duplicate rules can be removed, rules can be merged, and / or order dependencies can be identified. Further, rules can be reordered and / or grouped and ordered to support fast searching of packet filtering applications. Step 550 can be performed by a target packet filtering device / gateway. In some examples, step 550 and step 530 can be combined. In step 560, the system (e.g., SPMS 150) can distribute the CTI-POLICY to one or more subscribing ESNI-G / Ws 120. The process 500 can be repeated to change, modify, alter, or otherwise update the CTI-POLICY.

[0152] The process 500 can be performed in a different order and / or different combination than described above. The dynamic nature of the CTI indicates that the process 500 is frequently or even continuously performed in order to minimize lag and / or synchronization issues. In this regard, the process 500 can use a continuous dynamic update model. Additionally or alternatively, the process 500 can use batch processing to update the CTI-POLICY. While the process 500 is described in terms of a network security application for network protection based on CTI, it should be appreciated that other applications, such as lawful interception as well as privacy protection and preservation applications, can use the process 500 to update the CTI-POLICY or its equivalent.

[0153] Figure 6An example of a process 600 is shown that illustrates the creation, distribution, and maintenance of a DNS-ESNI set data structure by a system (e.g., DNS-ESNI-SYS 156). In some examples, the DNS-ESNI-SYS 156 system can be integrated with or can include a subsystem of the SPMS 150 that creates, distributes, and / or maintains policies of packet filtering rules derived from a CTI database. The DNS-ESNI set data structure can include entries for DNS registered domain names that support eSNI. The DNS-ESNI data structure can determine whether a domain name registered in the Internet DNS is associated with a domain that supports eSNI. The DNS-ESNI set can be derived from a dynamic database containing Internet DNS registered domain names or can be derived from dynamic eSNI support information derived from querying the DNS for eSNI support status of a registered domain name. The ESNI-G / W can create and / or maintain the DNS-ESNI. Additionally or alternatively, a centralized approach, e.g., via the SPMS (e.g., SPMS 150), can be employed to create and / or manage the DNS-ESNI.

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

[0155] In step 610, a system (e.g., DNS-ESNI-SYS 156) can generate a database (e.g., DNS-REG-DB) by collecting and / or aggregating lists of domain names registered in the DNS. For example, sources of these lists include DNS registration authority operator organizations and / or associated representatives and / or authoritative name server discovery of zone files, domain list aggregation services, third-party services that discover country code domains (CCDs), ICANN, and the like. Once the DNS registered domain names are obtained (e.g., determined), the system can initiate a loop or iterative process to generate the DNS-ESNI.

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

[0157] The process 600 can be performed in a different order and / or different combinations than described above. The dynamic nature of the DNS and eSNI indicates that the process 600 can be performed frequently or even continuously in order to minimize lag and / or synchronization issues. In this regard, the process 600 can use a continuous dynamic update model. In some examples, the ESNI-G / Ws (e.g., the ESNI-G / Ws 120) can determine the information contained in the DNS-ESNI as needed by directly querying the DNS for eSNI support status when they observe clear text SNIs contained in packets in transit.

[0158] Figure 7 An example of a process 700 is shown that creates, distributes, and maintains the EDCL, CTI-derived policies, and / or DNS-ESNI set data structures for a system (e.g., the SPMS 150). Although the examples described below relate to CTI-based network protection applications, it should be understood that the systems and methods described below can be incorporated into SPMS 150 operations and / or associated ESNI-G / W operations.

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

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

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

[0162] Figure 8A and Figure 8BAn example of a process for using one or more packet filtering policies and EDCLs to configure an ESNI-G / W 120 and to perform a network threat protection application based on one or more packet filtering policies and EDCLs derived from one or more CTI indicators is shown.

[0163] In step 805, the SPMS 150 can distribute 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 can also distribute a 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 can configure its PKT-FILTER 122, EDCL-SVC 123, and / or DNS-ESNI-SVC 124.

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

[0165] In step 815, ESNI-G / W 120 can intercept packet PKT-0. ESNI-G / W 120 can inspect 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 can extract the (L3 / IP) destination IP address (e.g., 87.65.43.21) from PKT-0 and index an entry by 87.65.43.21 by querying EDCL-SVC 123 in an EDCL search. If the search returns no results, ESNI-G / W 120 can determine that the plaintext domain name (e.g., www.legitimate-non-CTI-site.net) is not associated with any domain name threat indicators in the relevant policy CTI-POLICY. ESNI-G / W 120 can make this determination even if it does not know the plaintext domain name that corresponds to the encrypted hostname (e.g., encrypted domain name). At the end of step 815, ESNI-G / W 120 can allow PKT-0 to proceed to its destination 87.65.43.21 (SRVR-0 130). In step 820, a TLS tunnel can be established between HOST-1 110 and SRVR-0 130, and a (TLS-secure) HTTP session (e.g., HTTPS) is conducted. After the HTTP session is complete, the TLS tunnel and TCP connection can be torn down.

[0166] In step 825, a user of the web browser executing on HOST-1 110 can attempt to access site SRVR-1 131. SRVR-1 131 can host a second domain (e.g., toplipts.com) that supports eSNI. As described above, the DNS entry for the second domain can include a second public encryption key for the second domain name. The user can enter the second domain as part of a URI (e.g., https: / / toplipts.com / ) in a browser window. The browser can query DNS 160 for the IP address of the second domain (e.g., toplipts.com). In response to the query, the browser can 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 can be captured by a DNS-QUERY-TRACKER 125 instance (not shown). Upon receiving the second IP address and the second public encryption key, the browser can establish a TCP connection with the 443 port (HTTPS) of the second IP address (e.g., 22.74.02.18). To establish a TLS secure session, the browser can 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 and IP packet PKT-1 with the (L3 / IP) Destination IP address field set to the second IP address (e.g., 22.74.02.18), and forward the packet PKT-1 to SRVR-1 131.

[0167] In step 830, ESNI-G / W 120 can intercept packet PKT-1. ESNI-G / W 120 can inspect the ClientHello message and determine that the message contains eSNI ciphertext. ESNI-G / W 120 can extract the (L3 / IP) Destination IP address (e.g., 22.74.02.18) and search the EDCL for an entry indexed by 22.74.02.18 by querying EDCL-SVC 123. The search can return an entry from the EDCL. For example, the search can return the entry from above with respect to Figure 3Line 314 of EDCL 300 is discussed. After examining the contents of the entry, ESNI-G / W 120 can determine that the eSNI ciphertext corresponds to the plaintext domain name toplipts.com. ESNI-G / W 120 can invoke the PKT-FILTER 122 system. As discussed above, PKT-FILTER 122 can be configured with a CTI-POLICY in step 805. ESNI-G / W 120 can search the CTI-POLICY for a packet filtering rule that matches the criteria “toplipts.com”. According to this example, a matching rule can be found that has a (network protection) “block” action for handling matching packets (PKT-1). Additionally or alternatively, the matching rule can include a packet transformation function (PTF) “tcp-rst”. ESNI-G / W 120 can spoof or transparently proxy SRVR-1 131, and can send a TLS alert protocol message with a (fatal) alert code (e.g., code 40 “handshake failure”) to HOST-1 110 that causes HOST-1 110 to close the TLS session. The TCP RST can cause HOST-1 110 to tear down the TCP connection. Alternatively, ESNI-G / W 120 can send a TCP RST that closes the TLS session without signaling. In this regard, ESNI-G / W 120 can not want to provide any data and / or information to HOST-1 110 that can have been compromised.

[0168] In step 835, a user of the web browser executing on HOST-1 110 can attempt to access a site SRVR-2 132. SRVR-2 132 can host a third domain name (e.g., kottoqui.ga) that supports eSNI. That is, the DNS entry for the third domain name can include a public encryption key. The user can enter the third domain name as part of a URI in a browser window (e.g., https: / / kottoqui.ga / ). The browser on HOST-1 110 can query the 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 can be captured by the DNS-QUERY-TRACKER 125 (not shown). Upon receiving the third IP address and the third public encryption key, the browser can establish a TCP connection with the 443 port (HTTPS) of 102.2.18.81. To establish a TLS secure session, the browser can generate a ClientHello message, encrypt the third domain name (e.g., kottoqui.ga) and / or one or more other portions of the message using the third public encryption key (e.g., SITE-2-KEY), encapsulate the message in a TCP packet and an IP packet PKT-2 with the (L3 / IP) destination IP address field set to 102.2.18.81, and forward the packet PKT-2 to SRVR-2 132.

[0169] In step 840, the ESNI-G / W 120 can intercept the packet PKT-2. The ESNI-G / W 120 can inspect the ClientHello message and determine that the message includes an encrypted hostname (e.g., eSNI ciphertext). The ESNI-G / W 120 can extract the (L3 / IP) destination IP address (e.g., 102.2.18.81) and search the EDCL for an entry indexed by 102.2.18.81 by querying the EDCL-SVC 123. The search can return an entry from the EDCL. For example, the search can return the entry from above with respect to step 830. The ESNI-G / W 120 can decrypt the eSNI ciphertext using the third private encryption key (e.g., SITE-2-KEY) to obtain the third domain name (e.g., kottoqui.ga). The ESNI-G / W 120 can then forward the packet PKT-2 to SRVR-2 132. Figure 3Row 310 of EDCL 300 is discussed. After examining the contents of the entries, ESNI-G / W 120 can determine that it cannot determine the plaintext domain name corresponding to the eSNI ciphertext from the EDCL. ESNI-G / W 120 can determine that all domains hosted at IP address 102.2.18.81 have domain names that are in the CTI Index database and associated CTI-POLICY and support eSNI. Any of the eight (8) domain names in element {row 310, column 302} of EDCL 300 can be the plaintext domain name corresponding to the eSNI ciphertext. ESNI-G / W 120 can select any of the eight domain names as a possible communication party and then proceed. Additionally or alternatively, ESNI-G / W 120 can check whether DNS-QUERY-TRACKER 125 has any entries that can determine the communication party. In this example, ESNI-G / W 120 can check DNS-QUERY-TRACKER 125 to determine that the third domain name (e.g., kottoqui.ga) is likely the communication party. ESNI-G / W 120 can invoke PKT-FILTER 122 system configured with CTI-POLICY in step 805 to search the CTI-POLICY for a packet filtering rule with matching criteria “kottoqui.ga”. A matching rule with a (network protection) “block” action and a packet transformation function (PTF) “tcp-rst” for handling matching packets (PKT-2) can be found. ESNI-G / W 120 can spoof or transparently proxy SRVR-2 132. Additionally or alternatively, ESNI-G / W 120 can 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 can cause HOST-1 110 to close the TLS session. Additionally or alternatively, ESNI-G / W 120 can send a TCP RST that causes HOST-1 110 to tear down the TCP connection.

[0170] Turning to Figure 8BIn step 845, a user of the web browser executing on HOST-1 110 can attempt to access site SRVR-3 133. SRVR-3 133 can host a fourth domain name (e.g., cakbacon.cn) that supports eSNI. As in the example above, the DNS entry for the fourth domain name can include a public encryption key. The user can enter the fourth domain name as part of a URI in a browser window (e.g., https: / / cakbacon.cn / ). The browser can query DNS 160 for the fourth IP address (e.g., 14.99.65.22) and the fourth public encryption key (e.g., SITE-3-KEY). The DNS query can be captured by a DNS-QUERY-TRACKER 125 instance (not shown). The browser can establish a TCP connection with the 443 port (HTTPS) of 14.99.65.22. To establish a TLS secure session, the browser can generate a ClientHello message, encrypt the fourth domain name (e.g., cakbacon.cn) and / or one or more portions of the message using the fourth public encryption key (e.g., SITE-3-KEY 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 to SRVR-3 133.

[0171] In step 850, ESNI-G / W 120 can intercept packet PKT-3 and inspect the ClientHello message. ESNI-G / W 120 can determine that the message includes an encrypted hostname (e.g., eSNI ciphertext). ESNI-G / W 120 can extract the (L3 / IP) destination IP address 14.99.65.22 and search the EDCL for an entry indexed by 14.99.65.22 by querying EDCL-SVC 123. The search can return an entry, such as the one above. Figure 3Row 312 in the EDCL 300 described in the middle. After examining the contents of row 312, the ESNI-G / W 120 can determine that the plaintext domain name corresponding to the encrypted hostname (e.g., eSNI ciphertext) cannot be determined from the EDCL. The ESNI-G / W 120 can determine that the one or more domains hosted on 14.99.65.22 are not in the CTI. Additionally or alternatively, the ESNI-G / W 120 can determine that the plaintext domain name corresponding to the encrypted hostname (e.g., eSNI ciphertext) should be resolved to properly enforce policies associated with the communication. The ESNI-G / W 120 can spoof or transparently proxy SRVR-3 133. The ESNI-G / W 120 can send a TLS message to HOST-1 110. The TLS message can cause HOST-1 110 to issue a ClientHello that does not encrypt the SNI. The TLS message can include a TLS alert protocol message with a (fatal) alert code (e.g., code 70 “protocol version”). The TLS alert protocol message can also cause HOST-1 110 to use a TLS version that does not support encrypted SNI, such as TLS 1.2. Additionally or alternatively, the ESNI-G / W 120 can send a TLS message that causes HOST-1 110 to not use the encrypted SNI option.

[0172] In step 860, the browser on HOST-1 110 can generate a ClientHello message with the SNI extension field set to (in clear text) cakbacon.cn, encapsulate the message in a TCP packet with the (L3 / IP) Destination IP address field set to 14.99.65.22 and an IP packet PKT-3.1, and forward the packet PKT-3.1 to SRVR-3 133. In step 865, the ESNI-G / W 120 can intercept the packet PKT-3.1 and inspect the ClientHello message. The ESNI-G / W 120 can determine that the message includes the clear text SNI value cakbacon.cn. The ESNI-G / W 120 can invoke the PKT-FILTER 122 system configured with the CTI-POLICY in step 805 to search the CTI-POLICY for a packet filtering rule with the matching criteria “cakbacon.cn”. According to this example, a matching rule can be found with a (network protection) “block” action and a packet transformation function (PTF) “tcp-rst” for handling matching packets (PKT-3.1). The ESNI-G / W 120 can spoof or transparently proxy SRVR-3 133 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 can cause HOST-1 110 to close the TLS session. Additionally or alternatively, the ESNI-G / W 120 can send a TCP RST to HOST-1 110, which causes HOST-1 110 to tear down the TCP connection.

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

[0174] In step 875, the ESNI-G / W 120 can intercept the packet PKT-4. The ESNI-G / W 120 can inspect the ClientHello message and determine that the message includes an encrypted hostname (e.g., eSNI ciphertext). The ESNI-G / W 120 can 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 can include querying the EDCL-SVC 123 with the IP address 14.99.65.22. The search can return an entry from the EDCL. The entry can be the entry described above with respect to Figure 3Row 312 of the EDCL 300 is discussed. After examining the contents of row 312, the ESNI-G / W 120 can determine that the plaintext domain name corresponding to the eSNI ciphertext cannot be determined from the EDCL. Additionally or alternatively, the ESNI-G / W 120 can determine that the multiple domains hosted on 14.99.65.22 are not in the CTI. The ESNI-G / W 120 can further determine that the plaintext domain name corresponding to the encrypted hostname (e.g., eSNI ciphertext) should be resolved to properly enforce one or more policies associated with the communication. The ESNI-G / W 120 can spoof or transparently proxy the SRVR-4 134 and send to the HOST-1 110 a TLS message that can cause the HOST-1 110 to issue a ClientHello with an unencrypted SNI. For example, the ESNI-G / W 120 can send to the HOST-1 110 a TLS alert protocol message with a (fatal) alert code (e.g., code 70 “protocol version”). The TLS alert message can cause the HOST-1 110 to use a TLS version that does not support encrypted SNI (e.g., TLS 1.2). Additionally or alternatively, the ESNI-G / W 120 can send to the HOST-1 110 a TLS message that causes the HOST-1 110 to not use the encrypted SNI option.

[0175] In step 880, the browser on HOST-1 110 can generate a ClientHello message with the SNI extension field set to (in the clear) not-a-CTI-threat-site.net, encapsulate the message in 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 to SRVR-4 134. In step 885, ESNI-G / W 120 can intercept packet PKT-4.1 and inspect the ClientHello message. Based on inspecting the ClientHello message, ESNI-G / W 120 can determine that the message includes the clear text SNI value not-a-CTI-threat-site.net. ESNI-G / W 120 can invoke PKT-FILTER 122 system configured with CTI-POLICY in step 805 to search CTI-POLICY for a packet filtering rule with the matching criteria "not-a-CTI-threat-site.net." The search can return no results. ESNI-G / W 120 can allow PKT-4.1 to proceed to its destination 14.99.65.22 (SRVR-4 134). In step 890, a TLS tunnel can be established between HOST-1 110 and SRVR-4 134, and a (TLS secure) HTTP session can be conducted. After the HTTP session is complete, the TLS tunnel and TCP connection can be torn down.

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

[0177] Figure 9 An example of a process to configure ESNI-G / W 120 using a packet filtering operation that supports one or more applications is shown. The one or more applications can include, for example, a Law Enforcement (LE) application, such as lawful interception, or (2) a Privacy Protection and Preservation (P3) application. For LE applications, a packet filtering policy and / or EDCL can be derived from LEI indicators. Similarly, a packet filtering policy and / or EDCL can be derived from P3 indicators (P3I) for P3 applications. Such LE and P3 applications can include logic that relies on observing domain names associated with communications. If a communication is associated with a domain name contained in some LEI database and / or P3I database, the application can take action on the communication.

[0178] Figure 9 Such a description in Figure 8A and Figure 8B is similar in form and function to the CTI application described in Figure 8A and Figure 8B . For example, Figure 9 the CTI and / or associated CTI-POLICY and EDCL of Figure 9 may be similar to the LEI and / or associated LEI-POLICY and LEI-EDCL of The TLS-MITM-PROXY 126 can be used in

[0179] differently than in the example discussed above. CTI and P3 and other applications can use the TLS-MITM-PROXY 126 component for similar reasons as LEI applications, including, for example, (1) to decrypt communications ciphertext into plaintext so that the application can further inspect the communication to determine the domain name corresponding to the eSNI ciphertext and subsequently take appropriate action (e.g., invoke the associated PKT-FILTER 122 on the plaintext packet); and (2) to decrypt the communication and further inspect the plaintext for information other than the domain name, such as a user ID, in order to make a communication handling decision (e.g., whether to capture / store the plaintext communication).

[0179] In step 910, the SPMS 150 can 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 can distribute the DNS-ESNI. The ESNI-G / W 120 can configure its PKT-FILTER 122, EDCL-SVC 123, and / or DNS-ESNI-SVC 124, e.g., based on the LEI-derived packet filtering policy (e.g., LEI-POLICY), the associated LEI-derived LEI-EDCL, and / or the DNS-ESNI. In some examples, the SPMS 150 can distribute additional LEI data, including, e.g., one or more lists of user IDs.

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

[0181] In step 930, ESNI-G / W 120 can intercept packet PKT-6 and inspect the ClientHello message contained therein. ESNI-G / W 120 can determine that the message includes an encrypted hostname (e.g., eSNI ciphertext). ESNI-G / W 120 can extract the (L3 / IP) destination IP address 21.43.65.87 and search the LEI-EDCL for an entry indexed by 21.43.65.87 by querying EDCL-SVC 123. The search can return an entry of the LEI-EDCL (indexed by 21.43.65.87). Based on the search result, ESNI-G / W 120 can determine (resolve) the (plaintext) domain name to be “LEI-watchlist-site.net”. ESNI-G / W 120 can invoke PKT-FILTER 122 configured with LEI-POLICY in step 910 to search LEI-POLICY for a packet filtering rule with matching criteria “LEI-watchlist-site.net”. A matching rule can be found, which indicates an “allow” action and a packet transformation function (PTF) “tls-mitm-proxy” for processing matching packets (PKT-6). PTF “tls-mitm-proxy” can signal ESNI-G / W 120 to forward PKT-6 and subsequent packets associated with the same flow / communication as PKT-6 to TLS-MITM-PROXY 126. After passing through TLS-MITM-PROXY 126, PKT-6 can be forwarded by ESNI-G / W 120 to SRVR-6 136. In some examples, a proxied version of PKT-6 can be forwarded to SRVR-6 136.

[0182] In step 940, a TLS tunnel can be established between HOST-2 112 and SRVR-6 136, and a (TLS-protected) HTTP session can be conducted. Packets containing the session pass through TLS-MITM-PROXY 126, and the application can capture and store decrypted plaintext messages / packets. The application can also inspect additional information of the plaintext, such as a user ID, to determine whether it is allowed to capture and store the plaintext. If not, the capture and storage function can be terminated and any stored data can be erased and / or otherwise made inaccessible. After the HTTP session is completed, the TLS tunnel and TCP connection can be torn down.

[0183] Figure 10An example of packet filtering that minimizes eavesdropping by ESNI-G / W 120 is shown. A first application can perform using eSIN as long as eSNI is available. A second application can perform using eSNI for all TLS secure communications. That is, the second application can only allow TLS secure communications that support eSNI, and eSNI is available to access these sites.

[0184] In step 1005, SPMS 150 can distribute DNS-ESNI to ESNI-G / W 120. DNS-ESNI can be an updated version of DNS-ESNI. ESNI-G / W 120 can configure DNS-ESNI-SVC 124 with DNS-ESNI. ESNI-G / W 120 can be performing a first application (e.g., performing using eSIN as long as eSNI is available).

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

[0186] In step 1015, ESNI-G / W 120 can intercept packet PKT-7 and inspect the ClientHello message contained therein. ESNI-G / W 120 can determine that the message includes the plaintext SNI value "non-eSNI-site.net." ESNI-G / W 120 can query DNS-ESNI-SVC 124 to determine that the domain "non-eSNI-site.net" does not support eSNI. ESNI-G / W 120 can allow PKT-7 to proceed to its destination 78.56.34.12 (SRVR-7 137). In step 1020, a TLS tunnel can be established between HOST-4 114 and SRVR-7 137, and a (TLS-secure) HTTP session can be conducted. Upon completion of the HTTP session, the TLS tunnel and TCP connection can be torn down.

[0187] In step 1025, a user of the web browser executing on HOST-4 114 can attempt to access site SRVR-8 138. SRVR-8 138 can host a ninth domain name that supports eSNI (e.g., supports-eSNI-site.net). The user can enter the ninth domain name as part of a URI in a browser window (e.g., https: / / supports-eSNI-site.net / ). Next, the browser can query DNS 160 for the IP address of the ninth domain (e.g., supports-eSNI-site.net) (e.g., 12.34.43.21). Upon receiving the IP address, the browser can establish a TCP connection to port 443 (HTTPS) of 12.34.43.21. To establish a TLS-secure session, the browser can 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 to SRVR-8 138.

[0188] In step 1030, ESNI-G / W 120 can intercept packet PKT-8 and inspect the ClientHello message contained therein. ESNI-G / W 120 can determine that the message includes the plaintext SNI value "supports-eSNI-site.net." ESNI-G / W 120 can query DNS-ESNI-SVC 124 to determine that the domain "supports-eSNI-site.net" supports eSNI. Because the first application needs to use eSNI if it is available, ESNI-G / W 120 can spoof or transparently proxy SRVR-8 138. ESNI-G / W 120 can send a TLS message to HOST-4 114 that can cause HOST-4 114 to issue a ClientHello that uses eSNI. The TLS message can include a TLS alert protocol message that signals to HOST-4 114 that eSNI is required.

[0189] In step 1035, the browser executing on HOST-4 114 can query DNS 160 for the public encryption key (e.g., SITE-8-KEY) for the domain "supports-eSNI-site.net." The browser can generate a ClientHello message, encrypt the domain name "supports-eSNI-site.net" and / or one or more other parts 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 to SRVR-8 138.

[0190] In step 1040, ESNI-G / W 120 can intercept packet PKT-8.1 and inspect the ClientHello message contained therein. ESNI-G / W 120 can determine that the message includes eSNI ciphertext. ESNI-G / W 120 can allow PKT-8.1 to proceed by forwarding PKT-8.1 to its destination 12.34.43.21 (SRVR-8 138).

[0191] In step 1045, a TLS tunnel can be established between HOST-4 114 and SRVR-8 138, and a (TLS-secure) HTTP session can be conducted. After the HTTPS session is complete, the TLS tunnel and TCP connection can be torn down.

[0192] During steps 1050 and 1055, the ESNI-G / W 120 can be operating a second application that only allows access to sites that support eSNI and require the use of eSNI.

[0193] In step 1050, a user of a web browser executing on HOST-4 114 can attempt to access site SRVR-7 137. SRVR-7 137 can host a tenth domain name that does not support eSNI (e.g., non-eSNI-site.net). The user can enter the domain name as part of a URI in a browser window (e.g., https: / / non-eSNI-site.net / ). The browser can query the DNS 160 for the IP address of non-eSNI-site.net (e.g., 78.56.34.12). Upon receiving the IP address, the browser can establish a TCP connection with the 443 port (HTTPS) of 78.56.34.12. To establish a TLS secure session, the browser can 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 the packet PKT-9 to SRVR-7 137.

[0194] In step 1055, the ESNI-G / W 120 can intercept the packet PKT-9 and inspect the ClientHello message contained therein. The ESNI-G / W 120 can determine that the message includes the plaintext SNI value "non-eSNI-site.net." The ESNI-G / W 120 can query the DNS-ESNI-SVC 124 to determine that the domain "non-eSNI-site.net" does not support eSNI. Since the second application can only allow access to sites that support eSNI, the ESNI-G / W 120 can spoof or transparently proxy SRVR-7 137. The second application can perform similarly to the first application described above when accessing sites that support eSNI. The ESNI-G / W 120 can 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 can cause HOST-4 114 to close the TLS session. Additionally or alternatively, the ESNI-G / W 120 can send a TCP RST to HOST-4 114. The TCP RST can cause HOST-4 114 to tear down the TCP connection.

[0195] As described above, a packet filtering system can receive a packet including ciphertext including an encrypted server name indication (SNI) value. The packet filtering system can determine a plaintext hostname associated with the encrypted hostname to determine whether the plaintext hostname is associated with one or more threats. Figure 11 An example of a process 1100 for determining whether encrypted network traffic is associated with one or more threats is shown. Some or all of the steps of the process 1100 can be performed using one or more computing devices, such as the packet security gateway 120.

[0196] In step 1110, the packet filtering device can receive one or more threat indicators. For example, the packet filtering device can 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 can be received from a security policy management server (SPMS). Additionally or alternatively, the one or more threat indicators can be received indirectly as matching criteria in a packet filtering rule. In further examples, the packet filtering device can receive one or more policies comprised of packet filtering rules derived from the threat indicators. The one or more policies can include an enterprise communications policy; a privacy protection and preservation policy; a law enforcement policy; or equivalents thereof. The packet filtering device can reside at a boundary between a first network and a second network. In this regard, the packet filtering device can be a gateway, a firewall, a router, or any other type of edge device. Additionally or alternatively, the packet filtering device can be a pass-through device located on one or more network segments. As described above, the one or more threat indicators can include a plurality of domain names (e.g., hostnames) associated with one or more threats. Additionally or alternatively, the one or more threat indicators can include a plurality of network addresses (e.g., IP addresses) associated with one or more threats.

[0197] In step 1120, the packet filtering device can receive a plurality of packets including ciphertext including an encrypted server name indication (SNI) value. The plurality of packets can be associated with a single communication and / or message, such as a ClientHello message. As described above, the plurality of packets can include ciphertext including an encrypted server name indication (SNI) value.

[0198] In step 1130, the packet filtering device can determine whether a plaintext hostname can be resolved from the encrypted hostname (e.g., an encrypted SNI (eSNI)). The packet filtering device can use the above regarding Figure 8A and 8BThe one or more techniques described. For example, a packet filtering device can determine a destination network address (e.g., an IP address) associated with the plurality of packets. The packet filtering device can query a data structure indexed by the destination network address to determine a plaintext hostname associated with or corresponding to the encrypted hostname. Based on the query, the packet filtering device can receive a response that includes the plaintext hostname associated with the encrypted hostname. As described above, the queried data structure can be an eSNI Domain Name Correspondence List (EDCL). In some examples, the response can include a plurality of plaintext hostnames that can correspond to the encrypted hostname. That is, a plurality of hostnames can be associated with the destination network address. The packet filtering device can indicate that the encrypted hostname corresponds to one of the plurality of hostnames associated with the destination network address. Further, other domain names can be hosted in the destination network address that can correspond to ciphertext; however, these domain names can not be listed in the EDCL because these domain names are either not in the CTI database or eSNI is not supported.

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

[0200] In some examples, the packet filtering device can determine a destination network address associated with the plurality of packets. For the above example, the packet filtering device can query the data structure using the destination network address to determine a plaintext hostname associated with the encrypted hostname. In response to the query, the packet filtering device can receive a response that fails to locate the destination network address in the data structure. The packet filtering device can transmit a response to the first device. The response can request a retransmission of the plurality of packets having a plaintext hostname (e.g., an unencrypted server name indication (SNI)). The packet filtering device can receive the retransmission of the plurality of packets having the plaintext hostname (e.g., SNI).

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

[0202] In some cases, an enterprise host can need to use an encrypted host name when communicating with a destination that supports ciphertext including an encrypted server name indication (SNI) value. Figure 12 An example of a process 1200 for performing a policy using an encrypted host name is shown in accordance with one or more examples described herein. Some or all of the steps of process 1200 can be performed using one or more computing devices, such as packet security gateway 120.

[0203] In step 1210, the packet filtering device can receive one or more policies, as described above with respect to Figure 9 The packet filtering device can be configured with a plurality of packet filtering rules.

[0204] In step 1220, the packet filtering device can receive a first plurality of packets from a first device intended for a destination. The first plurality of packets can be associated with a communication or message, such as a ClientHello message. The first plurality of packets can include a plaintext host name.

[0205] In step 1230, the packet filtering device can determine whether the destination supports eSNI. For example, the packet filtering device can 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 can determine that the destination supports eSNI. Additionally or alternatively, the packet filtering device can query a data structure (e.g., a table, a database, etc.) to determine whether the destination supports eSNI. When an entry for the destination exists in the data structure, the packet filtering device can determine that the destination supports eSNI. If the destination does not support eSNI, the packet filtering device can forward the plurality of packets to the destination in step 1235. The plurality of packets can 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 does not support eSNI, in step 1240, the packet filtering device can transmit a message including an indication that the first device used eSNI.

[0206] In step 1250, the packet filtering device can receive a second plurality of packets from the first device intended for the destination. The second plurality of packets can include ciphertext including an encrypted server name indication (SNI) value (e.g., eSNI ciphertext). In some examples, the packet filtering device can perform the analysis discussed above with respect to Figure 11 The policy enforcement aspect and the filtering aspect can be performed concurrently or consecutively. In some examples, the packet filtering device can store the plaintext hostname from the first plurality of packets and associate the plaintext hostname with the eSNI ciphertext in the second plurality of packets. As discussed above, if the destination is not associated with one or more threat indicators, in step 1260, the packet filtering device can forward the second plurality of packets to the destination. Additionally or alternatively, the second plurality of packets can be forwarded in response to determining that the second plurality of packets includes encrypted SNI (e.g., eSNI ciphertext). The second plurality of packets can include one or more communications associated with creating a secure communication channel (e.g., TLS) between the first device and the destination.

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

[0208] In step 1310, the packet filtering device can receive one or more policies. The packet filtering device can be configured with a plurality of packet filtering rules. The one or more policies can include an enterprise communications policy; a privacy protection and preservation policy; a law enforcement policy; or equivalents thereof. In step 1320, the packet filtering device can receive a plurality of encrypted packets. The plurality of encrypted packets can include an encrypted hostname (e.g., eSNI ciphertext). As described above, the packet filtering device can perform the above-discussed analysis to determine the plaintext hostname and whether the plaintext hostname is associated with one or more threat indicators. Figure 11

[0209] In step 1330, the packet filtering device can decrypt the plurality of encrypted packets to obtain a plurality of plaintext packets. The packet filtering device can forward the plurality of encrypted packets to a (transparent) intermediary TLS man-in-the-middle (MITM) proxy function. The MITM proxy function can decrypt a TLS secure application session, inspect the session in unencrypted form, re-encrypt the session, and forward the TLS secure session to its destination. In step 1340, the packet filtering device (e.g., the MITM proxy function) can inspect (e.g., investigate) the plaintext packets. In some examples, the packet filtering device can extract the plaintext domain name corresponding to the eSNI ciphertext in the session content. In some cases, the packet filtering device can use the extracted plaintext domain name to perform the above-discussed analysis. Figure 11

[0210] In step 1350, the packet filtering device can determine whether to allow the capture and storage of the plurality of packets. The determination can be based on policies such as an enterprise communications policy; a privacy protection and preservation policy; a law enforcement policy; or equivalents thereof. In this regard, the enterprise communications policy can require the recording and / or archiving of communications to comply with regulatory schemes (i.e., HIPAA, Sarbanes-Oxley, etc.). In another example, the law enforcement policy can be based on whether a law enforcement agency is authorized to store the communications. If there is a logical basis to store the plurality of packets, then in step 1360, the packet filtering device can store a copy of the plurality of decrypted packets. After storing the decrypted packets, the process 1300 can proceed to step 1370. If the storage of the plurality of decrypted packets is not allowed or after storing the decrypted packets, the packet filtering device can forward the plurality of encrypted packets to their destination. As described above, the plurality of encrypted packets can allow for a secure communication channel (e.g., TLS) between the first device and the destination.

[0211] ​​The techniques described herein allow a packet filtering device to resolve encrypted hostnames to plaintext hostnames. The plaintext hostnames can be used to determine whether 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. Further, the techniques described herein allow the packet filtering device to monitor encrypted network traffic for known threats. This provides improved network monitoring and reduces the spread of malware. Additionally, performing eSNI when supported by the destination can reduce threats such as privacy breaches caused by malicious eavesdropping. Moreover, the techniques described herein can perform communications to comply with privacy laws and / or regulations. Finally, the techniques described herein can assist law enforcement in monitoring encrypted network traffic.

[0212] One or more of the features discussed herein can be embodied in computer- usable or readable data and / or computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices described herein. Program modules can include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. Modules can be written in, for example, a source code programming language (that can then be compiled) or a scripting language (that can be interpreted). The computer-executable instructions can be stored on a computer- readable medium such as a hard disk, optical disk, removable memory, solid state memory, RAM, etc. The functions of the program modules can be combined or distributed as desired. In addition, the functionality can be embodied in whole or in part in firmware or hardware equivalents such as integrated circuits, field programmable gate arrays (FPGA), and the like. Particular data structures can be used to more effectively implement one or more features described herein, and such data structures are deemed to be within the scope of computer-executable instructions and computer-usable data described herein. Various features described herein can be embodied as methods, computing devices, systems, and / or computer program products.

[0213] While the present disclosure has been described in terms of various examples, many additional modifications and variations would be apparent to those skilled in the art. Particularly, any of the various processes described above can be performed in an alternative order and / or in parallel (on different computing devices) to achieve an analogous result in a manner that is better suited to the requirements of a particular application. It is therefore understood that the present disclosure can be practiced otherwise than is specifically described without actually departing from the scope and spirit of the present disclosure. Although examples have been described above, features and / or steps from those examples can be combined, divided, omitted, rearranged, modified, and / or added to in any desired manner. Accordingly, the present disclosure in all respects should be considered as illustrative and not restrictive. The scope of the present disclosure should therefore be determined not with reference to the above description but with reference to the appended claims, along with their full scope of equivalents.

Claims

1. A method for determining whether encrypted network traffic is associated with one or more threat indicators, the method comprising: receiving, by a packet filtering device and from a server external to a network protected by the packet filtering device, a security policy, wherein the security policy comprises a plurality of packet filtering rules created or changed based on one or more indicators received from one or more intelligence providers; receiving a plurality of packets from a first device, wherein the plurality of packets comprise ciphertext that includes an encrypted server name indication (eSNI) value; determining, based on a determination that the plurality of packets comprise the eSNI value, a destination network address associated with the plurality of packets; querying a data structure using the destination network address to determine a plaintext hostname corresponding to the eSNI value, wherein the data structure comprises one or more hostnames and corresponding network addresses; receiving, based on querying the data structure, a response indicating the plaintext hostname corresponding to the eSNI value, wherein the plaintext hostname is determined to correspond to the eSNI value based on the plaintext hostname being associated with the destination network address; determining whether the plaintext hostname corresponds to at least one of the one or more indicators; and based on a determination that the plaintext hostname corresponds to at least one of the one or more indicators, applying a packet filtering operation to the plurality of packets specified by one or more of the plurality of packet filtering rules corresponding to the at least one of the one or more indicators. At least two of the one or more intelligence providers are managed by different organizations.

2. The method of claim 1, wherein, The server external to a network protected by the packet filtering device comprises a security policy management server.

3. The method of claim 1 or 2, wherein, The packet filtering operation comprises at least one of:

4. The method of claim 1, wherein, preventing the plurality of packets from continuing toward their intended destination, allowing the plurality of packets to continue to their intended destination and forwarding a copy of the plurality of packets to a first agent for monitoring, or forwarding the plurality of packets to a second agent. The ciphertext comprises a ClientHello message.

5. The method of claim 1, wherein, The one or more intelligence providers comprise at least one of:

6. The method of claim 1, wherein, a network threat intelligence provider, wherein one or more indicators provided by the network threat intelligence provider comprise one or more threat indicators; a law enforcement intelligence provider, wherein one or more indicators provided by the law enforcement intelligence provider comprise one or more network indicators; or a privacy protection and preservation intelligence provider, wherein one or more indicators provided by the privacy protection and preservation intelligence provider comprise one or more network indicators.

7. The method of claim 1, further comprising: receiving the data structure from a server external to a network protected by the packet filtering device. The data structure comprises an eSNI domain name correspondence list (EDCL).

8. The method of claim 1, wherein, The packet filtering operation comprises preventing the plurality of packets from continuing toward their intended destination, and the method further comprises:

9. The method of claim 1, wherein, ​ sending one or more responses to the first device for the plurality of packets, wherein the one or more responses comprise at least one of: a TCP RST message or a TLS handshake message.

10. The method of claim 1, wherein: the packet filtering device resides at a boundary between a protected network and an unprotected network; and the packet filtering device brokers traffic between the protected network and the unprotected network.

11. A packet filtering device, comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the packet filtering device to perform the method of any of claims 1-10.

12. A non-transitory computer-readable medium comprising instructions that, when executed, cause a packet filtering device to perform the method of any of claims 1-10.

13. A method for determining whether encrypted network traffic is associated with one or more threat indicators, the method comprising: receiving, by a packet filtering device and from a server external to a network protected by the packet filtering device, a security policy, wherein the security policy comprises a plurality of packet filtering rules based on one or more indicators received from one or more intelligence providers; receiving, from a first device, a plurality of packets, wherein the plurality of packets comprises a first message to establish a secure communication channel and an encrypted server name indication (eSNI) value; determining, based on a determination that the plurality of packets comprises the eSNI value, a destination network address associated with the plurality of packets; querying a data structure using the destination network address to determine a plaintext hostname corresponding to the eSNI value, wherein the data structure comprises one or more hostnames and corresponding network addresses; receiving, based on querying the data structure, a response indicating a plurality of plaintext hostnames associated with the destination network address; determining, based on a record indicating one or more previous domain name service (DNS) queries associated with the first device, a first plaintext hostname of the plurality of plaintext hostnames; determining whether the first plaintext hostname corresponds to at least one of the one or more indicators; and based on a determination that the first plaintext hostname corresponds to at least one of the one or more indicators, applying, to the plurality of packets, a packet filtering operation specified by one or more of the plurality of packet filtering rules corresponding to the at least one of the one or more indicators.

14. The method of claim 13, further comprising: receiving one or more DNS queries to resolve the first plaintext hostname; and creating, in a second data structure, a record associated with the one or more DNS queries, wherein the record comprises the first plaintext hostname and an internet protocol (IP) address to which the first plaintext hostname was resolved. determining the first plaintext hostname further comprises: querying the second data structure to determine a record indicating one or more previous DNS queries from the first device; and ​ 15. The method of claim 14, wherein, ​ ​ based on the destination network address corresponding to the IP address to which the first plaintext hostname is resolved.

16. The method of claim 15, wherein, determining that the first plaintext hostname corresponds to the eSNI value is further based on a time correlation between recording the one or more DNS queries and receiving the plurality of packets.

17. The method of claim 13, wherein, the first message includes an encrypted ClientHello message.

18. The method of claim 13, wherein, at least two of the one or more intelligence providers are managed by different organizations.

19. The method of claim 13, wherein, the one or more intelligence providers include at least one of: a network threat intelligence provider, wherein one or more indicators provided by the network threat intelligence provider include one or more threat indicators; a law enforcement intelligence provider, wherein one or more indicators provided by the law enforcement intelligence provider include one or more network indicators; or a privacy protection and preservation intelligence provider, wherein one or more indicators provided by the privacy protection and preservation intelligence provider include one or more network indicators.

20. The method of claim 13, further comprising: receiving the data structure from a server external to a network protected by the packet filtering device.

21. The method of claim 13, wherein: the packet filtering device resides at a boundary between a protected network and an unprotected network; and the packet filtering device brokers traffic between the protected network and the unprotected network.

22. A packet filtering device, comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the packet filtering device to perform the method of any of claims 13-21.

23. A non-transitory computer-readable medium comprising instructions that, when executed, cause a packet filtering device to perform the method of any of claims 13-21. ​

Images