System and method for controlling internet access using encrypted DNS

Abstract

The described systems and methods enable client devices (e.g., personal computers and IoT devices) implementing an encrypted DNS protocol to be protected from harmful or inappropriate Internet content. A DNS proxy intercepts attempts to establish an encrypted communication session between a client device and a DNS server. Without decrypting any communication, some embodiments of the DNS proxy determine an identifier of the respective session and an identifier of the client device, and send a query tracer to a security server that ties the session identifier to the client identifier. In some embodiments, the security server obtains the domain name included in the encrypted DNS query from the DNS server, and instructs the DNS server to allow or block the client device's access to the respective Internet domain according to device-specific and / or user-specific access policies.

Description

[Technical field]

[0001]

[0001] The present invention relates to computer security, and more particularly to protecting users from malicious Internet content. [Background technology]

[0002]

[0002] Malicious software, also known as malware, infects many computer systems worldwide. Malware, in its many forms, such as computer viruses, Trojan horses, spyware, and ransomware, poses serious risks to millions of computer users, making them susceptible to data and confidential information loss, identity theft, loss of productivity, and the like. A significant pathway to the spread of malware consists of users inadvertently visiting websites that host malicious or fraudulent content.

[0003]

[0003] Meanwhile, more and more devices, informally referred to as the Internet of Things (IoT), are being connected to communication networks and the Internet. Such devices include smartphones, smart watches, televisions and other multimedia devices, game consoles, home appliances, and various home sensors such as thermostats. As more and more such devices are brought online, they become exposed to security threats such as malware and intrusions. Thus, it becomes increasingly necessary to secure such devices against malware and to protect communications between such devices. Specific areas of renewed interest due to the emergence of the Internet of Things include access control applications, e.g., parental control, and preventing confidential information from being transmitted over IoT devices.

[0004]

[0004] Conventional methods of protecting users and devices include intercepting Domain Name Service (DNS) messages sent by protected devices when attempting to connect to remote Internet resources. In one such example, a modified DNS server may search for a requested domain in a blacklist. If the domain is deemed unsafe, the DNS server blocks access and / or redirects the respective request to a replacement IP address that provides a warning message. In another example, such DNS-based traffic filtering is performed by hardware and / or software components running on the user's network appliance (e.g., a gateway or router).

[0005]

[0005] User privacy concerns have led to the development of encrypted domain name services. Examples include DNS over transport layer security (TLS), as described, for example, in Internet Engineering Task Force (IETF) Request for Comments (RFC) 7858, and DNS over hypertext transport protocol secure (HTTPS), as described, for example, in IETF RFC 8484. Because such protocols implement end-to-end encryption, they can effectively impede computer security efforts by preventing intermediate entities (e.g., routers) from performing DNS-based traffic filtering. Summary of the Invention

[0006]

[0006] Therefore, there is great interest in developing computer security systems and methods that allow traffic filtering in the case of encrypted DNS.

[0007] According to one aspect, a method includes using at least one hardware processor of a network appliance to execute a DNS proxy. The DNS proxy is configured to intercept an attempt to establish an encrypted communication session between a client device and a DNS server, the client device being connected to the network appliance via a local network, the encrypted communication session including a plaintext portion and an encrypted portion. The encrypted portion includes sending an encrypted DNS query to the DNS server. The DNS proxy is further configured to determine a session identifier identifying the encrypted communication session and an identifier identifying the client device, the session identifier being determined according to a content of the plaintext portion of the encrypted communication session. The DNS proxy is further configured to send a query tracer associating the session identifier with a client identifier to a security server configured to determine an access indicator according to the query tracer, the access indicator indicating whether an access policy selected according to the client identifier allows access to an Internet domain identified according to the encrypted DNS query. The security server is further configured to communicate the access indicator to enforce the access policy.

[0007]

[0008] According to another aspect, a network appliance includes at least one hardware processor configured to execute a DNS proxy. The DNS proxy is configured to intercept an attempt to establish an encrypted communication session between a client device and a DNS server, the client device being connected to the network appliance via a local network, the encrypted communication session including a plaintext portion and an encrypted portion. The encrypted portion includes sending an encrypted DNS query to the DNS server. The DNS proxy is further configured to determine a session identifier identifying the encrypted communication session and a client identifier identifying the client device, the session identifier being determined according to a content of the plaintext portion of the encrypted communication session. The DNS proxy is further configured to send a query tracer associating the session identifier with the client identifier to a security server configured to determine an access indicator according to the query tracer, the access indicator indicating whether an access policy selected according to the client identifier allows access to an Internet domain identified according to the encrypted DNS query. The security server is further configured to communicate the access indicator to enforce the access policy.

[0008]

[0009] According to another aspect, a non-transitory computer-readable medium stores instructions that, when executed by at least one hardware processor of the network appliance, cause the network appliance to form a DNS proxy. The DNS proxy is configured to intercept an attempt to establish an encrypted communication session between a client device and a DNS server, the client device being connected to the network via a local network, the encrypted communication session including a plaintext portion and an encrypted portion. The encrypted portion includes sending an encrypted DNS query to the DNS server. The DNS proxy is further configured to determine a session identifier identifying the encrypted communication session and an identifier identifying the client device, the session identifier being determined according to a content of the plaintext portion of the encrypted communication session. The DNS proxy is further configured to send a query tracer associating the session identifier with the client identifier to a security server configured to determine an access indicator according to the query tracer, the access indicator indicating whether an access policy selected according to the client identifier allows access to an Internet domain identified according to the encrypted DNS query. The security server is further configured to communicate the access indicator to enforce the access policy.

[0009]

[0010] According to another aspect, a computer system includes at least one hardware processor configured to receive, from a DNS proxy, a query tracer characterizing an encrypted communication session between a client device and a DNS server. The DNS proxy is connected to the client device via a local network, the encrypted communication session includes a plaintext portion and an encrypted portion, the encrypted portion includes the client device sending an encrypted DNS query to the DNS server. The query tracer associates a session identifier with a client identifier, the client identifier identifies the client device, the session identifier identifies the encrypted communication session, and is determined according to a content of the plaintext portion. The at least one hardware processor is further configured to receive, from the DNS server, a query notification including a domain name included in the encrypted DNS query, the query notification further associates the domain name with the session identifier. The at least one hardware processor is further configured to determine an access indicator according to the query tracer and the query notification, the access indicator indicating whether an access policy selected according to the client identifier allows the client device to access an Internet domain having the domain name. The at least one hardware processor further communicates the access indicator to enforce the access policy.

[0010]

[0011] The above aspects and advantages of the present invention will be better understood upon reading the following detailed description and upon reference to the drawings, in which: [Brief description of the drawings]

[0011] [Figure 1]

[0012] FIG. 2 illustrates an exemplary set of client devices protected against computer security threats, according to some embodiments of the present invention. [Diagram 2]

[0013] FIG. 1 illustrates a typical Domain Name Service (DNS) transaction as known in the art. [Diagram 3]

[0014] FIG. 1 illustrates domain names as known in the art. [Figure 4]

[0015] FIG. 2 is an exemplary diagram illustrating messages exchanged between a client system, a DNS proxy, a DNS server, and a security server in accordance with some embodiments of the present invention. [Diagram 5]

[0016] FIG. 2 illustrates a query tracer according to some embodiments of the present invention. [Figure 6]

[0017] FIG. 1 illustrates an exemplary encrypted communication session conducted in accordance with the Transport Layer Security (TLS) protocol. [Figure 7]

