Privacy-preserving filtering of encrypted traffic

Abstract

BTD-2104 5 / 2 / 2023 33. Privacy-Preserving Filtering of Encrypted Traffic. Abstract. The described systems and methods protect client devices, such as personal computers and IoT devices, from harmful or inappropriate Internet content. When a client uses an encrypted handshake to hide the identity of the end server, e.g., for applications that implement an Encrypted Client Hello (ECH), some embodiments use a modified DNS server to provide the client with a surrogate key instead of the real handshake key. A traffic filter, e.g., running on a network gateway, then intercepts and decrypts the handshake and applies an access policy to selectively allow or deny access to the respective end server. If access is granted, the traffic filter may re-encrypt the server identifier using the real handshake key before forwarding the handshake to its destination. Because the illustrated method only decrypts the handshake and not the actual payload, privacy of the communication is maintained.

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, affects many computer systems worldwide. Many forms of malware, including computer viruses, Trojan horses, spyware, and ransomware, pose serious risks to millions of computer users, making them vulnerable to loss of data and confidential information, identity theft, and lost productivity. A key vector for the spread of malware is through users' inadvertent access to malicious or fraudulent online content.

[0003]

[0003] Meanwhile, an ever-increasing number of devices, referred to as the Internet of Things (IoT), are connected to communication networks and the Internet. Such devices include, among others, smartphones, smart watches, televisions and other multimedia devices, game consoles, home appliances, and various home sensors such as thermostats. As such devices come online, they become subject to security threats such as malware and intrusions. Thus, there is an increasing need to protect such devices from malware as well as to secure communications to and from such devices. Particular areas of interest arising from the emergence of the Internet of Things include access control applications, for example parental control and preventing the transmission of sensitive information via IoT devices.

[0004]

[0004] Conventional methods of protecting users and devices include using security products, such as network gateways, to intercept access requests (e.g., HTTP) and / or Domain Name Service (DNS) requests sent by the protected device when attempting to access a remote Internet resource. The domain name or IP address specified in the intercepted request may then be compared to a blacklist of known malicious domains or addresses. Thus, the security product may block access to unsafe domains or addresses.

[0005]

[0005] Recent concerns about user privacy have led to the development of encrypted domain name services, such as DNS over hypertext transport protocol secure (DoH), described in Internet Engineering Task Force (IETF) Request for Comments (RFC) 8484. Additionally, some communication protocols, such as Transport Layer Security (TLS), allow for encryption of at least a portion of the handshake exchange, for example, to keep destination servers private. Unfortunately, such new developments in Internet communications may hinder computer security operations by preventing intermediaries (e.g., routers) from performing traditional traffic filtering.

[0006]

[0006] Accordingly, there is considerable interest in developing computer security systems and methods that allow traffic filtering in the case of encrypted DNS and communication protocols that use encrypted handshakes. Summary of the Invention

[0007]

[0007] According to one aspect, a method includes using at least one hardware processor of a computer system to intercept a client handshake message to establish an encrypted communication session between a client device and a remote content server. The client handshake message includes an encrypted portion that stores an identifier of the remote content server. The method further includes decrypting the encrypted portion to obtain the identifier of the remote content server, and determining whether an access policy associated with the client device allows the client device to access the remote content server according to the identifier of the remote content server. In response, if the access policy allows the client device to access the remote content server, the method further includes determining a handshake encryption key according to the identifier of the remote content server, and modifying the client handshake message by replacing the encrypted portion with an alternative encrypted portion that stores the identifier of the remote content server. The alternative encrypted portion is encrypted using the handshake encryption key. The method further includes sending the modified handshake message to a destination of the client handshake message, and relaying other messages to the client device in response to intercepting other messages sent by the remote content server in the encrypted communication session.

[0008]

[0008] According to another aspect, a computer system includes at least one hardware processor programmed to execute a traffic filter configured to intercept a client handshake message to establish an encrypted communication session between a client device and a remote content server. The client handshake message includes an encrypted portion storing an identifier of the remote content server. The traffic filter is further configured to decrypt the encrypted portion to obtain the identifier of the remote content server, and to determine whether an access policy associated with the client device allows the client device to access the remote content server according to the identifier of the remote content server. In response, if the access policy allows the client device to access the remote content server, the traffic filter is further configured to determine a handshake encryption key according to the identifier of the remote content server, and to modify the client handshake message by replacing the encrypted portion with an alternative encrypted portion storing the identifier of the remote content server. The alternative encrypted portion is encrypted using the handshake encryption key. The traffic filter is further configured to send the modified handshake message to a destination of the client handshake message and, in response to intercepting other messages sent by the remote content server within the encrypted communication session, relay other messages to the client device.

[0009]

[0009] According to another aspect, a non-transitory computer-readable medium stores instructions that, when executed by at least one hardware processor of a computer system, cause the computer system to execute a network filter configured to intercept a client handshake message to establish an encrypted communication session between a client device and a remote content server. The client handshake message includes an encrypted portion that stores an identifier of the remote content server. The traffic filter is further configured to decrypt the encrypted portion to obtain the identifier of the remote content server, and to determine whether an access policy associated with the client device allows the client device to access the remote content server according to the identifier of the remote content server. In response, if the access policy allows the client device to access the remote content server, the traffic filter is further configured to determine a handshake encryption key according to the identifier of the remote content server, and to modify the client handshake message by replacing the encrypted portion with an alternative encrypted portion that stores the identifier of the remote content server. The alternative encrypted portion is encrypted using the handshake encryption key. The traffic filter is further configured to send the modified handshake message to a destination of the client handshake message and, in response to intercepting other messages sent by the remote content server within the encrypted communication session, relay other messages to the client device.

[0010]

[0010] The foregoing aspects and advantages of the present invention will be better understood from reading the following detailed description and by reference to the drawings, in which: [Brief description of the drawings]

[0011] [Figure 1]FIG. 1 is a diagram illustrating an exemplary set of client devices protected from computer security threats in accordance with some embodiments of the present invention. [Diagram 2]

[0012] FIG. 2 is a diagram illustrating a typical data exchange performed according to a protocol for encrypted communications known in the art. [Diagram 3]

