Privacy preserving screening of encrypted traffic

Abstract

The described systems and methods protect client devices, such as personal computers and IoT 5 devices, from harmful or inappropriate Internet content. Some embodiments employ a modified DNS server to provide a proxy key instead of a real handshake key to a client when the client uses an encrypted handshake to hide the identity of a terminal server, such as in applications implementing an encrypted client greeting (ECH). A traffic filter, e.g. Executing on a network gateway, may then intercept and decrypt the handshake and apply access policies 10 to selectively allow or deny access to the respective terminal servers. When access is allowed, the traffic filter may re-encrypt a server identifier using the real handshake key prior to forwarding the handshake to its destination. As the described method decrypts only the handshake rather than the actual payload, communication privacy is maintained.

Description

Background Art

[0001] The present invention relates to computer security and, in particular, to protecting users from malicious Internet content.

[0002] Malicious software, also known as malware, affects a large number of computer systems around the world. In its many forms, such as computer viruses, Trojan horses, spyware, and ransomware, malware poses a serious risk to millions of computer users, exposing them to loss of data and sensitive information, identity theft, and loss of productivity, among other things. An important way malware spreads is when users inadvertently access malicious or fraudulent online content.

[0003] At the same time, an increasing number of devices, informally referred to as the Internet of Things (IoT), are connected to communication networks and the Internet. Such devices include, among others, smartphones, smart watches, TVs and other multimedia devices, game consoles, home appliances, and various home sensors, such as thermostats. As more of these devices come online, they will face security threats such as malware and intrusions. Therefore, there is a growing need to protect such devices from malware, as well as to protect communications to and from such devices. Specific areas of renewed interest with the advent of the Internet of Things include access control applications, such as parental controls and preventing confidential information from being transmitted via IoT devices.

[0004] Conventional methods of protecting users and devices include employing security appliances such as network gateways to intercept access requests (e.g., HTTP) and / or domain name service (DNS) requests sent by protected devices while attempting to access remote Internet resources. The domain name or IP address specified in the intercepted request can then be compared to a blacklist of known malicious domains or addresses. The security appliance can thus block access to unsafe domains or addresses.

[0005] Recent concerns about user privacy have led to the development of encrypted domain name services, such as DNS over Hypertext Transfer Protocol Secure (DoH), described in Request for Comments (RFC) 8484 of the Internet Engineering Task Force (IETF). In addition, some communication protocols, such as Transport Layer Security (TLS), now allow for encryption of at least a portion of the handshake exchange, such as to keep the destination server private. Unfortunately, such new developments in Internet communications can also hinder computer security activities by preventing intermediary devices (e.g., routers) from performing conventional traffic screening.

[0006] Therefore, there is considerable interest in developing computer security systems and methods that implement traffic screening in the context of encrypted DNS and communication protocols that use encrypted handshakes. Summary of the invention

[0007] According to one aspect, a method includes using at least one hardware processor of a computer system to intercept a client handshake message for establishing an encrypted communication session between a client device and a remote content server. The client handshake message includes an encrypted section storing an identifier of the remote content server. The method further includes decrypting the encrypted section to retrieve 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 based on the identifier of the remote content server. In response, when the access policy allows the client device to access the remote content server, the method further includes determining a handshake encryption key based on the identifier of the remote content server, and modifying the client handshake message by replacing the encrypted section with a replacement encrypted section storing the identifier of the remote content server. The replacement encrypted section is encrypted using the handshake encryption key. The method further includes transmitting the modified handshake message to a destination of the client handshake message, and in response to intercepting another message sent by the remote content server within the encrypted communication session, relaying the other message to the client device.

[0008] According to another aspect, a computer system includes at least one hardware processor, the at least one hardware processor being programmed to execute a business filter, the business filter being configured to intercept a client handshake message for establishing an encrypted communication session between a client device and a remote content server. The client handshake message includes an encrypted section storing an identifier of the remote content server. The business filter is further configured to decrypt the encrypted section to retrieve the identifier of the remote content server, and determine whether an access policy associated with the client device allows the client device to access the remote content server based on the identifier of the remote content server. In response, when the access policy allows the client device to access the remote content server, the business filter is further configured to determine a handshake encryption key based on the identifier of the remote content server, and modify the client handshake message by replacing the encrypted section with a replacement encrypted section storing the identifier of the remote content server. The replacement encrypted section is encrypted using the handshake encryption key. The traffic filter is further configured to transmit the modified handshake message to a destination for the client handshake message and, in response to intercepting another message sent by the remote content server within the encrypted communication session, relay the other message to the client device.