[0018] FIG. 2 illustrates a typical layout of a TLS record as known in the art. [Figure 8]

[0019] FIG. 2 is an exemplary diagram illustrating components of a “Client Hello” TLS record. [Figure 9]

[0020] FIG. 1 illustrates typical components of a Transmission Control Protocol (TCP) header as known in the art. [Figure 10]

[0021] FIG. 1 illustrates typical components of an Internet Protocol (IP) header as known in the art. [Figure 11]

[0022] FIG. 2 is an exemplary diagram illustrating the operation of a DNS proxy according to some embodiments of the present invention. [Figure 12]

[0023] FIG. 2 illustrates an exemplary sequence of steps performed by a security server according to some embodiments of the present invention. [Figure 13]

[0024] FIG. 2 is an exemplary diagram illustrating components of a query notification according to some embodiments of the present invention. [Figure 14A]

[0025] FIG. 2 illustrates an exemplary sequence of steps taken by a DNS server in accordance with some embodiments of the present invention. [Figure 14B]

[0026] FIG. 2 illustrates an exemplary sequence of steps performed by a DNS server in accordance with some embodiments of the present invention. [Figure 15]

[0027] FIG. 4 illustrates an exemplary operation of a traffic filter according to some embodiments of the present invention. [Figure 16]

[0028] FIG. 4 is an exemplary diagram illustrating another message exchange according to some embodiments of the present invention. [Figure 17A]

[0029] FIG. 4 illustrates an exemplary sequence of steps performed by a traffic filter according to some embodiments of the present invention. [Figure 17B]

[0030] FIG. 4 illustrates an exemplary sequence of steps performed by a traffic filter according to some embodiments of the present invention. [Figure 18]

[0031] FIG. 2 illustrates an exemplary hardware configuration of a computing appliance programmable to implement methods and algorithms according to some embodiments of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012]

[0032] In the following description, all described connections between structures can be direct operational connections or indirect operational connections through intermediate structures. A set of elements includes one or more elements. Any description of an element is understood to refer to at least one element. A plurality of elements includes at least two elements. Unless otherwise required, any method steps described need not necessarily be performed in a particular illustrated order. A first element (e.g., data) derived from a second element includes the first element being equal to the second element, and the first data generated by processing the second element and optionally other data. Making a decision or determination according to a parameter includes making a decision or determination according to the parameter and optionally other data. Unless otherwise specified, an indication of any quantity / data may be the quantity / data itself or a different indication than the quantity / data itself. A computer program is a sequence of processor instructions that perform a task. In some embodiments of the present invention, the computer programs described may be standalone software entities or subentities (e.g., subroutines, libraries) of other computer programs. A network domain consists of a group of interconnected computing devices that form different parts of a computer network. An Internet domain is a network domain connected to the public Internet. A domain name is a label / alias that identifies an address of a network / Internet domain. Resolving a domain name, as used herein, means determining the network address of the domain with the respective domain name. Metadata, as used herein, means characteristics of a transmission other than the payload itself. Examples of metadata include, among other things, source and / or destination network addresses, payload size, and timestamps indicating the actual time of each transmission.Two devices are said to be connected to or belong to the same local network if their network addresses belong to the same subnet and / or both have the same broadcast address. A wide area network includes at least one router. The term "database" is used herein to mean any organized collection of data. A hash is the output of a hash function. A hash function is a mathematical function that maps an input of any length to an output of a fixed length. A session identifier as described herein may include, but is not limited to, the contents of the SessionID field of a ClientHello record. Computer-readable media encompass non-transitory computer-readable media such as magnetic, optical and semiconductor storage media (e.g., hard drives, optical disks, flash memory, DRAM), and communication links such as conductive cables and fiber optic links. According to some embodiments, the present invention provides, among other things, a computer system including hardware (e.g., one or more processors) programmed to perform the methods described herein, and a computer-readable medium encoding instructions to perform the methods described herein.

[0013]

[0033] The following description illustrates embodiments of the present invention by way of example, and not necessarily by way of limitation.

[0034] 1 illustrates a system 10 for protecting a set of client devices 12a-12e against computer security threats according to some embodiments of the present invention. Exemplary client devices 12a-12e include personal computer systems, enterprise mainframe computers, mobile computing platforms (e.g., laptop computers, tablets, mobile phones), entertainment devices (e.g., televisions, game consoles), wearable devices (e.g., smart watches, fitness bands), home appliances (e.g., refrigerators, washing machines), and any other electronic devices that include a processor, memory, and a communications internet that allows each device to communicate with other devices / computer systems. Any of the exemplary client devices 12a-12e can interact with a remote content server 16 via a communications link to exchange data, such as web content, electronic messages, various documents, and the like.

[0014]

[0035] In the exemplary configuration of FIG. 1, client devices 12a-12e are interconnected by a local network 13, such as a local area network (LAN), a home network, an enterprise network, etc. Devices 12a-12e may be further connected to an extended network 15, such as a wide area network (WAN) and / or the Internet. In some embodiments, at least a portion of the network traffic between client devices 12a-12e and extended network 15 passes through a network appliance 14, such as a router, a WiFi hotspot, a network hub, etc. In the illustrated configuration, appliance 14 acts as a gateway device between local network 13 and extended network 15. In some embodiments, network appliance 14 performs various computer security operations, such as a firewall that scans communications for malware.

[0015]

[0036] In some embodiments, as described in more detail below, a domain name service (DNS) server 20 cooperates with a security server 40 to protect client devices 12a-12e. Each of servers 20 and 40 collectively represents a set of communicatively coupled computers that may or may not be physically proximate to one another. Those skilled in the art will appreciate that the actions performed by servers 20 and 40 as described herein may be divided among multiple physical machines or processors. In some embodiments, security server 40 may be implemented as a set of software modules executing on network appliance 14. In yet another exemplary embodiment, security server 40 and DNS server may be implemented as separate software modules executing on the same physical machine.

[0016]

[0037] In some embodiments, the security server 40 is further connected to the client policy database 42 and the security database 44 and configured to access the databases 42 and / or 44 to perform selective data insertion, data retrieval, and / or other database management operations. The policy database 42 is configured to store a plurality of client records for the client devices 12a-12e and / or users of the respective client devices. In one embodiment, each client record corresponds to a different client device 12a-12e. The client records can store a set of identifiers for the respective client devices (e.g., a client identifier as described below, a Media Access Control (MAC) address, an International Mobile Equipment Identity (IMEI) number, a local network address, etc.) and an Internet access policy specific to the respective client device. The access policy encodes a set of rules or constraints for accessing Internet content. For example, the access policy indicator may include an indicator of a category of content that the respective client device should not access (e.g., adult content, social network, online gambling, etc.). The access policy may further include a time indicator, for example, a time interval for which the respective policy is applicable. The access policies may further include a location indicator indicating the applicability area of ​​the respective policy. In one such example, one access policy may be applied when the respective device is connected to the local network 13 (e.g., when at home) and another policy may be applied when the respective device is roaming. Another exemplary policy may be applied only within the boundaries of a given geofence. In some embodiments, the access policies may include an identifier of a user of the respective client device, indicating that the respective policy applies when the respective client device is operated by the respective user.

[0017]

[0038] In some embodiments, the client records may include other data that may be relevant to access policies. Examples include an indication of device type (e.g., digital camera, thermostat, smartphone, tablet computer, router, automobile), various hardware configuration indications of each client device (e.g., whether each device has a camera, etc.), and a list of software applications installed on each device. Other information stored in an exemplary client record includes device usage data, such as statistics of network access by each client device, e.g., the relative frequency of using various communication ports, the relative traffic volume during various time intervals, etc. Other client record examples may include metadata describing network traffic sent or received by each client device. In some embodiments, such metadata may be organized according to formats such as the Internet Engineering Task Force's IP Flow Information Export (IPFIX) or Cisco's NetFlow®.