[0013] FIG. 3 is a diagram illustrating an exemplary data exchange according to a version of a communications protocol that uses an encrypted handshake. [Figure 4]

[0014] FIG. 4 is a diagram illustrating an exemplary data exchange between a client device, a DNS server, and a front server according to some embodiments of the present invention. [Diagram 5]

[0015] FIG. 5 is a diagram illustrating an example client handshake message according to some embodiments of the invention. [Figure 6-A]

[0016] FIG. 6-A is a diagram illustrating an exemplary sequence of steps performed by a traffic filter according to some embodiments of the present invention. [Figure 6-B]

[0017] FIG. 6-B is a diagram illustrating another exemplary sequence of steps performed by a traffic filter according to some embodiments of the present invention. [Figure 7]

[0018] FIG. 7 illustrates an exemplary hardware configuration of a computer system programmable to execute methods and algorithms according to some embodiments of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012]

[0019] In the following description, it is understood that 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 recitation of an element is understood to refer to at least one element. A plurality of elements includes at least two elements. Unless specifically 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 not only a first element equal to a second element, but also a first element generated by processing a second element and optionally other data. Determining or determining according to a parameter includes determining or determining according to a parameter and, optionally, other data. Unless otherwise specified, an indicator of a certain amount / data may be the amount / data itself or an indicator different from the amount / data itself. A computer program is a sequence of processor instructions that perform a task. The computer programs described in some embodiments of the present invention 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 a distinct part 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 herein means determining the network address of the domain with the respective domain name. Metadata, as used herein, indicates characteristics of a transmission other than the payload itself. Exemplary metadata include sender and / or receiver network addresses, payload size, and timestamps indicating the actual time of each transmission, etc.Two devices are considered to be connected to or belong to the same local network if their network addresses belong to the same subnet and / or both devices have the same broadcast address. A wide area network includes at least one router. In this specification, the term "database" is used to denote any organized collection of data. A session identifier as described herein may include, but is not limited to, the contents of the SessionID field of a TLS ClientHello record. As used herein, relaying a message means passing the respective message without modifying its contents. A computer-readable medium encompasses non-transitory media such as magnetic, optical, and semiconductor storage media (e.g., hard drives, optical disks, flash memory, DRAM), as well as communication links such as conductive cables and fiber optic links. According to some embodiments, the present invention provides, among other things, computer systems including hardware (e.g., one or more processors) programmed to perform the methods described herein, as well as computer-readable media encoding instructions for performing the methods described herein.

[0013]

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

[0021] FIG. 1 illustrates a system 10 for protecting a set of client devices 12a-e from computer security threats in accordance with some embodiments of the present invention. Exemplary client devices 12a-e include personal computer systems, corporate 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), consumer electronics (e.g., refrigerators, washing machines), and any other electronic device that includes a processor, memory, and a communication interface that allows each device to communicate with other devices / computer systems. Exemplary client devices 12a-e may request access to remote content servers 22a-c over communication links and exchange data, such as web content, electronic messages, various documents, and the like. In some embodiments, access to servers 22a-c is regulated by traffic filters, as described in more detail below.

[0014]

[0022] In the exemplary configuration of FIG. 1, client devices 12a-e are interconnected by a local network 13, such as a local area network (LAN), a home network, an enterprise network, etc. Devices 12a-e 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-e and extended network 15 passes through a network product 14, such as a router, a WiFi hotspot, a network hub, etc. In the illustrated configuration, product 14 serves as a gateway device between local network 13 and extended network 15. In some embodiments, network product 14 includes a traffic filter configured to selectively enable access to locations on extended network 15, as described in further detail below. Product 14 may further perform various other computer security operations, such as a firewall, scanning communications for malware, etc.

[0015]

[0023] In some embodiments, the system 10 further includes a client policy database 24 and a content index 25, which may be stored on a remote server system further configured to perform selective data insertion, data retrieval, and / or other database management operations. The databases 24, 25 may be formatted and stored according to any standard known in the art. Exemplary database formats include relational databases, Extensible Markup Language (XML) databases, spreadsheets, key-value stores, and the like.

[0016]

[0024] The policy database 24 may store multiple client records associated with the client devices 12a-e and / or associated with users of the respective client devices. In one example, each client record corresponds to a separate client device 12a-e. The client records may store a set of identifiers for the respective client devices (e.g., a client identifier described below, a Media Access Control-MAC address, an International Mobile Equipment Identity-IMEI number, a local network address, etc.) and an indicator of an Internet access policy specific to the respective client device. The access policy encodes rules or restrictions for accessing Internet content. For example, the access policy indicator may include an indicator of a category of content (e.g., adult content, social networking, online gambling, etc.) that the respective client device should not access. The access policy may further include a time indicator, e.g., a time interval for application of the respective policy. The access policy may further include a location indicator indicating an area of ​​application of the respective policy. In one such example, one access policy may apply when each respective device is connected to the local network 13 (e.g., at home) and another policy may apply when each respective device is roaming. Another exemplary policy may apply only within the boundaries of a pre-determined geofence. In some embodiments, the access policy 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]

[0025] In some embodiments, the client records may include other data that may be relevant to access policies. Examples include an indicator of device type (e.g., digital camera, thermostat, smartphone, tablet computer, router, car), various hardware configuration indicators 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 exemplary client records may include metadata describing network traffic sent or received by each client device. In some embodiments, such metadata may be organized according to a format such as the Internet Engineering Task Force's IP Flow Information Export (IPFIX) or Cisco's NetFlow®.

[0018]

[0026] In some embodiments, the policy database 24 may store records indicating collective access policies. One exemplary collective access policy applies to all devices having a particular device profile, as defined by a tuple of device features, such as device type and operating system. In one such example, one access policy may apply to desktop computers, another 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, and so on. Another collective access policy may apply to all devices belonging to a group or organization. In one such example, all devices connected to the local network 13 may be defined by a collective access policy attached to the network product 14. In yet another example, one access policy may apply to devices operated by employees in the engineering department, another to devices operated by employees in the legal department of the company, and so on.

[0019]