[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 for establishing an encrypted communication session between a client device and a remote content server. The client handshake message includes an encrypted section storing an identifier of the remote content server. A service filter is further configured to decrypt the encrypted section to retrieve the identifier of the remote content server, and determine whether an access policy associated with the client device allows the client device to access the remote content server based on the identifier of the remote content server. In response, when the access policy allows the client device to access the remote content server, the service filter is further configured to determine a handshake encryption key based on the identifier of the remote content server, and modify the client handshake message by replacing the encrypted section with a replacement encrypted section storing the identifier of the remote content server. The replacement encrypted section is encrypted using the handshake encryption key. The traffic filter is further configured to transmit the modified handshake message to a destination for the client handshake message and, in response to intercepting another message sent by the remote content server within the encrypted communication session, relay the other message to the client device. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The foregoing aspects and advantages of the present invention will be better understood after reading the following detailed description and after referring to the accompanying drawings, in which:

[0011] Figure 1 Shown is a set of exemplary client devices protected from computer security threats according to some embodiments of the invention.

[0012] FIG. 2 shows a typical data exchange performed according to a protocol known in the art for encrypted communications.

[0013] 3 illustrates an exemplary data exchange according to a version of the communications protocol that uses an encrypted handshake.

[0014] Figure 4 An exemplary data exchange between a client device, a DNS server, and a front-end server according to some embodiments of the present invention is shown.

[0015] Figure 5 Illustrated are exemplary client handshake messages according to some embodiments of the invention.

[0016] Figure 6-AAn exemplary sequence of steps performed by a traffic filter according to some embodiments of the present invention is presented.

[0017] Figure 6-B Another exemplary sequence of steps performed by a traffic filter according to some embodiments of the present invention is presented.

[0018] Figure 7 An exemplary hardware configuration of a computer system that can be programmed to execute methods and algorithms according to some embodiments of the present invention is illustrated. DETAILED DESCRIPTION

[0019] In the following description, it should be 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 statement of an element should be understood to refer to at least one element. A plurality of elements includes at least two elements. Unless otherwise required, any described method steps do not necessarily need to be performed in a specific described order. A first element (e.g., data) derived from a second element includes a first element equal to the second element and a first element and optionally other data generated by processing the second element. Making a determination or decision based on a parameter includes making a determination or decision based on the parameter and optionally based on other data. Unless otherwise specified, an indicator of some quantity / data may be the quantity / data itself, or an indicator different from the quantity / data itself. A computer program is a sequence of processor instructions that performs a task. The computer program described in some embodiments of the present invention may be a stand-alone software entity or sub-entity (e.g., a subroutine, a library) of other computer programs. A network domain consists of a group of interconnected computing devices, and the group of interconnected computing devices forms 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 herein means determining the network address of a domain with a corresponding domain name. Metadata herein refers to characteristics of a transmission, not the payload itself. Exemplary metadata includes (among other things) the network address of the sender and / or the receiver, the size of the payload, and a timestamp indicating the actual time of the corresponding transmission. When the network addresses of two devices belong to the same subnet and / or when the two devices have the same broadcast address, the two devices are said to be connected to or belong to the same local network. A wide area network includes at least one router. The term 'database' is used herein to represent any organized collection of data. Session identifiers as described herein may include, but are not limited to, the contents of the SessionID field of a TLS ClientHello record. Relaying a message herein means delivering a corresponding message without changing its contents. Computer-readable media include non-transitory media such as magnetic, optical, and semiconductor storage media (e.g., hard drives, optical disks, flash memories, DRAM), and communication links such as conductive cables and optical fiber links. According to some embodiments, the present invention provides, among other things, a computer system comprising hardware (eg, one or more processors) programmed to perform the methods described herein, and a computer-readable medium encoding instructions to perform the methods described herein.

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

[0021] Figure 1A system 10 for protecting a group of client devices 12a-12e from computer security threats is shown 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., laptops, tablet computers, mobile phones), entertainment devices (e.g., TVs, game consoles), wearable devices (e.g., smart watches, fitness bands), household appliances (e.g., refrigerators, washing machines), and any other electronic devices, including processors, memory, and communication interfaces that enable the respective devices to communicate with other devices / computer systems. Any of the exemplary client devices 12a-12e can request access to remote content servers 22a-22c via a communication link to exchange data such as web page content, electronic messages, various files, etc. In some embodiments, access to servers 22a-22c is managed by a business filter, as described in detail below.

[0022] exist Figure 1 In an exemplary configuration of , 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. The 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 the client devices 12a-12e and the extended network 15 traverses a network appliance 14, such as a router, a WiFi hotspot, a network hub, etc. In the illustrated configuration, the appliance 14 acts as a gateway device between the local network 13 and the extended network 15. In some embodiments, the network appliance 14 includes a traffic filter that is configured to selectively enable access to locations on the extended network 15, as described in further detail below. The appliance 14 may further perform various other computer security activities, such as a firewall, scanning communications for malware, etc.

[0023] In some embodiments, the system 10 further includes a client policy database 24 and a content index 25 that may be stored on a remote server system that is 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, and key-value stores, among others.

[0024] The policy database 24 may store multiple client records associated with the client devices 12a-12e and / or users of the corresponding client devices. In one example, each client record corresponds to a different client device 12a-12e. The client record may store a set of identifiers of the corresponding client device (e.g., client identifiers, media access control-MAC addresses, international mobile equipment identities-IMEI numbers, local network addresses, etc. as described below), and indicators of Internet access policies specific to the corresponding client devices. The access policy encodes a set of rules or restrictions for accessing Internet content. For example, the access policy indicator may include indicators of content categories that the corresponding client device should not access (e.g., adult content, social networks, etc.). The access policy may further include a time indicator, such as a time interval of the applicability of the corresponding policy. The access policy may further include a location indicator indicating the applicability area of ​​the corresponding policy. In one such example, when the corresponding device is connected to the local network 13 (e.g., when at home), an access policy may be applicable, and when the corresponding device is roaming, another policy may be applicable. Another exemplary policy may only be applicable within the boundaries of a predetermined geographic fence. In some embodiments, an access policy may include an identifier of a user of a respective client device, the identifier indicating that the respective policy applies when the respective client device is operated by the respective user.

[0025] In some embodiments, the client record may include other data that may be relevant to the access policy. Examples include indicators of device types (e.g., digital cameras, thermostats, smart phones, tablet computers, routers, cars), various hardware configuration indicators of the corresponding client device (e.g., whether the corresponding device has a camera, etc.), and a list of software applications installed on the corresponding device. Other information stored in the exemplary client record includes device usage data, such as statistics of network accesses performed by the corresponding client device, such as the relative frequency of use of various communication ports, the relative traffic volume during various time intervals, etc. Other exemplary client records may include metadata describing network traffic transmitted or received by the corresponding client device. In some embodiments, this metadata may be organized according to formats such as IP Flow Information Export (IPFIX) from the Internet Engineering Task Force or NetFlow (R) from Cisco, Inc.