[0018]

[0039] In some embodiments, policy database 42 may store records indicative of collective access policies. One example of a collective access policy applies to all devices having a particular device profile defined by a tuple of device characteristics, e.g., device type and operating system. In one such example, one access policy may apply to desktop computers, and another access policy may apply to smartphones and tablet computers. In another example, an access policy may apply to all devices having an Android operating system older than version 10, etc. Another collective access policy may apply to all devices belonging to a group or organization. In one such example, all devices connected to local network 13 may be defined by a collective access policy associated with network appliance 14. In yet another example, one access policy may apply to devices operated by employees in the engineering department of a company, another access policy may apply to devices operated by employees in the legal department of a company, etc.

[0019]

[0040] The policy database 42 may be formatted and stored according to any standard known in the art. Example database formats include relational databases, Extensible Markup Language (XML) databases, spreadsheets, key-value stores, and the like.

[0020]

[0041] Security database 44 collectively represents any collection of data enabling servers 40 for determining whether access to a particular Internet resource constitutes a computer security hazard and / or for enforcing Internet access policies such as parental control. In a simple embodiment, database 44 includes a set of records indexed according to domain names, with each record indicating a category of content stored in the respective domain. Example categories include malicious content (e.g., malware, scam web pages, phishing web pages, dark web pages, etc.), adult content, streaming, gambling, social networking and gaming, etc. Security database 44 may be formatted and stored according to any standard known in the art.

[0021]

[0042] In some embodiments, DNS server system 20 provides domain name services to client devices 12a-12e, each of which includes, among other things, translating domain names into network addresses and / or vice versa by maintaining a mapping between domain names and network addresses. DNS server 20 collectively refers to a set of communicatively coupled computers, such as authoritative name servers, top-level domain name servers, root name servers, etc.

[0022]

[0043] A typical data transmission between the client device 12 and the content server 16 includes several steps. Such a transmission requires knowing the network address (e.g., Internet Protocol-IP address) of the server 16. Often, this address is unknown to the client for various reasons. For example, there may be multiple mirrored content servers, and the client may be dynamically directed to the most favorable content server according to the current load of each mirror server or according to the current geographical location of the client device. However, the client device may know a domain name that includes an alias for an unknown network address. Thus, to establish a connection to the content server 16, a software entity running on the respective client device issues a request to access the respective domain name instead of the IP address itself. In response, another software entity (e.g., an operating system) of the client device may attempt to translate the alias / domain name into the actual network address and then send the request to the correct network location.

[0023]

[0044] Translating a domain name to a network address (an operation also referred to in the art as domain name resolution) typically involves the client device 12 sending a DNS query 22 to a DNS server 20, as shown in FIG. 2. The query 22 may include an encoding of the domain name and an identifier for the type of question Q, among other things. The question type indicates the type of DNS resource record that is returned by the DNS server 20 in response to the respective query. Example questions include "A", which requests an IP address as defined in the Internet Protocol, version 4 (IPv4), and "AAAA", which returns an IP address as defined in the Internet Protocol, version 6 (IPv6). Other example question / resource record types include "TXT", "PTR", "LOC", and the like. In response to the query 22, the DNS server 20 may return a DNS response 24 to the requesting client, which includes a network address (e.g., an IPv6 address) corresponding to the respective domain name / alias. Example formats of the query 22 and the response 24 may be found, for example, in IETF RFC 1035. In systems using the encrypted DNS protocol, queries 22 and / or responses 24 may be at least partially encrypted as described below.

[0024]

[0045] 3 illustrates exemplary domain names for Internet domains. A domain name may consist of a fully qualified domain name (FQDN) 36 that completely and unambiguously specifies the respective domain using an ordered sequence of tokens / labels 32a-32d separated by delimiters 34 (dots in the illustrated example). Fragments of FQDN 36 that include subsets / subsequences of FQDN tokens 32a-32d are commonly referred to as partially qualified domain names (PQDNs). Items 38a-38c illustrate various exemplary PQDNs of FQDN 36. Unlike FQDN 36, each PQDN 38a-38c specifies the respective domain with a degree of ambiguity, i.e., there may be multiple FQDNs with the same characterizing PQDN. The resolution of an FQDN to a corresponding IP address typically proceeds iteratively, with each successive iteration proceeding through successive levels of the domain name hierarchy, from the root level ('_'), to the top level domain (TLD) level (e.g., com, net, fashion, tv, and country tokens such as ro, fr), to a domain level containing tokens such as wikipedia, facebook, and so on, and to a subdomain level containing various domain-specific prefix tokens. Each successive iteration can be determined according to a different token in the FQDN 36 and may involve sending a separate DNS query to a different component / machine of the DNS server 20.

[0025]

[0046] FIG. 4 illustrates an exemplary DNS exchange between a client device 12 (which may correspond to any of devices 12a-12e of FIG. 1) and a DNS server 20, according to some embodiments of the present invention, that implement a version of an encrypted DNS protocol, such as DNS over TLS or DNS over HTTPS. In some embodiments, a DNS proxy module 50 acts as an intermediary between the client device 12 and the DNS server 20. The DNS proxy 50 may be implemented as a computer program running on a computing appliance connected to the local network 13. In one embodiment, the DNS proxy 50 runs on the network appliance 14 or on a router that assigns network addresses to client devices on the network 13. In another embodiment, the proxy 50 may run on the client device 12. In yet another embodiment, the functionality of the DNS proxy 50 may be split between an agent running on the client device 12 and another agent running on the appliance 14.

[0026]

[0047] In some embodiments, the DNS proxy 50 is configured to intercept encrypted DNS queries 122 from the client device 12 and forward the queries 122 to the DNS server 20. The proxy 50 can further receive encrypted DNS responses 124 from the server 20 and forward them to the client device 12. In some embodiments, the queries 122 and / or responses 124 are forwarded unchanged to their intended destination / network address. In some embodiments, where the client device 12 is configured to send the queries 122 to a preferred DNS server different from the DNS server 20 described herein, the DNS proxy 50 may forcibly redirect the queries 122 to the DNS server 20. The queries 122 may include ciphertext encoding of the domain name, while the responses 124 may include ciphertext encoding of the IP address of the respective domain. In a simple example, the encrypted DNS queries 122 include encryption of the entire DNS query (e.g., query 22 in FIG. 2), while the encrypted DNS responses 124 include encryption of the entire DNS response (e.g., response 24 in FIG. 2).

[0027]

[0048] In some embodiments, the DNS proxy 50 is further configured to determine a query tracer 52 that associates the DNS query 122 with its source (e.g., the client device 12) and transmit the query tracer 52 to the security server 40. The security server 40 can then cooperate with the DNS server 20 to enforce an access policy, which may include selectively allowing or denying the client device 12 access to the Internet domain indicated by the domain name included in the encrypted DNS query 122 according to the domain name and according to an identity of the client device 12 and / or of a user of the client device 12. Such cooperation is described in more detail below.

[0028]