[0027] The content index 25 generally represents any collection of data from which it is possible to determine whether access to a particular Internet resource / location / service constitutes a computer security hazard and / or a violation of an access policy, such as parental control. In a simple example, the index 25 includes a set of records indexed according to domain names or IP addresses, with each record indicating a category of content stored in or distributed from the respective domain. Exemplary categories include malicious content (e.g., malware, scam web pages, phishing web pages, dark web, etc.), adult content, streaming, gambling, social networking, e-commerce, banking, gaming, etc.

[0020]

[0028] In some embodiments, the domain name service (DNS) server 18 cooperates with traffic filters (e.g., software components executing on the product 14) described below to protect the client devices 12a-e from computer security threats. The DNS server 18 provides domain name services to the client devices 12a-e, each of which includes translating domain names to network addresses and / or vice versa by maintaining a mapping between the domain names and network addresses. The server 18 generally represents a set of communicatively coupled computers that may or may not be physically proximate to one another. Skilled artisans will recognize that the operations of the DNS server 18 described herein may be split across multiple physical machines or processors, e.g., authoritative name servers, top-level domain name servers, root name servers, cryptographic key servers, etc.

[0021]

[0029] A typical communication between the client devices 12a-e and the content servers 22a-c includes several steps. Such communication requires knowing the network address (e.g., Internet Protocol-IP address) of the respective content server. Often, this address is unknown to the client for various reasons. For example, there may be multiple mirror content server machines, and the client may be dynamically directed to the most convenient machine according to the current load of each mirror server or according to the current geographic 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 respective content server, a software entity running on the respective client device may issue a request to access the respective domain name, rather than the IP address itself. In response, another software entity (e.g., operating system) of the client device may attempt to translate the alias / domain name into the actual network address and then send this request to the correct network location.

[0022]

[0030] Translating a domain name to a network address (an operation known in the art as domain name resolution) typically involves a respective client device sending a DNS query to the DNS server 18. The DNS query may include an encoding of the domain name and an indicator, such as Q, indicating the type of question. The type of question indicates the type of DNS resource record that will be returned by the DNS server 18 in response to the respective query. Exemplary queries include "A", which requests an IP address formulated in the fourth version of the Internet Protocol (IPv4), and "AAAA", which returns an IP address formulated in the sixth version of the Internet Protocol (IPv6). Other exemplary query / resource record types include "TXT", "PTR", "LOC", etc. In response to the query, the DNS server 18 may return a DNS response to the requesting client that includes an encoding of a network address (e.g., an IPv6 address) corresponding to the respective domain name / alias.

[0023]

[0031] In some cases, as illustrated in FIG. 1, multiple content servers 22a-c and / or Internet domains are collectively accessed via a common network address and physical machine exemplified by the front server 20. Such a situation occurs, for example, in content delivery networks (CDNs) such as AKAMAI® and CLOUDFLARE®, and in many applications known under the umbrella term "cloud computing". In such cases, all servers 22a-c and / or respective Internet domains appear to be located at the network address of the front server 20. In other words, a DNS query for any domain associated with the content servers 22a-c returns the IP address of the front server 20. To enable the front server 20 to selectively direct incoming access requests to the appropriate content server 22a-c, each access request is typically configured to include the desired domain name, for example, in the form of a Server Name Indicator (SNI) as described in IETF RFC3546.

[0024]

[0032] Some client-server communications may be encrypted. FIG. 2 illustrates a typical encrypted communication session 26 between a client device 12 and a content server 22 according to a protocol such as Transport Layer Security (TLS). The session 26 typically includes a handshake, in which the client 12 and the server 22 exchange various preliminary metadata, including cryptographic parameter values ​​used by the communicating parties to encrypt and / or decrypt payloads. Exemplary cryptographic parameters include cryptographic keys (e.g., public keys of an asymmetric key pair), nonce, random seed values, etc. Exemplary handshake messages include ClientHello and ServerHello messages, etc., according to a version of TLS. In some protocols, the handshake portion of the session further includes an authentication exchange in which the server 22 presents a certificate to the client device 12, allowing the client device 12 to verify the identity of the server 22.

[0025]

[0033] The handshake is typically followed by a communication payload that is encrypted according to cryptographic parameter values ​​(e.g., encryption keys, etc.) negotiated during the handshake. As used herein, payload refers to a portion of a communication that is readable only by the communicating parties (i.e., in the clear) and generally contains the contents of the messages, rather than metadata describing the respective message, session, or communication. Exemplary payloads include the content of documents, emails, web pages, video streams, instant messages, and the like.

[0026]

[0034] The payload portion of a session 26 may contain multiple encrypted messages sent by each party. In other words, there is a one-to-many correspondence between handshakes and multiple payloads. Thus, a session 26 is defined to consist of a handshake and the entire set of messages encrypted according to the respective handshake. Two encrypted messages belong to the same encrypted communication session if and only if they are both encrypted using the cryptographic value negotiated during the same handshake exchange.

[0027]

[0035] Some protocols attach session-specific metadata, such as a session identifier, to encrypted payload messages, allowing communicating parties to associate each message with a session-specific set of cryptographic parameter values. Tagging messages with a session identifier also enables asynchronous communication, for example, pausing a session and resuming it later without a new handshake.

[0028]

[0036] In some communications protocols, such as TLS version 1.3, parts of the handshake exchange are themselves encrypted, albeit using a key separate from the key used to encrypt the payload. To distinguish between the two sets of cryptographic keys / parameter values, the key used to encrypt parts of the handshake is considered herein as the handshake key, and the key used to encrypt the payload is considered herein as the application key.

[0029]

[0037] Such communication protocols may be used to hide the identity of the content server from third parties. In one example, known as Encrypted Client Hello (ECH) and illustrated in FIG. 3, the client device 12 initiates an encrypted communication session with the content server 22 by sending a client handshake message 32 to the front server 20. The client handshake 32 includes an encrypted portion 34 that specifies various parameters that the client wants to hide from third parties. For example, the portion 34 may include the domain name / SNI of the content server 22. The portion 34 is encrypted using a handshake encryption key 50 (e.g., the public key of an asymmetric key pair associated with the front server 20).

[0030]