[0026] In some embodiments, policy database 24 may store records indicating collective access policies. One exemplary collective access policy applies to all devices with a particular device profile, which is defined, for example, by a tuple of device characteristics such as 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 with versions earlier than version 10. The collective access policy may be applied to all devices that operate the system, etc. Other collective access policies may apply to all devices that belong 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 appliance 14. In yet another example, one access policy may apply to devices operated by employees from the engineering department, and another access policy may apply to devices operated by employees from the company's legal department, etc.

[0027] Content index 25 generally represents any collection of data that enables a determination of whether access to a particular Internet resource / location / service constitutes a computer security hazard and / or a violation of an access policy (e.g., parental controls). In a simple example, index 25 includes a set of records indexed by domain name or IP address, each record indicating a category of content stored at or distributed from a respective domain. Exemplary categories include malicious content (e.g., malware, fraudulent web pages, phishing web pages, dark web, etc.), adult content, streaming media, social networking, e-commerce, banking, and gaming, among others.

[0028] In some embodiments, a domain name service (DNS) server 18 cooperates with a traffic filter (e.g., a software component executed on the appliance 14) as described below to protect client devices 12a-12e from computer security threats. The DNS server 18 provides domain name services to the client devices 12a-12e, including, among other things, translating domain names into network addresses and / or vice versa by maintaining mappings between domain names and network addresses. The server 18 generally represents a group of communicatively coupled computers that may or may not be physically close to each other. Those skilled in the art will appreciate that the operation of the DNS server 18 as described herein may be divided among multiple physical machines or processors (e.g., authoritative name servers, top-level domain name servers, root name servers, cryptographic key servers, etc.).

[0029] Typical communication between client devices 12a-12e and content servers 22a-22c includes several steps. Such communication requires knowing the network address (e.g., Internet Protocol-IP address) of the corresponding content server. For various reasons, the client usually does not know this address. For example, there may be multiple mirror content server machines, and the client can be dynamically guided to the most convenient one mirror content server machine 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 the domain name of the alias including the unknown network address. In order to establish a connection to the corresponding content server, the software entity executed on the corresponding client device can therefore issue a request to access the corresponding domain name, rather than the IP address itself. In response, another software entity (e.g., operating system) of the client device can attempt to translate the alias / domain name into an actual network address, and then transmit the request to the correct network location.

[0030] Translating a domain name into a network address (an operation referred to in the art as domain name resolution) typically includes the transmission of a DNS query by the respective client device to the DNS server 18. The DNS query may include, among other things, an encoding of the domain name and an indicator of the type of question Q. The type of question indicates the type of DNS resource record returned by the DNS server 18 in response to the respective query. Exemplary questions 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 question / resource record types include 'TXT', 'PTR', 'LOC', etc. In response to the query, the DNS server 18 may return a DNS reply to the requesting client, including an encoding of a network address (e.g., an IPv6 address) corresponding to the respective domain name / alias.

[0031] In such Figure 1 In some of the scenarios shown in , multiple content servers 22a-22c and / or Internet domains are commonly accessed via a common network address and physical machine (illustrated by front-end server 20). Such scenarios occur, for example, and , and other content delivery networks (CDNs), and also appear in many applications collectively referred to as 'cloud computing'. In such scenarios, all servers 22a-22c and / or corresponding Internet domains are obviously located at the network address of the front-end server 20. In other words, a DNS query for any domain associated with the content servers 22a-22c will return the IP address of the front-end server 20. In order to enable the front-end server 20 to selectively direct incoming access requests to the appropriate content servers 22a-22c, the corresponding access requests are typically configured to include the desired domain name, such as in the form of a server name indicator (SNI) as described in IETF's RFC3546, among others.

[0032] Some client-server communications may be encrypted. FIG. 2 illustrates a generic 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 ​​to be used by the communicating parties to encrypt and / or decrypt the payload. Exemplary cryptographic parameters include cryptographic keys (e.g., a public key of an asymmetric key pair), random numbers, random seed values, etc. Exemplary handshake messages according to versions of TLS include ClientHello and ServerHello messages, among others. In some protocols, the handshake portion of the session further includes an authentication exchange in which the server 22 presents credentials to the client device 12, the respective credentials enabling the client device 12 to verify the identity of the server 22.