[0049] In some embodiments, the query tracer 52 includes a data structure that associates the DNS query 122 with its originating entity, the client device 12. An exemplary query tracer 52 may include an identifier for the DNS query 122 and an identifier for the client device 12. If the communication protocol allows multiple DNS queries to be made over the same encrypted session, another exemplary query tracer 52 includes a session identifier 56 that identifies the respective session and a client identifier 58 that identifies the client device 12, as shown in FIG. 5. Those skilled in the art will appreciate that the format and encoding of the query tracer 52 may vary and the illustrated embodiment is not intended to be limiting. The IDs 56-58 may be transmitted together in the same transmission or in separate message / data packages. If the IDs 56-58 are transmitted separately, each transmission may include a tag (e.g., an identification hash) that allows the server 40 to associate the session identifier 56 with the client identifier 58.

[0029]

[0050] FIG. 6 illustrates an exemplary encrypted communication session 26 conducted according to a version of the TLS protocol. Such a session may include DNS exchanges conducted over DNS over TLS and / or DNS over HTTPS protocols. Those skilled in the art will appreciate that the use of TLS herein is merely exemplary and not intended to be limiting. As illustrated, the encrypted communication session includes multiple messages (often referred to in the art as TLS records 60). The records 60 may be grouped into a handshake portion / exchange and a payload portion / exchange. The handshake records are sent in preparation for the transmission of a payload, are typically assembled in the clear (unencrypted), and include various metadata such as parameter values ​​for establishing a connection between the respective communication parties, and various cryptographic parameter values ​​necessary to encrypt and / or decrypt the payload. Using TLS as an example, a "ClientHello" handshake record may include a random number (referred to as ClientRandom) used to derive a cryptographic key, and may further indicate a list of ciphers currently supported by the client 12. The "ServerHello" handshake record may include another random number (called ServerRandom) used to derive the encryption key, an indication of the selected cipher, the public key of server 20, etc. Other handshake records may include metadata such as the record type and record size of the respective record, checksums used to verify the integrity of the record, etc.

[0030]

[0051] The handshake is typically followed by transmission of a payload encrypted according to parameter values ​​determined and / or exchanged during the handshake. In the example of Fig. 6 applied to encrypted DNS, an exemplary client payload may include a domain name and an exemplary server payload may include an IP address of the respective Internet domain. In some cases, multiple encrypted DNS queries and / or responses are exchanged sequentially within the same session, i.e., each query and / or response is encrypted according to a session-specific encryption key, and thus each individual query and / or response does not require a separate handshake.

[0031]

[0052] The DNS proxy 50 can operate at various levels of the networking protocol suite, said levels in this specification referring to the Open Systems Interconnection (OSI) model. Figure 7 shows an exemplary generic TLS record 60 from an OSI perspective (which may correspond to any of the TLS records shown in Figure 6, such as a "ClientHello" record). If intercepted at the application level, the record 60 may consist of a set of application data 66. However, if the proxy 50 intercepts the DNS exchange at the transport level, the record 60 may be encapsulated by a Transmission Control Protocol (TCP) header 64. Similarly, if intercepted at the network level, the record 60 may be further encapsulated in an Internet Protocol (IP) header 62. Such headers are shown here by way of example only and may vary depending on the communication protocol and network architecture.

[0032]

[0053] FIG. 8 illustrates exemplary application data 66 for a “Client Hello” TLS record, including multiple metadata fields, including a ClientRandom field and a SessionID field. In some versions of TLS, the ClientRandom field contains a 256-bit random number generated by the client device 12 during the handshake procedure, which is further used by the client device 12 and the server 20 to generate a session-specific encryption key. Some embodiments rely on the observation that since a new ClientRandom value is generated for each handshake, each value can effectively identify a respective DNS session and / or query, either alone or in combination with other query metadata (the same reasoning applies to ServerRandom, which is the content of the ServerRandom field of the handshake exchange sent by the server 20 to the client device 12). The SessionID field contains an identifier of the current exchange that further uniquely identifies each session-specific encryption key, allowing the client device 12 and the server 20 to exchange multiple payloads without renegotiating the handshake. For example, the same SessionID value can be used to encrypt / decrypt DNS queries 122 and DNS responses 124 with the same session-specific key. Some embodiments rely on the observation that such characteristics allow the SessionID value to be used to identify a DNS session 26, DNS query 122 and / or response 124. However, the session identifier 56 is not limited to, and need not have, the same format as the SessionID field. Instead, some embodiments may use the contents of the SessionID field in combination with other data when calculating the session identifier 62.

[0033]

[0054] FIG. 9 illustrates components of an exemplary TCP header 64 known in the art. The header 64 includes a concatenation of multiple metadata fields, such as a source port, a destination port, and a set of flags / control bits. The TCP header flags can be used, for example, to set the priority of the current data packet, reset or terminate the connection / session. The header 64 can also include a sequence number field, which can include a 32-bit random number that identifies the current TCP session. The header 64 can further include a checksum field, which contains a hash of at least a portion of the header 64, which can be used to verify the integrity of the header 64. Some embodiments rely on the observation that an identifier of a TCP session, such as the value of the sequence number field and the value of the checksum field, can be used to identify an encryption session and / or a DNS query. However, such values ​​may be used preferably in combination with other query metadata in the calculation of the session identifier 56, since the range of the respective values ​​is not broad enough to avoid collisions (e.g., multiple queries / sessions coincidentally having the same value of SequenceNumber).

[0034]

[0055] 10 illustrates components of an exemplary IP header 62 known in the art. The header 62 includes a concatenation of metadata fields, such as a source IP address (containing the network address of the sender), a destination IP address (containing the network address of the intended recipient), and a packet identifier. The header 62 may further include a checksum field that contains a hash of at least a portion of the header 62 that can be used to verify the integrity of the header 62. Some embodiments rely on the observation that the source IP address can be used in combination with other query metadata to identify the DNS session 26 and / or the DNS query 122.

[0035]

[0056] In some embodiments, the DNS proxy 50 and / or the DNS server 20 may determine the session identifier 56 according to the cleartext (i.e., unencrypted) portion of the encrypted communication session 26, e.g., according to the contents of the handshake record. In a preferred embodiment, the session identifier 56 may be determined according to the contents of the "ClientHello" TLS record, e.g., according to the contents of the ClientRandom, ServerRandom and / or SessionID fields.

[0036]

[0057] In some embodiments, the session identifier 56 is determined according to the content of the TCP headers of the data packets that are part of the cryptographic session 26, such as the content of a sequence number field and / or the content of a checksum field of the respective TCP headers. In some embodiments, the session identifier 56 is determined according to the content of the IP headers of the data packets that are part of the session 26, such as the content of a source address field, the content of an identification field and / or the content of a checksum field of the respective IP headers.

[0037]

[0058] An example calculation of the session identifier 56 may include combining and / or transforming a set of data extracted from various headers and / or application data fields. One embodiment may concatenate the source address extracted from the IP header 62 with the sequence number extracted from the TCP header 64 and apply a hash function to the result. Those skilled in the art will appreciate that there may be many ways to combine and / or transform a set of data, including but not limited to hashing.

[0038]

[0059] In some embodiments, client identifier 58 (FIG. 5) includes a set of data that distinguishes client device 12 from other client devices. Examples of client identifiers include a MAC address, an IMEI number, and a local network address. In some embodiments, client identifier 58 may not identify each client device individually, but instead indicates a group identity of the respective client devices. For example, client identifier 58 may selectively indicate a device group (e.g., devices in a particular division of a company, devices within a particular network subdomain, devices belonging to a particular home network). In such an embodiment, client identifier 58 may include an IP address from which each DNS query originates.

[0039]