[0038] As part of the ECH protocol, the client device 12 may obtain the key 50 from the DNS server 18. The server 18 may provide an IP-specific handshake key to each DNS record that associates a domain name with a respective IP address. In a situation where a single front server 20 controls access to multiple content servers 22a-c, as illustrated in FIG. 1, a single handshake key 50 may be associated not only with the front server 20 but also with all the servers 22a-c, since all the servers 22a-c may share the same IP address as the front server 20. In response to a DNS query 42 that requests the DNS server 18 to resolve the domain name of the content server 22, the DNS server 18 may selectively obtain the handshake key 50 according to the resolved IP address and may send the key 50 to the client device 12 in addition to the respective IP address. The key 50 may be included in the DNS response 44, for example, in a TXT portion.

[0031]

[0039] In response to receiving the client handshake 32, the front server 20 may decrypt the portion 34 using a handshake decryption key 52 (e.g., a private key associated with the front server 20). The front server 20 may thus recover the SNI of the server 22 and redirect the client handshake to the appropriate destination. However, since the key 52 is only available to the front server 20, in principle, no one else can see the respective SNI in the clear. Thus, conventional computer security methods that rely on intercepting the client handshake 32 and inspecting the SNI no longer work in situations such as those illustrated in FIG. 3.

[0032]

[0040] FIG. 4 illustrates exemplary data exchanges performed between the client device 12, the DNS server 18, and the front server 20 in some embodiments of the present invention. The traffic filter 60 cooperates with the DNS server 18 to protect the client device 12 from computer security threats such as malicious software and online fraud. The traffic filter 60 may be embodied as a set of software modules executing on the network product 14, the client device 12, the front server 20, and / or any other network device capable of intercepting traffic between the client device 12 and the content server 22. The functionality of the traffic filter 60 may be split among multiple hardware hosts, such as, for example, between the network product 14 and a remote server computer. An engineer will recognize that some or all of the functionality of the traffic filter 60 described herein may be implemented in hardware (e.g., a dedicated integrated circuit such as a field programmable gate array-FPGA), or a combination of hardware and software.

[0033]

[0041] In some embodiments, in addition to the handshake encryption keys 50 specific to the various front servers / IP addresses (as in the conventional ECH operation described above in connection with FIG. 3), the DNS server 18 further stores a proxy encryption key 56, e.g., the public side of a public-private key pair associated with the traffic filter 60. In response to a DNS query 42 requesting resolution of a domain name hosting content server 22, the DNS server 18 returns a DNS response 144 including the network address of the front server 20. However, in contrast to the conventional ECH described above in connection with FIG. 3, in some embodiments of the present invention, the DNS response 144 includes the proxy key 56 instead of the server-specific key 50. After receiving the DNS response 144, the client device 12 may initiate an encrypted communication session with the server 22 by sending a client handshake message 132 to the front server 20, where the domain name / SNI of the respective domain is hidden within the encrypted portion 134. Unlike the conventional ECH, the portion 134 is encrypted using the proxy key 56 instead of the real key 50 associated with the front server 20.

[0034]

[0042] In some embodiments, the traffic filter 60 uses the proxy decryption key 58 (e.g., a private key paired with the proxy encryption key 56) to decrypt the portion 134, thereby recovering the respective SNI. The traffic filter 60 then consults the access policy database 24 and / or the content index 25 to determine whether to allow access to the respective resource. If the access is deemed unsafe or does not comply with the client's access policy, the filter 60 may prevent the client device 12 from accessing the respective resource, for example, by terminating the respective connection. If access is allowed, some embodiments of the traffic filter 60 may request from the DNS server 18 the authentic handshake encryption key associated with the front server 20 and use the key 50 to reformulate the client handshake 132 by replacing the original encrypted portion 134 with the alternative encrypted portion 234 in which the respective SNI is encrypted according to the authentic handshake encryption key 50. In a preferred embodiment, the traffic filter 60 may generate a modified handshake 232 that is indistinguishable from the handshake sent by the client device 12 during a conventional ECH exchange (e.g., handshake 32 in FIG. 3). The traffic filter 60 may then forward the modified handshake 232 to the front server 20, which may use the handshake decryption key 52 to reveal the SNI and forward the respective handshake to the appropriate content server.

[0035]

[0043] In some embodiments, the proxy key pairs 56-58 are non-specific in the sense that a single proxy encryption key 56 may replace multiple genuine handshake encryption keys 50. However, the proxy key pairs 56-58 may be specific to a set of clients (e.g., a business or home with multiple protected devices 12a-e), a network device 14, a domain name and / or IP address, etc. In such embodiments, the server 18 may store multiple proxy encryption keys 56 and selectively return one according to, for example, the identity of the requesting client. In cases where DNS requests from multiple clients are routed through a single network product 14 (see, for example, FIG. 1), the server 18 may select which key 56 to include in the DNS response 144 according to the identity of the product 14. In such embodiments, all clients 12a-e accessing the extended network 15 through the product 14 may be protected according to the same contract / service level agreement associated with the product 14. A particular proxy key pair 56-58 may then be associated with each contract.

[0036]

[0044] In some embodiments, there may be multiple proxy key pairs 56-58, each associated with a distinct category of Internet content. In an exemplary security-focused embodiment, there may be separate key pairs associated with domains / resources / services that are considered secure and unsecure, respectively. In another example, DNS server 18 may store or generate separate keys 56 for each of multiple categories or services, such as video streaming, news, e-commerce, social media, gambling, pornography, etc. In such an embodiment, in response to receiving DNS query 42, server 18 may consult content index 25 and selectively provide a version of proxy key 56 appropriate for each content category.

[0037]