[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. Payload herein refers to a portion of a communication that is intended to be readable only by the communicating parties (i.e., in plain text), and generally includes the content of the message, rather than metadata describing the corresponding message, session, or communication. Exemplary payloads include the content of a file, an email, a web page, a video stream, and an instant message, among others.

[0034] The payload portion of a session 26 may include multiple encrypted messages transmitted by each party. In other words, there is a one-to-many correspondence between a handshake and multiple payloads. Thus, a session 26 is defined as consisting of a handshake and all messages encrypted according to the corresponding handshake. Two encrypted messages belong to the same encrypted communication session only if both are encrypted using a cryptographic value negotiated during the same handshake exchange.

[0035] Some protocols append session-specific metadata (e.g., session identifiers) to encrypted payload messages, enabling the communicating parties to associate each message with a set of session-specific cryptographic parameter values. Tagging messages with session identifiers further enables asynchronous communication, such as pausing a session and later resuming it without a new handshake.

[0036] In some communication protocols, such as TLS version 1.3, some of the handshake exchange itself is encrypted, albeit using different keys than those used to encrypt the payload. To distinguish between the two sets of cryptographic keys / parameter values, the keys used to encrypt parts of the handshake will be referred to herein as handshake keys, while the keys used to encrypt the payload will be referred to herein as application keys.

[0037] Such communication protocols may be used to hide the identity of the content server from third parties. In one example, referred to 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 transmitting a client handshake message 32 to the front-end server 20. The client handshake 32 includes an encrypted section 34 that specifies various parameters that the client wants to hide from third parties. For example, the section 34 may include the domain name / SNI of the content server 22. The section 34 is encrypted using a handshake encryption key 50 (e.g., a public key of an asymmetric key pair associated with the front-end server 20).

[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 append the IP-specific handshake key to each DNS record, thereby associating the domain name with the corresponding IP address. Figure 1 , where a single front-end server 20 controls access to multiple content servers 22a-22c, a single handshake key 50 may be associated with the front-end server 20 and with all of the servers 22a-22c because the servers may all share the same IP address of the front-end server 20. In response to a DNS query 42 requesting the DNS server 18 to resolve the domain name of the content server 22, the DNS server 18 may selectively retrieve the handshake key 50 based on the resolved IP address and transmit the key 50 to the client device 12 in addition to the corresponding IP address. The key 50 may be included in the DNS reply 44, such as within a TXT section.

[0039] In response to receiving the client handshake 32, the front-end server 20 can use the handshake decryption key 52 (e.g., a private key associated with the front-end server 20) to decrypt the segment 34. The front-end server 20 can 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-end server 20, in principle no one else can see the corresponding SNI in plain text. Therefore, conventional computer security methods that rely on intercepting the client handshake 32 and checking the SNI are no longer effective in the case as illustrated in FIG. 3.

[0040] Figure 4 An exemplary data exchange performed between a client device 12, a DNS server 18, and a front-end server 20 in some embodiments of the present invention is shown. A traffic filter 60 cooperates with the DNS server 18 to protect the client device 12 from computer security threats, such as malware and online fraud, among others. The traffic filter 60 may be embodied as a set of software modules that can intercept traffic between the client device 12 and the content server 22, executed on the network appliance 14, the client device 12, the front-end server 20, and / or any other network device. The functionality of the traffic filter 60 may be divided between multiple hardware hosts (for example, between the network appliance 14 and a remote server computer). A skilled person will appreciate that, alternatively, some or all of the functionality of the traffic filter 60 described herein may be implemented in hardware (e.g., an application specific integrated circuit such as a field programmable gate array-FPGA) or a combination of hardware and software.

[0041] In some embodiments, in addition to the handshake encryption keys 50 specific to various front-end servers / IP addresses (as in conventional ECH activities described above with respect to FIG. 3 ), the DNS server 18 further stores a proxy encryption key 56, such as 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 the domain name of the host content server 22, the DNS server 18 returns a DNS reply 144 containing the network address of the front-end server 20. However, in contrast to conventional ECH described above with respect to FIG. 3 , in some embodiments of the present invention, the DNS reply 144 contains the proxy key 56 instead of the server-specific key 50. Upon receiving the DNS reply 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-end server 20, wherein the domain name / SNI of the corresponding domain is hidden within an encrypted section 134. In contrast to conventional ECH, the section 134 is encrypted using the proxy key 56 instead of the real key 50 associated with the front-end server 20.

[0042] In some embodiments, the service filter 60 decrypts the segment 134 using the proxy decryption key 58 (e.g., a private key paired with the proxy encryption key 56), thereby recovering the corresponding SNI. The service filter 60 may then consult the access policy database 24 and / or the content index 25 to determine whether to allow access to the corresponding resource. When 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 corresponding resource, for example by terminating the corresponding connection. When access is allowed, some embodiments of the service filter 60 may request the real handshake encryption key associated with the front-end server 20 from the DNS server 18 and use the key 50 to reformulate the client handshake 132 by replacing the original encrypted segment 134 with the replacement encrypted segment 234, wherein the corresponding SNI is encrypted according to the real handshake encryption key 50. In a preferred embodiment, the service filter 60 may generate a modified handshake 232 that is indistinguishable from the handshake that the client device 12 would have sent during a conventional ECH exchange (e.g., the handshake 32 in FIG. 3 ). Traffic filter 60 may then forward modified handshake 232 to front-end server 20, which may use its handshake decryption key 52 to reveal the SNI and forward the corresponding handshake to the appropriate content server.

[0043] In some embodiments, the proxy key pairs 56-58 are non-specific in that a single proxy encryption key 56 can replace multiple real handshake encryption keys 50. However, the proxy key pairs 56-58 can be specific to a group of clients (e.g., specific to a company or family with multiple protected devices 12a-12e), specific to a network appliance 14, specific to a domain name and / or IP address, etc. In such embodiments, the server 18 can store multiple proxy encryption keys 56 and selectively return one or another proxy encryption key based on, for example, the identity of the requesting client. When DNS requests from multiple clients are routed via a single network appliance 14 (e.g., see Figure 1 ), the server 18 may select which key 56 to include in the DNS reply 144 based on the identity of the appliance 14. In some such embodiments, all clients 12a-12e accessing the extended network 15 via the appliance 14 may be protected according to the same contract / service level agreement associated with the appliance 14. A particular proxy key pair 56-58 may then be associated with a corresponding contract.

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

[0045] Figure 5 Exemplary contents of a client handshake message 132 according to some embodiments of the present invention are shown. The actual contents and ordering of the various data fields may vary from one communication protocol / version to another. In some embodiments, the client handshake 132 includes at least a field storing a set of client cryptographic values ​​36 (i.e., values ​​of various cryptographic parameters used to establish an encrypted communication session between a respective client device and a content server). Exemplary client cryptographic values ​​36 include a public application key of the respective client device, i.e., a key used by the content server 22 to encrypt a payload transmitted to the client device 12. Other exemplary client cryptographic values ​​36 include random numbers, salts, random numbers, initialization vectors, etc., which are used by the content server 22 to derive a set of application keys used to encrypt payloads transmitted to the client device 12 under the respective session. In one example according to a member of the TLS protocol family, the handshake 132 may include a client hello message, and the client cryptographic values ​​36 may include the contents of the ClientRandom field of the respective client hello. (In accordance with the TLS protocol, server 22 uses the contents of the ClientRandom field to determine an application key for the corresponding session.) At least one of client cryptographic values ​​36 is specific to client device 12, such as determined by client device 12 for purposes of establishing a corresponding encrypted communication session, and / or identifying the client side of the corresponding communication session.

[0046] In some embodiments, the client handshake 132 further includes a session identifier 38, such as a number or token that allows the handshake 132 to be uniquely associated with a specific encrypted communication session. In some embodiments, an instance of the identifier 38 is included in all communications that form part of the corresponding session, thereby enabling the communicating parties to exchange multiple messages using the same cryptographic parameters / keys without having to renegotiate the cryptographic parameters / keys. 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, thereby enabling multiple concurrent sessions to be performed by selectively retrieving the correct key for each different 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 client hello handshake message. However, the session identifier 38 is not limited to and need not have the same format as the TLS SessionID field. Alternatively, when calculating the session identifier 38, some embodiments may use the contents of the SessionID field in conjunction with other data.

[0047] The handshake message 132 further includes an encrypted section 134, which can be used to transmit various handshake parameters in an encrypted form. Section 134 may include, for example, a server name indicator (SNI) of the content server 22, among others. In some embodiments, section 134 is encrypted using the proxy handshake key 56 received from the DNS server 18.

[0048] Figure 6-A -B shows an exemplary sequence of steps performed by the service filter 60 according to some embodiments of the present invention. In one exemplary embodiment, the filter 60 is executed on the network appliance 14 (i.e., a gateway device that controls the service between the local network 13 and the extended network 15). Figure 6-A , filter 60 may intercept incoming communications / messages (step 304) and identify a client handshake sent by a protected client device attempting to establish an encrypted communication session (steps 308-310). In an exemplary embodiment using TLS, step 310 may include reading the value of a particular flag included in the header of the respective message to determine whether the respective message includes a ClientHello. In embodiments where the entire client handshake message is encrypted (rather than just segment 134), filter 60 may not be able to determine whether the respective message includes a client handshake without first decrypting the respective message. In such embodiments, step 310 may include attempting to decrypt the respective message using proxy decryption key 58, and determining whether the respective message includes a client handshake based on whether the decryption attempt is successful.

[0049] Some embodiments may further be configured to relay messages that are not client handshakes unchanged to their intended destinations (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, traffic filter 60 does not interfere with an already established communication session between a client device and a content server.

[0050] In preparation for the traffic screening operation, in step 302, the screener 60 may obtain the proxy decryption key 58. In one exemplary embodiment, the proxy key pair 56-58 may be generated by the DNS server 18. Step 302 may then include retrieving the decryption key 58 from the DNS server 18. However, this procedure may be risky because it includes transmitting a private key over a potentially insecure channel. Therefore, in preparation for transmitting the key 58, the screener 60 and the server 18 may participate in a mutual authentication procedure. In addition, the key 58 may be transmitted in an encrypted form after a separate handshake between the screener 60 and the server 18.

[0051] In an 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, while a copy of the encryption key 56 may be transmitted to the DNS server 18 and / or a key server, which may forward the copy to the DNS server 18 upon request. This transaction is not considered risky because the key 56 typically includes the equivalent of a public key. However, due to the peculiarities of typical cryptographic algorithms, the key pair 56-58 may be specific to the instance of the traffic filter 60 that actually generated the key pair. Thus, each instance of the traffic filter 60 may send its own version of the proxy encryption key 56 to the DNS server 18. Furthermore, in order to implement the traffic filtering functionality described herein, the DNS server 18 may have to correctly associate each received DNS query 42 with a corresponding proxy key 56 that is paired with the specific instance of the filter 60 used by the corresponding client device. In one such exemplary embodiment in which clients 12a-12e access extended network 15 via network appliance 14 that also hosts service filter 60, DNS server 18 may associate all DNS queries 42 received from respective clients with respective instances of appliance 14 and reply with a version of proxy key 56 associated with respective instances of appliance 14 / service filter 60.

[0052] In another exemplary embodiment, each DNS query 42 may be tagged with an identifier of the corresponding client device and / or network appliance 14 / service filter 60. This tag may be included, for example, in a TXT record of the query 42. The server 18 may maintain a mapping between instances of the client 12 and the filter 60 and selectively retrieve the correct proxy key 56 based on the corresponding tag. These exemplary methods for generating and distributing proxy keys are also applicable to embodiments that maintain multiple key pairs, each key pair corresponding to a different category of content and / or service.

[0053] Figure 6-B The diagram 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 segment 134, thereby revealing the identifier (e.g., SNI, domain name) of the content server 22 (step 322). In another step 324, the filter 60 may determine whether the client device 12 is allowed to access the corresponding content server. In a computer security embodiment, step 324 may include looking up the SNI / domain name of the server 22 in the content index 25 to determine whether the corresponding SNI / domain name is associated with a computer security threat such as malware or online fraud. In a parental control and / or application control embodiment, step 324 may include looking up the SNI / domain name in the access policy database 24 to determine whether the client device 12 is allowed to access the corresponding domain or content category. Step 324 may include formulating a query based on the corresponding SNI / domain name and further based on the identifier of the client device 12, and transmitting the corresponding query to a server computer responsible for retrieving data from the database 24 and / or 25. The determination of whether to allow access may further proceed based on other criteria such as the identity of the current user of the corresponding client device, the current time, the current geographic location of the corresponding client device, etc.

[0054] Some embodiments may implement different access policies depending on whether the client device 12 is currently connected to the local network 13 (e.g., whether the laptop is accessing the Internet from home). One such exemplary embodiment maintains a mapping between the client devices 12a-12e and an instance of the service filter 60 (or a network appliance 14 that hosts a corresponding instance of the service filter 60). For example, all client devices within a home may be mapped to one network appliance 14 / contract. This mapping may be maintained and queried via a cloud service / web interface. Step 324 may then include looking up the corresponding mapping to determine whether the originator of the client handshake 132 is associated with / registered with the corresponding instance of the service filter 60. A mismatch may indicate that the corresponding client device is not currently connected to its registered 'home' network appliance, but is roaming and accessing the Internet via another instance of the service filter 60. In such cases, some embodiments of the service filter 60 may implement a more restrictive access policy than when the corresponding 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 corresponding instance of the service filter 60.

[0055] In one such exemplary roaming detection scenario, the DNS server 18 may manage multiple proxy keys 56, each such key being associated with a particular instance of a network filter 60 and / or with a particular network appliance 14 (see, e.g., Figure 1 ). At the same time, each client device may be registered / associated with a client-specific instance of filter 60 and / or network appliance 14 (i.e., its intended 'home'). In some embodiments, in response to receiving a DNS query, DNS server 18 may identify the originating client device and return a proxy key associated with the registered 'home' of the respective client. When the respective client is roaming, any attempt to access the Internet via another instance of service filter 60 will result in a failure of the decryption client handshake 132 due to a key mismatch. This failure may be interpreted as an indicator of roaming and may cause the respective instance of the service filter to apply a roaming access policy (e.g., block access).

[0056] In response to the determination that the client device 12 is not allowed to access the content server 22 (step 326 returns "no"), the service filter 60 can block access to the corresponding resource using any method known in the art. For example, the filter 60 can block the client handshake 132 from reaching the front-end server 20, interrupt the corresponding connection, etc.

[0057] When step 326 determines that access is allowed, some embodiments may simply relay the client handshake 132 to its destination without modification. Since the handshake 132 is encrypted using the proxy key 56 rather than the real handshake key 50, the front-end server 20 may not be able to decrypt the handshake. However, such embodiments rely on a recovery mechanism built into protocols such as ECH, through which the server 20 can engage the corresponding client device 12 in another handshake exchange.

[0058] In other exemplary embodiments, in step 330, the traffic filter 60 may determine the identity of the front-end server 20 based on the intercepted client handshake (e.g., based on the destination IP address of the handshake message 132) and retrieve the real handshake encryption key 50 associated with the front-end server 20. Step 330 may include, for example, performing a DNS transaction with the DNS server 18, wherein 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 reply. In embodiments where the traffic filter 60 maintains a cache of recently used keys, step 330 includes retrieving the key 50 from a local cache based on the SNI included in the handshake message 132 and / or based on the destination IP address of the handshake message 132.

[0059] In another sequence of steps 332-334, traffic filter 60 may modify client handshake 132 and transmit modified handshake 232 to the destination (e.g., front-end server 20) of original handshake 132, respectively. In some embodiments, modifying handshake message 132 includes replacing encrypted segment 134 with a replacement encrypted segment 234 including the SNI / domain name of content server 22 (obtained by decrypting segment 134), this time encrypted using real handshake key 50. In other words, in some embodiments, segments 134 and 234 have the same plaintext content, however segment 134 is encrypted using proxy key 56, while segment 234 is encrypted using real key 50.

[0060] In formulating the modified handshake 232, some embodiments explicitly keep the rest of the handshake message 132 intact, including the header, the client secret value 36, the session identifier 38, etc. Such embodiments rely on the observation that in order to ensure privacy while still enforcing access policies, the traffic filter 60 should interfere with the communication between the client device 12 and the content server 22 as little as possible. In particular, in response to determining that access to the server 22 is allowed, the traffic filter 60 does not act as a conventional man-in-the-middle (MITM) by independently renegotiating a separate communication session with the device 12 and / or the server 22. Instead, by forwarding to the server a handshake that is nearly identical to the handshake 132 generated by the client (except for the re-encrypted section 234), and by further relaying the server handshake message back to the respective client, some embodiments ensure that the password (e.g., application key) for the respective communication session is negotiated directly between the client device 12 and the content server 22. This security policy protects privacy by denying the filter 60 the ability to decrypt the payload of the respective session.

[0061] In an alternative embodiment configured to generate multiple key pairs 56-58, each key pair being specific to a different category of content and / or service, step 320 ( Figure 6-B ) may include attempting to decrypt the segment 134 using multiple decryption keys 58. The key that achieves successful decryption may therefore identify the category of content / service that the corresponding client device is attempting to access. The business filter 60 may then use this information to determine whether 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, the business filter 60 may first attempt to decrypt the client handshake 132 using the malicious-indicating decryption key. Successful decryption may indicate that the DNS server 18 has identified a potential threat associated with the corresponding Internet domain, and therefore the filter 60 may block access without having to perform further evaluation. Conversely, when decryption using the malicious-indicating key is unsuccessful, some embodiments of the business filter 60 may simply relay the corresponding handshake to its destination. Such embodiments may facilitate business screening by dividing the computational load generated by step 326 between the DNS server 18 and the business filter 60.

[0062] The above description shows various methods and algorithms that can be embodied as computer programs executed by a general-purpose hardware processor, but those skilled in the art will understand that dedicated hardware components such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs) can also be used to implement the corresponding functionality. Figure 7An exemplary hardware configuration of a computer system 80 that can be programmed to perform some of the methods and algorithms described herein is illustrated. The illustrated configuration is generic and may represent, for example, any of the client devices 12a-12e, the network appliance 14, the DNS server 18, and the front-end server 20, among others. A skilled person will appreciate that the hardware configuration of some devices (e.g., mobile phones, smart watches, servers, routers) may differ from one another. Figure 7 The hardware configuration described in is slightly different.

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

[0064] Input devices 86 may include, among others, a computer keyboard, a mouse, and a microphone, including corresponding hardware interfaces and / or adapters that allow a user to introduce data and / or instructions into a corresponding computer system. Output devices 88 may include display devices such as a monitor and speakers, among others, and hardware interfaces / adapters such as a graphics card, thereby allowing the illustrated computer to communicate data to a user. In some embodiments, input device 86 shares a common piece of hardware with output device 88, such as in the case of a touch screen device. Storage device 92 includes computer-readable media that implements non-volatile storage, reading, and writing of software instructions and / or data. Exemplary storage device 92 includes 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, enable the illustrated computer system to connect to, for example, a local network 13 ( Figure 1 ) and / or other devices / computer systems. Controller hub 90 generally represents multiple system, peripheral and / or chipset buses, and / or all 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, and an interrupt controller, among others. In another example, controller hub 90 may include a north bridge that connects processor 82 to memory 84, and / or a south bridge that connects processor 82 to devices 86, 88, 92, and 94.

[0065] The exemplary systems and methods described above allow for selective control of how a variety of different client devices (personal computers, smartphones, IoT devices such as TVs, thermostats, door locks, refrigerators, wearable devices, etc.) access the Internet. This control is critical for applications such as computer security (protecting users and devices from malicious content and / or Internet fraud), parental control (monitoring and / or limiting access to specific online content by specific devices / users), and application control (monitoring and / or limiting the use of selected software such as social media, streaming media, gaming, and instant messaging applications). Selectivity in this context refers to the ability to apply device-specific and / or user-specific access policies.

[0066] Most modern Internet communications are encrypted, for example, using a version of the Transport Layer Security (TLS) family of protocols. In such cases, an encrypted communication session includes 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 conventional 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 hampered by the advent of encrypted communication protocols, such as Encrypted Client Hello (ECH), in which a portion of the handshake itself is encrypted using a handshake key that is different from the application key negotiated during the handshake. For example, an encrypted handshake is used to increase privacy by hiding the identity of the end server from third parties. Some embodiments of the present invention specifically address this problem.

[0067] In some embodiments, a service filter located, for example, on a network gateway device collaborates with a DNS server to obtain access to the encrypted portion of the client handshake. The DNS server may interact with the client device in a domain name resolution procedure, during which the DNS server may provide the client device with a proxy key disguised as a real handshake key associated with a terminal server (or associated with a front-end server that controls access to the terminal server, such as in several popular cloud computing configurations). In some embodiments, the service filter may intercept the client handshake and decrypt the client handshake using a decryption key paired with the proxy key, and thus reveal the identity of the terminal server to which the client device is currently trying to connect. The service filter may then use any known method to determine whether access to the corresponding terminal server is allowed. When access is not allowed, the service filter may prevent the corresponding client handshake from reaching its destination. When access is allowed, the service filter may retrieve the real handshake key from the DNS server and modify the intercepted handshake by re-encrypting the identifier of the terminal server using the real handshake key. Then, the modified client handshake is forwarded to its intended destination, thereby enabling the corresponding client device to establish a session with the corresponding terminal server and exchange encrypted communications.

[0068] One conventional strategy for tampering with encrypted communications is known as a man-in-the-middle (MITM) attack, in which a malicious entity prevents a direct encrypted communication session from being established between a client and a server, and instead negotiates two separate sessions, one with the client and the other with the server. In each of these sessions, the attacker masquerades as another legitimate communicating party. By negotiating keys with both the client and the server, the attacker can compromise privacy by gaining access to the communication payload itself. However, several modern communication protocols have incorporated MITM countermeasures, such as by introducing an additional handshake step, requiring the communicating parties to be authenticated via a credential system.

[0069] Some embodiments of the present invention avoid operating in a MITM configuration by explicitly ensuring that any communication session is established directly between the corresponding client device and the terminal server. In some embodiments, the modified handshake message transmitted to the terminal server is almost the same as the original intercepted handshake message, except that the ciphertext portion uses a different handshake encryption key. In particular, the modified handshake saves session-specific, client-determined parameter values, such as client random and / or the session ID of the original intercepted handshake. Some embodiments further relay the server handshake message sent by the terminal server in response to the modified handshake message to the corresponding client device without modification. Such actions enable the corresponding client device and server to establish a single direct encrypted communication session and seamlessly authenticate each other. In addition, not participating in the actual negotiation of application keys with any of the communicating parties prevents the business filter from being able to decrypt the communication payload. Therefore, access control is implemented without compromising the confidentiality of the communication.

[0070] 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 invention. Therefore, the scope of the invention should be determined by the appended claims and their legal equivalents.

Claims

1. A method comprising employing at least one hardware processor of a computer system to: 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 section storing an identifier of the remote content server; decrypting the encrypted segment to retrieve the identifier of the remote content server; determining, based on the identifier of the remote content server, whether an access policy associated with the client device permits the client device to access the remote content server; as well as In response, when the access policy permits the client device to access the remote content server: determining a handshake encryption key based on the identifier of the remote content server, modifying the client handshake message by replacing the encrypted section with a replacement encrypted section storing the identifier of the remote content server, the replacement encrypted section encrypted using the handshake encryption key, transmitting the modified handshake message to the destination of the client handshake message, and Responsive to intercepting another message sent by the remote content server within the encrypted communication session, relaying the other message to the client device.

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

3. A method according to claim 1, wherein the client handshake message includes a cryptographic parameter value, the cryptographic parameter value is used by the remote content server to derive an application key, the application key is used to encrypt a payload transmitted as part of the encrypted communication session, and wherein the modified handshake message includes the cryptographic parameter value.

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

5. The method according to claim 1, further comprising: In response to receiving a request to resolve a domain name of the remote content server, transmitting, using a DNS server, to the client device a proxy encryption key different from the handshake encryption key; and Wherein the encrypted segment is encrypted by the client device using the proxy encryption key.

6. The method of claim 5, further comprising employing the at least one hardware processor to: Retrieving a proxy decryption key from the DNS server; and The encrypted segment is decrypted using the proxy decryption key.

7. The method of claim 5, further comprising employing the at least one hardware processor to: generating a cryptographic 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; and The encrypted segment is decrypted according to the proxy decryption key.

8. The method of claim 5, further comprising, in preparation for transmitting the proxy encryption key to the client device, employing the DNS server to: selecting a content category from a plurality of content categories based on the domain name, the content category indicating a type of content distributed by the remote content server; and In response, the proxy encryption key is selected from a plurality of proxy encryption keys based on the selected content category.

9. The method according to claim 8, comprising: selecting the proxy encryption key from the plurality of proxy encryption keys using the DNS server according to whether the remote content server distributes malicious content; and In response to decrypting the encrypted segment, the at least one hardware processor is employed to interpret the decryption as indicating that the remote content server distributed malicious content.

10. The method of claim 1, wherein determining the handshake encryption key comprises: transmitting a DNS query to a DNS server, the DNS query being formulated based on the identifier of the remote content server; and In response, the handshake encryption key is received from the DNS server.

11. A computer system having at least one hardware processor programmed to execute a service filter, the service filter being configured to: 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 section storing an identifier of the remote content server; decrypting the encrypted segment to retrieve the identifier of the remote content server; determining, based on the identifier of the remote content server, whether an access policy associated with the client device permits the client device to access the remote content server; as well as In response, when the access policy permits the client device to access the remote content server: determining a handshake encryption key based on the identifier of the remote content server, modifying the client handshake message by replacing the encrypted section with a replacement encrypted section storing the identifier of the remote content server, the replacement encrypted section encrypted using the handshake encryption key, transmitting the modified handshake message to the destination of the client handshake message, and Responsive to intercepting another message sent by the remote content server within the encrypted communication session, relaying the other message to the client device.

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

13. A computer system according to claim 11, wherein the client handshake message includes a cryptographic parameter value, the cryptographic parameter value is used by the remote content server to derive an application key, the application key is used to encrypt a payload transmitted as part of the encrypted communication session, and wherein the modified handshake message includes the cryptographic parameter value.

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

15. The computer system of claim 11 , further comprising a DNS server configured to transmit a proxy encryption key different from the handshake encryption key to the client device in response to receiving a request to resolve a domain name of the remote content server, and wherein the encrypted segment is encrypted by the client device using the proxy encryption key.

16. The computer system of claim 15, wherein the at least one hardware processor is further configured to: Retrieving a proxy decryption key from the DNS server; and The encrypted segment is decrypted using the proxy decryption key.

17. The computer system of claim 15, wherein the at least one hardware processor is further configured to: generating a cryptographic 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; and The encrypted segment is decrypted according to the proxy decryption key.

18. The computer system of claim 15, wherein in preparing to transmit the proxy encryption key to the client device, the DNS server is further configured to: selecting a content category from a plurality of content categories based on the domain name, the content category indicating a type of content distributed by the remote content server; and In response, the proxy encryption key is selected from a plurality of proxy encryption keys based on the selected content category.

19. The computer system of claim 18, wherein: The DNS server is configured to select the proxy encryption key from the plurality of proxy encryption keys based on whether the remote content server distributes malicious content; and The at least one hardware processor is further configured to, in response to decrypting the encrypted segment, interpret the decryption as indicating that the remote content server distributes malicious content.

20. The computer system of claim 11, wherein determining the handshake encryption key comprises: transmitting a DNS query to a DNS server, the DNS query being formulated based on the identifier of the remote content server; and In response, the handshake key is received from the DNS server.

21. 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 configured to: 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 section storing an identifier of the remote content server; decrypting the encrypted segment to retrieve the identifier of the remote content server; determining, based on the identifier of the remote content server, whether an access policy associated with the client device permits the client device to access the remote content server; as well as In response, when the access policy permits the client device to access the remote content server: determining a handshake encryption key based on the identifier of the remote content server, modifying the client handshake message by replacing the encrypted section with a replacement encrypted section storing the identifier of the remote content server, the replacement encrypted section encrypted using the handshake encryption key, transmitting the modified handshake message to the destination of the client handshake message, and Responsive to intercepting another message sent by the remote content server within the encrypted communication session, relaying the other message to the client device.

Images