[0060] In some embodiments, the client identifier 58 includes an identifier for the network appliance 14. In one such example, the client devices 12a-12e that belong to the family local network 13 represent a home network, and all of the devices 12a-12e are protected from computer security threats based on a single service contract associated with the network appliance 14. In such an embodiment, including the identifier for the appliance 14 in the client identifier 58 enables the security server 40 to selectively identify access policies according to the service contract associated with each network appliance 14.

[0040]

[0061] Another exemplary client identifier 58 may include an indication of a device profile, thus enabling the security server 40 to selectively retrieve access policies associated with the respective device profile from the policy database 42. Examples of device profile information include, for example, an indication of the device type (e.g., smartphone or desktop PC, etc.), an indication of the operating system running on the respective client device (e.g., which version of Android the originator of the query 122 is currently running), a geographic location indication indicating the current geographic location of the respective client device (e.g., whether the respective device is currently connected to the local network 13 or roaming), an indication of the type of application that issued the current DNS request (e.g., a browser, a social media application, a banking application, etc.), and an identifier of the current user of the respective client device. To determine such data, some embodiments of the DNS proxy 50 may cooperate with software agents running on the client devices 12 and / or on the network appliance 14. In one such example, upon introduction to the local network 13, the appliance 14 may perform a device discovery procedure to determine the device type, etc., of each device 12a-12e. The appliance 14 may then share such device identification data with the DNS proxy 50 .

[0041]

[0062] FIG. 11 illustrates an exemplary sequence of steps performed by the DNS proxy 50 in an embodiment such as that shown in FIG. 4. The proxy 50 may be located in a position where it can intercept communications to and / or from the client devices 12a-12e. Intercepting incoming communications herein includes receiving metadata of each communication and analyzing the payload without decrypting it. In one embodiment, the DNS proxy 50 may run on a gateway device (e.g., on the network appliance 14 as shown in FIG. 1) that mediates data traffic between the local network 13 and the extended network 15 / Internet. In a sequence of steps 302-304, the proxy 50 may listen for connection requests (e.g., TCP requests) from the clients 12a-12e and / or the DNS server 20. Once a request is received, step 306 may determine whether each request is related to DNS activity. Since the incoming communications may be encrypted, it may not be possible to distinguish DNS messages from other data by the content of each communication. However, in some embodiments, DNS traffic may be identified by communication metadata such as the destination IP address (e.g., by matching the destination IP address against a list of addresses of known DNS servers) and / or by port number (e.g., traditional unencrypted DNS protocols typically use port 53, while encrypted DNS typically uses ports 443 or 853). Some embodiments simply forward non-DNS traffic to its intended destination (step 306 returns NO).

[0042]

[0063] If the respective connection request concerns DNS traffic (step 306 returns YES), step 307 determines whether the transmitted data is part of a handshake exchange. In other words, step 307 may determine whether the received request initiates a new encrypted communication session. If not, step 314 may forward the respective payload to its intended destination. If the intercepted communication includes handshake data (step 307 returns YES), step 308 may determine a session identifier 56 according to any of the methods and data items described above with respect to Figures 4-10. A further step 310 may determine a client identifier 58, for example according to the network address from which the respective message was sent. In some embodiments, in step 310, the DNS proxy 50 may receive additional client identification and / or query identification information from a software agent running on the client device 12. In step 312, the DNS proxy 50 may assemble a query tracer 52 and send the tracer 52 to the security server 40. The proxy 50 may then forward the respective payload to its intended destination. In some embodiments, step 314 includes actively rerouting DNS-related communications received from clients 12a-12e to a preferred DNS server, regardless of their original destination, thereby forcing the clients to use the DNS server for domain name resolution activities.

[0043]

[0064] To protect multiple client devices by filtering Internet access, some embodiments of the security server 40 maintain a mapping between DNS queries and devices / users, thereby allowing the server 40 to determine which device and / or user a DNS query belongs to. In some embodiments where multiple queries may occur within the same encrypted communication session, the server 40 may map each session to a corresponding device 12. All queries that are part of the respective session may then be associated with the respective client device. The mapping may be implemented using any method known in the art, for example as a table, a relational database, etc. In some embodiments, the server 40 uses the session identifier 56 as a lookup key / index into a respective table or database to determine which client device and / or user sent which DNS query. In response, the server 40 may access device-specific and / or user-specific access policies associated with the respective device. However, because the DNS queries may be encrypted, the security server 40 may not recognize the domain name 36 included in each query. Instead, some embodiments of the security server 40 may receive the respective domain name from the DNS server 20.

[0044]

[0065] In some embodiments, such as that shown in FIG. 4, in response to receiving and decrypting the DNS queries 122, the DNS server 20 transmits a query notification 46 that associates an identifier of the queries 122 with the domain names 36 contained in each query. An example format of the query notification 46 is shown in FIG. 13, although one skilled in the art will appreciate that the illustrated format is not intended to be limiting. The queries are identifiable collectively according to a session identifier 56 and / or individually according to a query identifier 57 that distinguishes each query from other queries sent within the same session or from other queries resolved by the server 20. The query notification 46 may further include the domain name 36 and / or the result of the resolution of the domain name 36 (e.g., IP address 28). While the illustrated example shows a fully qualified domain name, some query notifications 46 may include a PQDN or other fragment of a domain name. In some embodiments, the query notification 46 may include data characterizing multiple queries. In one such embodiment, the notification 46 includes a session identifier 56 and multiple {query identifier, domain name} tuples corresponding to separate DNS queries made within the same encrypted communication session identified by the session identifier 56.

[0045]

[0066] The session identifier 56, the query identifier 57 and the domain name 36 may be sent as separate messages / data packages, in which case each individual message may include a label / tag (e.g., a hash of the same) that allows the server 40 to associate the IDs 56 and / or 57 with the domain name 36. In one such embodiment, the security server 40 may send a first message including the session identifier 56 to the DNS server 20, which may respond with another message including at least the query identifier 57 and the domain name 36. The response may further include an indicia (e.g., a hash) that associates the respective response with the first message sent by the security server 40, thereby associating the domain name 36 and / or the query identifier 57 with the session identifier 56.

[0046]

[0067] In some embodiments, security server 40 combines the session-client association provided by query tracer 52 with the query-domain association provided by query notification 46 to associate the domain name with a client device and / or user, thereby enabling it to apply device-specific and / or user-specific policies to determine whether the respective client device / user is permitted to access the Internet resource indicated by domain name 36.

[0047]

[0068] Figure 12 shows an exemplary sequence of steps performed by security server 40 in an embodiment such as that shown in Figure 4. Step 402 may listen for incoming communications. If the incoming communication includes a query tracer 52 from DNS proxy 50 (step 404 returns YES), then in step 408 server 40 parses the contents of query tracer 52 and maps session identifier 56 to client identifier 58, for example by creating a new table entry associating ID 56 with ID 57.

[0048]

[0069] When the security server receives the notification 46 from the DNS server 20 (step 406 returns YES), step 410 can identify the communication session and / or query according to the notification 46, for example by parsing the notification 46 to extract the session identifier 56 and / or the query identifier 57. In step 412, the server 40 can then use the session-client mapping described above to find a client identifier indicative of the client device 12a-12e and / or user that generated the respective DNS query. Step 414 can look up the access policy associated with the respective client identifier in the policy database 42.

[0049]

[0070] A further step 416 may determine an access indicator 37 according to the result of the determination whether the access policy retrieved in step 414 specific to the respective client device and / or user allows access to the domain identified by the domain name 36. In a simple embodiment, the access indicator 37 comprises a flag (e.g., a bit) that, when set, indicates to deny access of the client device 12 to the respective domain. In another embodiment, the access indicator 37 comprises an indication of an action (e.g., allow, block, redirect, display a warning page, etc.) to be taken in response to an attempt by the respective client device to access the respective domain.