[0045] FIG. 5 illustrates exemplary content of a client handshake message 132 according to some embodiments of the present invention. The actual content and order of the various data fields may vary for each communication protocol / version. In some embodiments, the client handshake 132 includes at least a set of client cipher values ​​36, i.e., fields that store values ​​of various cryptographic parameters used to set up an encrypted communication session between the respective client device and the content server. The exemplary client cipher values ​​36 include the respective client device's public application key, i.e., a key that the content server 22 uses to encrypt payloads sent to the client device 12. Other exemplary client cipher values ​​36 include random numbers, salts, nonces, initialization vectors, etc., that are used by the content server 22 to derive a set of application keys used in encrypting payloads sent to the client device 12 in the respective session. In one example according to a member of the TLS protocol family, the handshake 132 may include a ClientHello message, and the client cipher values ​​36 may include the contents of the ClientRandom field of the respective ClientHello. (In accordance with the TLS protocol, server 22 uses the contents of the ClientRandom field to determine an application key for each session.) At least one of the client cryptographic values ​​36 is unique to client device 12, e.g., determined by client device 12 for purposes of establishing the respective encrypted communications session, and / or identifies the client side of the respective communications session.

[0038]

[0046] In some embodiments, the client handshake 132 further includes a session identifier 38, e.g., a number or token that allows the handshake 132 to be uniquely associated with a particular encrypted communication session. In some embodiments, an instance of the identifier 38 is included in all communications that form part of the respective session, allowing the communication parties to exchange multiple messages using the same cryptographic parameters / keys without having to renegotiate them. For example, the client device 12 and / or the content server 22 may maintain a mapping between each value of the session identifier 38 and a session-specific encryption / decryption key, thus allowing multiple concurrent sessions to be performed by selectively obtaining the correct key for each separate communication. In an exemplary embodiment according to a member of the TLS protocol family, the identifier 38 may include the contents of the SessionID field of the ClientHello handshake message. However, the session identifier 38 is not limited to, and need not be, in the same format as the TLS SessionID field. Instead, some embodiments may use the contents of the SessionID field in combination with other data when calculating the session identifier 38.

[0039]

[0047] The handshake message 132 may further include an encrypted portion 134 that may be used to transmit various handshake parameters in encrypted form. The portion 134 may include, for example, a Server Name Indicator (SNI) of the content server 22, etc. In some embodiments, the portion 134 is encrypted using the proxy handshake key 56 received from the DNS server 18.

[0040]

[0048] 6-A-6-B illustrate an exemplary sequence of steps performed by traffic filter 60 in accordance with some embodiments of the present invention. In one exemplary embodiment, filter 60 executes on network product 14, i.e., a gateway device that controls traffic between local network 13 and extended network 15. In the sequence of steps illustrated in FIG. 6-A, filter 60 may intercept incoming communications / messages (step 304) and identify client handshakes sent by protected client devices attempting to establish encrypted communications sessions (steps 308-310). In an exemplary embodiment using TLS, step 310 may include reading the value of a particular flag in the header of each message to determine whether the respective message includes a ClientHello. In an embodiment in which the entire client handshake message (rather than just portion 134) is encrypted, filter 60 may not be able to determine whether the respective message includes a client handshake without first decrypting the message. In such an embodiment, step 310 may include attempting to decrypt each message using the proxy decryption key 58 and, depending on whether the decryption attempt is successful, determining whether each message includes a client handshake.

[0041]

[0049] Some embodiments may be further configured to relay non-client handshake messages, unchanged, to their intended destination (step 312). Such relayed messages may include server handshake messages and encrypted payload messages (see, e.g., FIG. 2). In other words, in some embodiments, the traffic filter 60 does not interfere with a communication session already established between a client device and a content server.

[0042]

[0050] In preparation for a traffic filtering operation, the filter 60 may obtain a proxy decryption key 58 in step 302. In one exemplary embodiment, the proxy key pair 56-58 may be generated by the DNS server 18. Step 302 may then include obtaining the decryption key 58 from the DNS server 18. However, such a procedure may be risky since it involves transmitting a private key over a channel that may not be secure. Therefore, in preparation for transmitting the key 58, the filter 60 and the server 18 may participate in a mutual authentication procedure. Furthermore, the key 58 may be transferred in encrypted form after another handshake between the filter 60 and the server 18.

[0043]

[0051] In another alternative exemplary embodiment, the proxy key pair 56-58 may be generated by the traffic filter 60. Thus, the decryption key 58 may reside on a computer-readable medium of the computer system hosting the traffic filter 60, and a copy of the encryption key 56 may be transmitted to the DNS server 18 and / or a key server, which may forward a copy of the encryption key 56 to the DNS server 18 upon request. Since the key 56 typically includes a public key equivalent, such a transaction is not considered risky. However, due to the peculiarities of typical cryptographic algorithms, the key pair 56-58 may be unique to the instance of the traffic filter 60 that actually generated the key pair 56-58. Thus, each instance of the traffic filter 60 may transmit its own version of the proxy encryption key 56 to the DNS server 18. Furthermore, to enable the traffic filtering functionality described herein, the DNS server 18 may need to properly associate each received DNS query 42 with the corresponding proxy key 56 that is paired with the particular instance of the filter 60 used by the respective client device. In one such exemplary embodiment, in which clients 12a-e access extended network 15 via a network product 14 that also hosts a traffic filter 60, DNS server 18 may associate all DNS queries 42 received from each client with the respective instance of product 14 and respond with the version of proxy key 56 associated with the respective instance of product 14 / traffic filter 60.

[0044]

[0052] In another exemplary embodiment, each DNS query 42 may be tagged with an identifier of the respective client device and / or network product 14 / traffic filter 60. Such a tag may be included, for example, in the TXT record of the query 42. The server 18 may maintain a mapping between the client 12 and an instance of the filter 60 and selectively obtain the correct proxy key 56 according to the respective tag. These exemplary methods for generating and distributing proxy keys are also compatible with embodiments that maintain multiple key pairs, each corresponding to a distinct category of content and / or service.

[0045]

[0053] FIG. 6-B illustrates an exemplary sequence of steps performed by the traffic filter 60 in response to intercepting a client handshake. Step 320 may use the proxy decryption key 58 to decrypt the encrypted portion 134 to reveal an identifier (e.g., SNI, domain name) of the content server 22 (step 322). In a further step 324, the filter 60 may include determining whether to allow the client device 12 to access the respective content server. In a computer security embodiment, step 324 may include searching the SNI / domain name of the server 22 in the content index 25 and determining whether the respective SNI / domain name is associated with a computer security threat, such as malicious software or online fraud. In a parental control and / or application control embodiment, step 324 may include searching the SNI / domain name in the access policy database 24 and determining whether the client device 12 is allowed to access the respective domain or content category. Step 324 may include formulating a query according to the respective SNI / domain name and further according to the identifier of the client device 12 and sending the respective query to a server computer which retrieves data from databases 24 and / or 25. The decision whether to allow access may further proceed according to other criteria such as the identity of the current user of the respective client device, the current time, the current geographic location of the respective client device, etc.

[0046]

[0054] Some embodiments may enforce separate access policies according to whether the client device 12 is currently connected to the local network 13 or not (e.g., whether a laptop is accessing the Internet from home or not). One such exemplary embodiment maintains a mapping between the client devices 12a-e and instances of the traffic filter 60 (or the network products 14 hosting the respective instances of the traffic filter 60). For example, all client devices in a home may be mapped to one network product 14 / contract. Such mapping may be maintained and queried via a cloud service / web interface. Step 324 may then include searching the respective mappings to determine whether the origin of the client handshake 132 is associated / registered with the respective instance of the traffic filter 60. No may indicate that the respective client device is not currently connected to the “home” network product with which it is registered, and instead is roaming to access the Internet via another instance of the traffic filter 60. In such a situation, some embodiments of the traffic filter 60 may enforce a more restrictive access policy than when the respective client device is “at home”. For example, a simple embodiment may block all access attempts from client devices that are not registered to use the respective instance of traffic filter 60.

[0047]

[0055] In one such exemplary roaming detection scenario, the DNS server 18 may manage multiple proxy keys 56, with each such key being associated with a particular instance of the network filter 60 and / or a particular network product 14 (see, e.g., FIG. 1). Meanwhile, each client device may be registered / associated with a client-specific instance of the filter 60 and / or network product 14 (i.e., its expected "home"). In some embodiments, the DNS server 18 may, upon receiving a DNS query, identify the originating client device and return a proxy key associated with the respective client's registered "home". If the respective client is roaming, attempting to access the Internet through another instance of the traffic filter 60 will fail to decrypt the client handshake 132 due to a key mismatch. Such a failure may be interpreted as an indication of roaming and may cause a roaming access policy to be applied (e.g., blocking access) for the respective instance of the traffic filter.

[0048]

[0056] In response to determining that the client device 12 is not authorized to access the content server 22 (step 326 returns NO), the traffic filter 60 may block access to the respective resource using any method known in the art. For example, the filter 60 may block the client handshake 132 from reaching the front server 20, abort the respective connection, etc.

[0049]

[0057] If step 326 determines that access is permitted, some embodiments may simply relay the client handshake 132 to the destination, unaltered. Because the handshake 132 was encrypted using the proxy key 56 instead of the real handshake key 50, the front server 20 may not be able to decrypt the handshake 132. However, such embodiments rely on recovery mechanisms built into protocols such as ECH, which allow the server 20 to participate in another handshake exchange for each client device 12.

[0050]

[0058] In another exemplary embodiment, in step 330, the traffic filter 60 may determine the identity of the front server 20 according to the intercepted client handshake (e.g., the destination IP address of the handshake message 132) and obtain the authentic handshake encryption key 50 associated with the front server 20. Step 330 may include, for example, performing a DNS transaction with the DNS server 18, where the filter 60 requests resolution of the domain name / SNI determined in step 322, and the server 18 returns the handshake key 50 as part of the DNS response. In an embodiment in which the traffic filter 60 maintains a cache of recently used keys, step 330 may include obtaining the key 50 from the local cache according to the SNI included in the handshake message 132 and / or according to the destination IP address of the handshake message 132.

[0051]

[0059] In a further sequence of steps 332-334, the traffic filter 60 may modify the client handshake 132 and send the modified handshake 232 to the destination of the original handshake 132 (e.g., the front server 20), respectively. In some embodiments, modifying the handshake message 132 includes replacing the encrypted portion 134 with an alternative encrypted portion 234 that includes the SNI / domain name of the content server 22 (obtained by decrypting portion 134), this time encrypted using the real handshake key 50. In other words, in some embodiments, portion 134 and portion 234 have identical plaintext content, but portion 134 is encrypted using the proxy key 56 and portion 234 is encrypted using the real key 50.

[0052]

[0060] In formulating the modified handshake 232, some embodiments explicitly keep the remaining parts of the handshake message 132, such as the header, the client encryption value 36, and the session identifier 38. Such embodiments are based on the observation that to ensure privacy while enforcing the access policy, the traffic filter 60 should interfere as little as possible with the communication between the client device 12 and the content server 22. In particular, in response to determining that access to the server 22 is permitted, the traffic filter 60 does not act as a traditional man-in-the-middle (MITM) by independently renegotiating separate communication sessions with the device 12 and / or the server 22. Instead, by forwarding a handshake that is nearly identical to the client-generated handshake 132 (except for the re-encryption portion 234) to the server, and further relaying the server handshake message to the respective client, some embodiments ensure that the encryption (e.g., application key) of the respective communication session is negotiated directly between the client device 12 and the content server 22. This security strategy protects privacy by denying filter 60 the ability to decrypt the payload of each session.

[0053]

[0061] In alternative embodiments configured to generate multiple key pairs 56-58, each key pair is specific to a distinct content and / or service category, and step 320 (FIG. 6-B) may include attempting to decrypt portion 134 using multiple decryption keys 58. The key that results in successful decryption may thus identify the content / service category that the respective client device is attempting to access. Traffic filter 60 may then use this information to determine whether or not to allow access. For example, in a simple computer security embodiment where one key pair is associated with malicious content and another key pair is associated with benign content, traffic filter 60 may first attempt to decrypt client handshake 132 with the malicious decryption key. Successful decryption may indicate that DNS server 18 has already identified potential threats associated with the respective Internet domain, and thus filter 60 may block access without having to perform further evaluation. Conversely, if decryption using the malicious key fails, some embodiments of traffic filter 60 may simply relay the respective handshake to its destination. Such an embodiment may facilitate traffic filtering by dividing the computational load created by step 326 between the DNS server 18 and the traffic filter 60 .

[0054]