[0050]

[0071] Step 416 may include evaluating the domain name 36 according to an access policy, and possibly other data, such as the current user of the client device 12, the current time, the current physical location of the client device, etc. Step 416 may further include looking up the domain name 36 in a security database 44 to determine whether access to the Internet domain having the domain name 36 may constitute a computer security threat. For example, the security database 44 may indicate that the domain name 36 is blacklisted as being associated with scams, phishing, malicious software, pornography, online gambling, etc.

[0051]

[0072] In response to determining the access indicator 37, in step 418, the security server 40 may transmit the access indicator 37 to the DNS server 20. In some embodiments, the access indicator 37 is bundled with a query identifier 57 into a security verdict 48, thereby allowing a recipient of the verdict 48 to associate the access indicator 37 with a particular query, client device and / or communication session. In one such embodiment, the DNS server 20 maintains a mapping of queries 122 and access indicators 37 using, for example, a table with the query identifier 57 as a lookup key / index.

[0052]

[0073] Figures 14A-14B show exemplary sequences of steps performed by DNS server 20 in an embodiment such as that shown in Figure 4. The two sequences (Figures 14A and 14B, respectively) can be executed synchronously by different computer programs and / or hardware modules of DNS server 20.

[0053]

[0074] Step 502 may listen for incoming communications. In response to receiving a communication, step 504 may determine whether the respective communication was received from security server 40. If YES, indicating that the respective communication includes a security decision / access indicator, in step 506 server 20 may parse security decision 48 to identify the DNS query to which decision 48 refers and update stored mappings to associate current access indicators 37 with the respective query identifiers 57.

[0054]

[0075] If the incoming communication is part of an established session and includes an encrypted DNS query (step 508 returns YES), step 509 determines an identifier for the respective session. Step 509 may be performed according to any of the methods and data sources described above in connection with figures 6-10, so long as the instance of the session identifier calculated by the DNS proxy 50 and the instance of the session identifier calculated by the DNS server 20 match for the same session. In step 510, the DNS server 20 may proceed to decrypt the DNS query included in the respective communication to generate the domain name 36. Step 512 may assign a query identifier to each query to distinguish it from other queries of the same session. Those skilled in the art will appreciate that there may be many ways to generate a unique identifier. Step 512 may use any method known in the art to generate the query identifier 57.

[0055]

[0076] In step 513, the DNS server 20 may perform a domain resolution procedure to generate a network address (e.g., an IP address) for the domain having the domain name 36. The domain name resolution may include multiple DNS queries directed to various subsystems of the server 20, as described above in connection with Figure 3. Step 514 then assembles a query notification 46 that includes the session identifier 56, the query identifier 57, and the domain name 36, and sends the notification 46 to the security server 40.

[0056]

[0077] In some embodiments, the DNS server 20 places the incoming queries in a pool to await receipt of the respective access indicator from the security server 40 (step 516 in FIG. 14A). Such a pool can allow the server 20 to process the incoming queries asynchronously, thus preventing problems caused by irregular communication and processing delays. The query pool can be implemented using any method known in the art, such as a queue, a stack, etc. FIG. 14B illustrates exemplary steps taken by the DNS server 20 to process a pool of DNS queries, according to some embodiments of the present invention. Step 520 determines whether there is currently an unprocessed query in the pool. If yes, step 522 selects a query and removes the selected query from the pool. Step 524 can search a data structure that maps queries to access indicators to determine whether an access indicator has been received for the selected query. If there is currently no access indicator 37 for the respective query, the selected query can be returned to the query pool (step 534). In some embodiments, step 532 determines whether an expiration condition is met (e.g., the time that has elapsed since the selection query was received at server 20 exceeds a predetermined threshold) and returns the selection query to the query pool only if the expiration condition is not met. If the expiration condition is met, in step 538, some embodiments formulate a default DNS response that includes, for example, an error code.

[0057]

[0078] If an access indicator is currently available for the selection query (step 524 returns YES), step 526 assembles a DNS response according to the access indicator 37. The respective DNS response may include an IP address, e.g., an address determined in step 513, or an alternate / dummy IP address that redirects the client device 12 to an alternative Internet domain, a warning page, or the like. In some embodiments, the respective DNS response may include a NXDOMAIN error code if the indicator 37 instructs the server 20 to block access. A further sequence of steps 528-530 may encrypt the respective response and send the encrypted DNS response 124 via the DNS proxy 50 to the originator of the selection query.

[0058]

[0079] The above description was primarily directed to the exemplary embodiment shown in FIG. 4, where the DNS server 20 is the entity that ultimately enforces the access policy (i.e., allows or denies access to a particular domain), while the DNS proxy 50 simply forwards incoming DNS messages to their intended recipients. In another embodiment, the security server 40 sends a security decision 48 to the DNS proxy 50 (rather than the DNS server 20 as shown in FIG. 4). The DNS proxy 50 can then actively enforce the access policy according to the decision 48. However, the DNS proxy 50 may not be able to distinguish between separate queries sent within the same session, due to the respective communications being encrypted. In such a case, one example of how the proxy 50 can enforce the access policy includes terminating the entire session if the access indicator associated with at least one query of the respective session indicates that access to the respective domain is blocked.

[0059]

[0080] To avoid such indiscriminate session termination, some embodiments enforce access policies not by interfering with DNS transactions, but by selectively allowing or preventing selected client devices from connecting to IP addresses resulting from resolving DNS queries. One such example, shown in FIG. 16, illustrates an exemplary traffic filter 70 communicatively coupled to the DNS proxy 50 and configured to intercept access requests 72, including requests for access to IP addresses 28, e.g., as part of accessing Internet resources hosted by the content server 16. Some embodiments of the traffic filter 70 intercept such requests at the transport layer of the OSI network model (e.g., at the TCP level). In some embodiments, the traffic filter 70 is configured to prevent the request 72 from reaching the server 16 in response to the access indicator 37 receiving a security decision 148 from the security server 40 indicating that the requesting client device 12 (identified by ID 58) should be prevented from accessing the IP address 28. In some embodiments, both the DNS proxy 50 and the traffic filter 70 may be implemented as hardware and / or software components running on a network gateway, such as the network appliance 14 of FIG. 1, i.e., on a device through which traffic passes between the clients 12a-12e and the content server 16.

[0060]

[0081] FIG. 16 illustrates an exemplary message exchange involving a traffic filter 70 according to some embodiments of the present invention. In some embodiments as illustrated in FIG. 16, the operation of the DNS proxy 50 may proceed according to the exemplary flow chart illustrated in FIG. 11. In response to receiving the query tracer 52, some embodiments of the security server 40 may request from the DNS server 20 at least the results of resolving queries belonging to the encrypted session identified by the session identifier 56. In one such embodiment, the security server 40 may send the session identifier 56 to the DNS server 20. The DNS server 20 may then send to the security server 40 a query notification 146 including at least one tuple including a query identifier 57, a domain name 36, and an IP address 28 corresponding to a query of the respective session. In some embodiments, the notification 146 enables the server 40 to associate the query identified by the ID 57 with the session identified by the session identifier 56 and further with the client identified by the client identifier 58 according to a session-client mapping maintained by the server 40 as described above in connection with FIG. 4.

[0061]