[0062] Although the above description illustrates various methods and algorithms that may be embodied as computer programs executed by a general-purpose hardware processor, a skilled artisan will understand that each function may be implemented using dedicated hardware components, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). FIG. 7 illustrates an exemplary hardware configuration of a computer system 80 that is programmable to execute some of the methods and algorithms described herein. The illustrated configuration is general and may represent, for example, any of the client devices 12a-e, the network product 14, the DNS server 18, and the front server 20, etc. An artisan will recognize that the hardware configuration of some devices (e.g., mobile phones, smart watches, servers, routers) may differ slightly from that illustrated in FIG. 7.

[0055]

[0063] 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.

[0056]

[0064] The input devices 86 may include a computer keyboard, mouse, and microphone, etc., including respective hardware interfaces and / or adapters that allow a user to introduce data and / or instructions into the respective computer systems. The output devices 88 may include display devices, such as a monitor and speakers, and hardware interfaces / adapters, such as a graphics card, that allow the illustrated computing product to communicate data to a user. In some embodiments, the input devices 86 and the output devices 88 share a common piece of hardware, such as in the case of a touch screen device. The storage devices 92 include computer readable media that allow for non-volatile storage, reading, and writing of software instructions and / or data. Exemplary storage devices 92 include magnetic disks, 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, along with associated communication interfaces, enable the illustrated computer system to connect to computer networks, such as local network 13 (FIG. 1), and / or to other devices / computer systems. Controller hub 90 collectively represents a number of system buses, peripheral buses, 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 memory controllers, input / output (I / O) controllers, interrupt controllers, etc. In another example, 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.

[0057]

[0065] The exemplary systems and methods described above can selectively control how miscellaneous client devices (personal computers, smartphones, IoT devices such as televisions, thermostats, door locks, refrigerators, wearables, etc.) access the Internet. Such control is important 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, instant messaging applications, etc.). Selectivity, as used herein, refers to the ability to adapt device-specific and / or user-specific access policies.

[0058]

[0066] Most modern Internet communications are encrypted, for example using versions of the Transport Layer Security (TLS) family of protocols. In such cases, an encrypted communication session involves an initial handshake exchange in which the parties negotiate a set of encryption keys, followed by the transmission of the actual communication payload (e.g., HTTP requests, DNS queries, etc.) encrypted using the session-specific negotiated keys. Some traditional access control methods rely on information extracted from the handshake exchange, such as the domain name and / or IP address of the end server. However, such methods have recently been pushed back by the advent of encrypted communication protocols such as Encrypted Client Hello (ECH), in which parts of the handshake are themselves encrypted using a handshake key that is separate from the application key negotiated during the handshake. Encrypted handshakes are used to improve privacy, for example by hiding the identity of the end server from third parties. Some embodiments of the present invention specifically address this problem.

[0059]

[0067] In some embodiments, a traffic filter located, for example, on a network gateway device, cooperates with a DNS server to access the encrypted portion of the client handshake. The DNS server may cooperate with the client device in a domain name resolution procedure during which the DNS server may provide the client device with a surrogate key disguised as a genuine handshake key associated with the end server (or a front server that controls access to the end server, as in some common cloud computing configurations). In some embodiments, the traffic filter may use a decryption key paired with the surrogate key to intercept and decrypt the client handshake, revealing the identity of the end server to which the client device is currently attempting to connect. The traffic filter may then determine, using any known method, whether to allow access to the respective end server. If access is not allowed, the traffic filter may block the respective client handshake from reaching its destination. If access is allowed, the traffic filter may obtain the genuine handshake key from the DNS server and modify the intercepted handshake by re-encrypting the end server's identifier with the genuine handshake key. The modified client handshake is then forwarded to the intended destination, allowing the respective client device to establish a session and exchange encrypted communications with the respective end server.

[0060]

[0068] One traditional strategy for tampering with encrypted communications is known as a man-in-the-middle (MITM) attack, in which a malicious entity prevents the establishment of a direct encrypted communication session between the client and the server, and instead negotiates two separate sessions, one with the client and one with the server. In each of these sessions, the attacker masquerades as the other legitimate communication party. By negotiating encryption keys with both the client and the server, the attacker can violate privacy by gaining access to the communication payload itself. However, some modern communication protocols include MITM countermeasures by introducing an additional handshake step that requires authentication of the communication parties, for example through a system of certificates.

[0061]

[0069] Some embodiments of the present invention avoid operation in a MITM configuration by explicitly ensuring that any communication session is established directly between the respective client device and the end server. In some embodiments, the modified handshake message sent to the end server is nearly identical to the original intercepted handshake message, except that the ciphertext portion uses a different handshake encryption key. In particular, the modified handshake preserves session-specific client-determined parameter values, such as client random and / or session ID, of the original intercepted handshake. Some embodiments further relay, unmodified, the server handshake message sent by the end server in response to the modified handshake message to the respective client device. Such operation allows the respective client device and server to establish a single directly encrypted communication session and seamlessly authenticate each other. Furthermore, by not participating in the actual negotiation of application keys with either of the communication partners, traffic filters are prevented from decrypting the communication payload. Thus, access control is enforced without compromising the confidentiality of the communication.

[0062]

[0070] It is obvious to those skilled in the art that the above embodiments can be modified in various 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. Using at least one hardware processor of a computer system, Intercepting a client handshake message for establishing an encrypted communication session between a client device and a remote content server, the client handshake message including an encrypted portion that stores an identifier of the remote content server; decrypting the encrypted portion to obtain the identifier of the remote content server; determining whether an access policy associated with the client device allows the client device to access the remote content server according to the identifier of the remote content server; Accordingly, if the access policy permits the client device to access the remote content server, determining a handshake encryption key according to the identifier of the remote content server; modifying the client handshake message by replacing the encrypted portion with an alternative encrypted portion that stores the identifier of the remote content server, the alternative encrypted portion being encrypted using the handshake encryption key; sending the modified handshake message to a destination of the client handshake message; responsive to intercepting other messages transmitted by the remote content server within the encrypted communication session, relaying the other messages to the client device; The method includes the step of:

2. 2. The method of claim 1, wherein the other message includes cryptographic parameter values ​​used by the client device to derive an application key for encrypting a payload transmitted within the encrypted communication session.