[0082] In some embodiments, security server 40 may then access client-specific and / or user-specific access policies according to client identifier 58 to determine access indicator 37 as described above in connection with Figure 12. However, unlike step 418 of Figure 12, server 40 may send access indicator 37 to traffic filter 70 to enforce the access policy. In some embodiments as shown in Figures 15-16, indicator 37 is bundled with client identifier 58 and IP address 28, thereby enabling filter 70 to enforce the access policy by selectively blocking requests to access the respective IP addresses when the respective requests arrive from the client identified by the respective client identifier.

[0062]

[0083] Figures 17A-17B show exemplary sequences of steps performed by traffic filter 70 in the embodiment as shown in Figures 15-16. The two sequences (Figures 17A and 17B, respectively) can be executed synchronously by different computer programs and / or hardware modules of traffic filter 70.

[0063]

[0084] Step 602 may listen for incoming communications, which may include a security decision 146 from the server 40 and an access request 72 from a client. Upon receiving a communication from the security server 40 (step 604 returns YES), the filter 70 parses the decision 146 in step 606 and maps the IP address 28 to a client identifier 58 and an access indicator 37. Upon intercepting the access request (step 608 returns YES), the filter 70 may determine in step 610 the client identifier of the client device requesting access. A further step 612 may map the access request 72 to a client identifier 58.

[0064]

[0085] Some embodiments of the traffic filter 70 maintain a pool (e.g., a queue) of pending access requests in which incoming requests are delayed until receiving the respective access indication from the security server 40. By pooling the requests, the filter 70 can process the access requests asynchronously, thus improving the user experience. In such embodiments, step 614 can add the current request to the request pool. Step 620 (FIG. 17B) can determine whether the pool currently has an unprocessed item, and if YES, step 620 can select and remove the access request from the pool. In step 624, the filter 70 can determine whether it has already received an access indication associated with the IP address of the selected request. Step 624 can look up the respective IP address in a mapping (e.g., a table that associates IP addresses with client identifiers and access indications; see above in connection with step 606). If there is no access indication currently registered for the respective IP address and client identifier, some embodiments can insert the selected access request into the request pool (step 632). Some embodiments may first verify whether an expiration condition is met and return the selected request to the pool only if step 630 returns NO. If an expiration condition is met, then in step 634 some embodiments of filter 70 may prevent access to the respective IP address.

[0065]

[0086] If the mapping maintained by filter 70 currently stores an access indicator 37 corresponding to the respective IP address and client identifier tuple (step 624 returns YES), a further step 626 determines whether the respective access indicator allows access to the respective IP address. If YES, step 628 may forward the selected access request to content server 16. If NO, some embodiments block the selected access request.

[0066]

[0087] Although the above description illustrates various methods and algorithms that can be implemented as computer programs executed by a general-purpose hardware processor, those skilled in the art will appreciate that the respective functions can also be implemented using dedicated hardware components, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). FIG. 18 illustrates an exemplary hardware configuration of a computer system 80 that can be programmed to implement some of the methods and algorithms described herein. The illustrated configuration is generic and can correspond to, for example, any of the client devices 12a-12e, the network appliance 14, the DNS server 20, and the security server 40, etc. Those skilled in the art will appreciate that the hardware configuration of some devices (e.g., mobile phones, smart watches, servers, routers) may differ slightly from that illustrated in FIG. 18.

[0067]

[0088] The illustrated computer system includes a set of physical devices including a hardware processor 82 and a memory unit 84. The processor 82 includes a physical device (e.g., a microprocessor, a multi-core integrated circuit formed on a semiconductor substrate, etc.) configured to perform computational and / or logical operations using a set of signals and / or data. In some embodiments, such operations are delivered to the processor 82 in the form of a sequence of processor instructions (e.g., machine code or other type of encoding). The memory unit 84 may include a volatile computer-readable medium (e.g., DRAM, SRAM) that stores instructions and / or data accessed or generated by the processor 82.

[0068]

[0089] The input devices 86 may include a computer keyboard, mouse, microphone, and the like, including respective hardware interfaces and / or adapters that allow a user to introduce data and / or instructions into the respective computer system. The output devices 88 may include a display device such as a monitor and speakers, and the like, as well as hardware interfaces / adapters, such as a graphics card, that allow the illustrated computing appliance to communicate data to a user. In some embodiments, the input devices 86 and the output devices 88 share common hardware, as in the case of a touch screen device. The storage devices 92 include computer-readable media that allow for the non-volatile storage, reading, and writing of software instructions and / or data. Examples of the storage devices 92 include magnetic and optical disks and flash memory devices, as well as removable media, such as CD and / or DVD disks and drives. A set of network adapters 94, together with associated communication interfaces, allow the illustrated computer system to connect to computer networks, such as the local network 13 (FIG. 1), and / or other devices / computer systems. Controller hub 90 collectively represents multiple system, peripheral and / or chipset buses and / or any other circuitry that enables communication between processor 82 and devices 84, 86, 88, 92, and 94. For example, controller hub 90 may include a memory controller, an input / output (I / O) controller, an interrupt controller, etc. In another embodiment, controller hub 90 may include a northbridge that connects processor 82 to memory 84 and / or a southbridge that connects processor 82 to devices 86, 88, 92, and 94.

[0069]

[0090] The above-described exemplary systems and methods allow selective control of how a large number of heterogeneous client devices (such as personal computers, smartphones, TVs, thermostats, door locks, refrigerators, IoT devices such as wearables, etc.) access the Internet. Such control is essential for applications such as computer security (protecting users and devices from malicious content and / or Internet fraud), parental control (monitoring and / or restricting access to certain online content for certain devices / users), and application control (monitoring and / or restricting the use of selected software such as social media, streaming, gaming, gambling and instant messaging applications). Selection, as used herein, refers to the ability to apply device-specific and / or user-specific access policies.

[0070]

[0091] Some embodiments implement selective Internet access by manipulating Domain Name Service (DNS) mechanisms. For clarity and simplicity of explanation, the above disclosure uses the term "Domain Name Service" to refer to conventional DNS as currently used in Internet communications. Specifically, encrypted DNS has been illustrated using the DNS over TLS and DNS over HTTP protocol families. However, those skilled in the art will appreciate that the methods and systems described herein can be readily adapted to any other services, versions and protocols for converting domain names to network addresses and vice versa.

[0071]

[0092] Various schemes of using DNS to control Internet access are known in the art. One such example modifies each DNS query by inserting a tag that can serve as a device identifier. The modified DNS query is then sent to a DNS server that enforces access policies according to the respective tag. In one example of parental control, in response to receiving a DNS query tagged with a client identifier, a DNS server can selectively choose to return or not return an IP address according to the client's identity and / or the requested domain name. However, in a cryptographic domain name system, modifying a DNS query requires decrypting the DNS query, which in turn requires obtaining and maintaining an additional public key certificate specific to the device that operates the modification. Maintaining the certificates can be costly and cumbersome, and can create unique computer security vulnerabilities.

[0072]

[0093] Unlike such conventional solutions, some embodiments of the present invention use a DNS proxy to intercept an encrypted communication session between a client device and a DNS server, and calculate a session identifier that collectively identifies a set of DNS queries sent during the respective session, without decrypting any communication. An exemplary session identifier according to some embodiments of the present invention can be calculated according to a ClientRandom value sent by the client device as part of a handshake exchange with the DNS server. The DNS proxy can then forward the DNS query to the DNS server, which can decrypt it, resolve it, and send back a DNS response that includes the network address of the Internet resource to which the respective client device is requesting access.

[0073]