3. 2. The method of claim 1, wherein the client handshake message includes cryptographic parameter values ​​used by the remote content server to derive an application key for encrypting a payload transmitted as part of the encrypted communication session, and the modified handshake message includes the cryptographic parameter values.

4. 2. The method of claim 1, wherein the client handshake message includes a session identifier that distinguishes the encrypted communication session from other sessions, and the modified handshake message includes the session identifier.

5. 2. The method of claim 1 , responsive to receiving a request to resolve a domain name of the remote content server using a DNS server, sending a proxy encryption key to the client device, the proxy encryption key being distinct from the handshake encryption key; the encrypted portion is encrypted by the client device using the proxy encryption key; method.

6. 6. The method of claim 5, further comprising using the at least one hardware processor: obtaining a proxy decryption key from the DNS server; decrypting the encrypted portion using the proxy decryption key; The method further comprising the step of:

7. 6. The method of claim 5, further comprising using the at least one hardware processor: generating an encryption key pair including the proxy encryption key and the proxy decryption key; transmitting the proxy encryption key to the DNS server for further transmission to the client device; decrypting the encrypted portion according to the proxy decryption key; The method further comprising the step of:

8. 6. The method of claim 5, further comprising using the DNS server to prepare for transmitting the proxy encryption key to the client device, the method comprising: selecting a content category from a plurality of content categories according to the domain name, the content category indicating a type of content delivered by the remote content server; responsively selecting the proxy encryption key from a plurality of proxy encryption keys according to the selected content category; The method further comprising the step of:

9. 9. The method of claim 8, selecting, using the DNS server, the proxy encryption key from the plurality of proxy encryption keys according to whether the remote content server distributes malicious content; and in response to decrypting the encrypted portion, interpreting the decryption as an indication that the remote content server is distributing malicious content, with the at least one hardware processor. The method includes:

10. 2. The method of claim 1, wherein determining the handshake encryption key comprises: sending a DNS query to a DNS server, the query being formulated according to the identifier of the remote content server; receiving the handshake encryption key from the DNS server in response; A method comprising:

11. 1. A computer system having at least one hardware processor programmed to implement a traffic filter, the traffic filter comprising: Intercepting a client handshake message for establishing an encrypted communication session between a client device and a remote content server, the client handshake message including an encrypted portion that stores an identifier of the remote content server; decrypting the encrypted portion to obtain the identifier of the remote content server; determining whether an access policy associated with the client device allows the client device to access the remote content server according to the identifier of the remote content server; Accordingly, if the access policy permits the client device to access the remote content server, determining a handshake encryption key according to the identifier of the remote content server; modifying the client handshake message by replacing the encrypted portion with an alternative encrypted portion that stores the identifier of the remote content server, the alternative encrypted portion being encrypted using the handshake encryption key; sending the modified handshake message to a destination of the client handshake message; responsive to intercepting other messages transmitted by the remote content server within the encrypted communication session, relaying the other messages to the client device; A computer system configured to:

12. 12. The computer system of claim 11, wherein the other message includes cryptographic parameter values ​​used by the client device to derive an application key for encrypting a payload transmitted within the encrypted communication session.

13. 12. The computer system of claim 11, wherein the client handshake message includes cryptographic parameter values ​​used by the remote content server to derive an application key for encrypting a payload transmitted as part of the encrypted communication session, and the modified handshake message includes the cryptographic parameter values.

14. 12. The computer system of claim 11, wherein the client handshake message includes a session identifier that distinguishes the encrypted communications session from other sessions, and the modified handshake message includes the session identifier.

15. 12. The computer system of claim 11, further comprising a DNS server configured to send a proxy encryption key to the client device in response to receiving a request to resolve the domain name of the remote content server, the proxy encryption key being separate from the handshake encryption key, the encrypted portion being encrypted by the client device using the proxy encryption key.

16. 16. The computer system of claim 15, wherein the at least one hardware processor comprises: obtaining a proxy decryption key from the DNS server; decrypting the encrypted portion using the proxy decryption key; The computer system further configured to:

17. 16. The computer system of claim 15, wherein the at least one hardware processor comprises: generating an encryption key pair including the proxy encryption key and the proxy decryption key; transmitting the proxy encryption key to the DNS server for further transmission to the client device; decrypting the encrypted portion according to the proxy decryption key; The computer system further configured to:

18. 16. The computer system of claim 15, wherein the DNS server, in preparation for transmitting the proxy encryption key to the client device, selecting a content category from a plurality of content categories according to the domain name, the content category indicating a type of content delivered by the remote content server; responsively selecting the proxy encryption key from a plurality of proxy encryption keys according to the selected content category; The computer system further configured to:

19. 20. The computer system of claim 18, The DNS server is configured to select the proxy encryption key from the plurality of proxy encryption keys according to whether the remote content server distributes malicious content; the at least one hardware processor is further configured, in response to decrypting the encrypted portion, to interpret the decryption as an indication that the remote content server distributes malicious content. Computer system.

20. 12. The computer system of claim 11, wherein determining the handshake encryption key comprises: sending a DNS query to a DNS server, the query being formulated according to the identifier of the remote content server; In response, receiving the handshake key from the DNS server.

2. A computer system comprising:

21. 1. 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 execute a network filter, the network filter comprising: Intercepting a client handshake message for establishing an encrypted communication session between a client device and a remote content server, the client handshake message including an encrypted portion that stores an identifier of the remote content server; decrypting the encrypted portion to obtain the identifier of the remote content server; determining whether an access policy associated with the client device allows the client device to access the remote content server according to the identifier of the remote content server; Accordingly, if the access policy permits the client device to access the remote content server, determining a handshake encryption key according to the identifier of the remote content server; modifying the client handshake message by replacing the encrypted portion with an alternative encrypted portion that stores the identifier of the remote content server, the alternative encrypted portion being encrypted using the handshake encryption key; sending the modified handshake message to a destination of the client handshake message; responsive to intercepting other messages transmitted by the remote content server within the encrypted communication session, relaying the other messages to the client device; 16. A non-transitory computer-readable medium configured to:

Images