[0094] The session identifier determined by the DNS proxy can be sent to the security server and / or DNS server via a side channel along with a client identifier that identifies the device and / or user that initiated the respective DNS session. The term "side channel" is used herein intuitively to describe a communication channel that is different from the encrypted communication session that connects the client to the DNS server. In some embodiments, the DNS server and the security server can then cooperate to enforce the access policy by selectively denying or allowing access to a particular Internet resource according to the identity of the requesting device and / or user. In one example, the security server receives the decrypted domain name from the DNS server and determines whether the respective device or user should be allowed to access the requested domain according to the device-specific and / or user-specific access policy and instructs the DNS server accordingly. To deny access, the DNS server can return an error or a dummy IP address to the DNS query from the respective client. In another exemplary embodiment, the security server obtains from the DNS server the IP address that is the result of resolving the domain name received in the encrypted DNS query from the client. The security server can then send the respective addresses to a traffic filter, which can enforce the access policy by blocking attempts by the respective client to access the respective IP addresses.

[0074]

[0095] By avoiding the need to decrypt intercepted DNS queries (and thus the need for dedicated public key certificates), some embodiments allow the DNS proxy and / or traffic filter to be installed on an intermediate means between the client device and the DNS server, such as a gateway device or router that assigns network addresses to client devices on a home network (see, for example, network appliance 14 as shown in FIG. 1 ). Such a location has the significant advantage, for example, of eliminating the need to install additional software on the end client, which is protected simply by joining the local network and defining access policies.

[0075]

[0096] Another advantage of running the DNS proxy 50 on a gateway device is that actions taken on the DNS proxy 50 are substantially undetectable by software running on client devices. Importantly, malware that may be running on a client device cannot interfere with or impair the activities of the DNS proxy. Another advantage is that a typical gateway device already performs some form of computer security activity, for example implementing a firewall or collecting traffic metadata, and DNS filtering as disclosed herein can enhance and / or take advantage of that existing functionality.

[0076]

[0097] Yet another important advantage of a configuration in which the DNS proxy 50 runs on a gateway device is awareness of the local network topology. In the exemplary network configuration shown in Figure 1, the DNS server 20 typically cannot distinguish between DNS queries coming from client devices 12a and 12b (because both queries will typically originate from the same IP address), but the appliance 14 can. Thus, placing the DNS proxy 50 on the gateway device enables the gateway device to identify the source of an incoming DNS query, and therefore to efficiently associate the query with a client device and / or user.

[0077]

[0098] It will be apparent to those skilled in the art that the above embodiments can be modified in many ways without departing from the scope of the present invention. Therefore, the scope of the present invention should be determined by the following claims and their legal equivalents.

Claims

1. 1. A computer system including at least one hardware processor, the hardware processor comprising: receiving, from the DNS proxy, a query tracer characterizing an encrypted communication session between the client device and the DNS server; the DNS proxy is connected to the client device via a local network; the encrypted communication session includes a plaintext portion and an encrypted portion, the encrypted portion including the client device sending an encrypted DNS query to the DNS server; the query tracer associates a session identifier with a client identifier, the client identifier identifying the client device, the session identifier identifying the encrypted communication session and determined according to content of the plaintext portion; Receiving a query tracer; receiving a query notification from the DNS server including a domain name included in the encrypted DNS query, the query notification further associating the domain name with the session identifier; determining an access indicator according to the query tracer and the query notification, the access indicator indicating whether an access policy selected according to the client identifier allows the client device to access an Internet domain having the domain name; communicating said access indication to enforce said access policy; A computer system configured to:

2. 2. The computer system of claim 1, wherein the cleartext portion includes a handshake including a Client Hello message sent by the client device to the DNS server and a Server Hello message sent by the DNS server to the client device, and the session identifier is determined according to content of the Client Hello message or according to content of the Server Hello message.

3. 3. The computer system of claim 2, wherein the session identifier is determined according to a ClientRandom value sent by the client device to the DNS server during the handshake.

4. 2. The computer system of claim 1, wherein the at least one hardware processor is configured to communicate the access indicator to the DNS server.

5. 2. The computer system of claim 1, wherein the at least one hardware processor is configured to communicate the access indication to a traffic filter, the traffic filter comprising: intercepting attempts by the client device to access the Internet domain; in response, if the access indication indicates that the client device is not authorized to access the Internet domain, preventing the client device from accessing the Internet domain. A computer system configured to:

6. 2. The computer system of claim 1, wherein the query tracer includes the session identifier and the client identifier.

7. 2. The computer system of claim 1, wherein the query notification includes the domain name and the session identifier.

8. 8. The computer system of claim 7, wherein the query notification further includes a query identifier that identifies the encrypted DNS query and an IP address generated by resolving the encrypted DNS query.

9. Using at least one hardware processor of a computer system, receiving, from the DNS proxy, a query tracer characterizing an encrypted communication session between the client device and the DNS server; the DNS proxy is connected to the client device via a local network; the encrypted communication session includes a plaintext portion and an encrypted portion, the encrypted portion including the client device sending an encrypted DNS query to the DNS server; the query tracer associates a session identifier with a client identifier, the client identifier identifying the client device, the session identifier identifying the encrypted communication session and determined according to content of the plaintext portion; Steps and receiving a query notification from the DNS server including a domain name included in the encrypted DNS query, the query notification further associating the domain name with the session identifier; determining an access indicator according to the query tracer and the query notification, the access indicator indicating whether an access policy selected according to the client identifier allows the client device to access an Internet domain having the domain name; communicating said access indication to enforce said access policy; The method includes:

10. 10. The method of claim 9, wherein the cleartext portion includes a handshake including a Client Hello message sent by the client device to the DNS server and a Server Hello message sent by the DNS server to the client device, and the session identifier is determined according to content of the Client Hello message or according to content of the Server Hello message.

11. The method of claim 10 , wherein the session identifier is determined according to a ClientRandom value sent by the client device to the DNS server during the handshake.

12. 10. The method of claim 9, wherein the at least one hardware processor is configured to communicate the access indication to the DNS server.

13. 10. The method of claim 9, wherein the at least one hardware processor is configured to communicate the access indication to a traffic filter, the traffic filter comprising: intercepting attempts by the client device to access the Internet domain; in response, if the access indication indicates that the client device is not authorized to access the Internet domain, preventing the client device from accessing the Internet domain. The method is configured to:

14. The method of claim 9 , wherein the query tracer includes the session identifier and the client identifier.

15. The method of claim 9 , wherein the query notification includes the domain name and the session identifier.

16. 16. The method of claim 15, wherein the query notification further includes a query identifier that identifies the encrypted DNS query and an IP address generated by resolving the encrypted DNS query.

17. A non-transitory computer readable medium storing instructions that, when executed by at least one hardware processor of a computer system, cause the computer system to: receiving, from the DNS proxy, a query tracer characterizing an encrypted communication session between the client device and the DNS server; the DNS proxy is connected to the client device via a local network; the encrypted communication session includes a plaintext portion and an encrypted portion, the encrypted portion including the client device sending an encrypted DNS query to the DNS server; the query tracer associates a session identifier with a client identifier, the client identifier identifying the client device, the session identifier identifying the encrypted communication session and determined according to content of the plaintext portion; Receiving a query tracer; receiving a query notification from the DNS server including a domain name included in the encrypted DNS query, the query notification further associating the domain name with the session identifier; determining an access indicator according to the query tracer and the query notification, the access indicator indicating whether an access policy selected according to the client identifier allows the client device to access an Internet domain having the domain name; communicating said access indication to enforce said access policy; A non-transitory computer storage medium that causes

Images