CN110870277B

CN110870277B - Introducing middleboxes into secure communication between a client and a server

Info

Publication number: CN110870277B
Application number: CN201880042761.XA
Authority: CN
Inventors: T·卡拉基亚尼斯; C·格坎特西迪斯; D·内勒; R·李
Original assignee: Microsoft Technology Licensing LLC
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2017-06-26
Filing date: 2018-06-04
Publication date: 2022-03-29
Anticipated expiration: 2038-06-04
Also published as: EP3646553A1; EP3646553B1; WO2019005426A1; CN110870277A; GB201710168D0; US10389524B2; US20180375644A1

Abstract

A method of communicating over a network between a first endpoint and a second endpoint, one endpoint being a client and the other endpoint being a server. The method comprises the following steps: establishing a first secure transport layer tunnel between a first endpoint and a second endpoint, establishing a second secure transport layer tunnel between the first endpoint and a middlebox, the first endpoint being to delegate processing of traffic sent over the first secure transport layer tunnel to the middlebox; the first endpoint authenticates the middleboxes via the respective second secure transport layer channels and shares the encryption key of the first channel with the middleboxes via the second secure transport layer channels under the condition of the authentication; and causing traffic sent over the tunnel to be routed via the middlebox. The method thus enables the middlebox to process the content of the traffic sent over the first channel in a clear text manner.

Description

Introducing middleboxes into secure communication between a client and a server

Background

Internet communications no longer have to include two endpoints exchanging messages by dumping (dump) packet forwarding cores. Instead, data is often processed by an intermediate middlebox (such as a cache, compression agent, intrusion detection system, or virus scanner). For example, all four mobile operators in the united states use HTTP proxies, and a typical enterprise network has roughly the same number of middleboxes as routers and switches. However, as the use of online encryption increased (almost half of all Web flows used HTTPS by 2014), these middleboxes became "blind" to the content of the traffic and therefore unable to perform their work any more. This prompted the academic and industrial community to consider this issue: how is the middlebox integrated into a secure communication session?

Because TLS (the standard secure communication protocol used in the internet) is designed specifically for both parties, the current practice is to split the connection into two separate TLS connections: the middlebox emulates the server as a client and opens a second connection to the server. This greatly weakens security, in part, because the client cannot explicitly authenticate the middlebox, nor can it be assured that the middlebox properly authenticates the server. More recently, proposals such as multi-context tls (mctls) have addressed this problem by allowing endpoints to explicitly authenticate each other and middleboxes.

However, the emerging middlebox deployment model complicates the situation: the middlebox functionality is outsourced to a third party (such as an ISP or third party cloud provider that provides the middlebox as a service). This ensures cost-effectiveness in economies of scale and eliminates the need for a network administrator to configure and manage multiple dedicated boxes. But this also presents new challenges: the owner of the middlebox software (middlebox service provider) and the owner of the hardware running it (infrastructure provider) are different. If the infrastructure is not trusted, existing protocols like split TLS and mcTLS cannot provide the standard security attributes TLS provides for us today because, first, the session data and keys are visible in memory, and, second, the endpoint cannot determine whether the infrastructure provider actually runs the code that the middlebox provider expects it to run.

One known idea is to use new cryptographic techniques to protect session data from infrastructure providers. Blinbox and Embark introduced new technologies that allowed middleboxes to directly process cryptographic data. These operations are based on patterns that match the encrypted data without the need to decrypt it.

Disclosure of Invention

Although attractive from a privacy perspective, these solutions only support middleboxes that perform pattern matching, such as intrusion detection systems. They still have no access to the actual (clear) content of the encrypted traffic. This means that they are limited in what they can do. First, they are point solutions, i.e. they can only work on specific instances of a specific task. Second, they cannot perform any task that requires knowledge of the actual content. The need to manipulate encrypted content also makes them very slow. Furthermore, existing approaches require both endpoints to be upgraded, which is a significant obstacle to deployment.

It would be desirable to provide a technique that enables a middlebox to operate on the content of a service, but while still maintaining security. It would also be desirable to be able to do this preferably in a manner that does not necessarily rely on both endpoints being upgraded, so that the technique works even if one endpoint is upgraded to identify a new protocol and the other endpoint is a legacy endpoint.

According to one aspect of the present disclosure, there is provided a method of communicating over a network between a first endpoint and a second endpoint, the first endpoint being a client device or a server, and the second endpoint being the other of the client device and the server. The method includes establishing a first secure transport layer channel between the first endpoint and the second endpoint, the first secure transport layer channel defined by a first cryptographic key required to access content of traffic sent over the first secure transport layer channel. The method also includes establishing a second secure transport layer tunnel between the first endpoint and the middlebox, the first endpoint to delegate processing of traffic sent over the first secure transport layer tunnel to the middlebox, the second secure transport layer tunnel defined by a second cryptographic key required to access content sent over the second secure transport layer tunnel. The first endpoint authenticates (e.g., authenticates) the middlebox via the respective second secure transport layer channel, and shares the first encryption key with the middlebox via the second secure transport layer channel on condition of the authentication. Further, traffic sent over the tunnel is routed via the middlebox. The method thus enables the middlebox to process the content of the traffic sent over the first secure transport layer channel in clear text using the first cryptographic key.

Thus, by verifying (e.g., authenticating) its middlebox via a secondary (i.e., secondary) secure channel, the first endpoint may determine that the middlebox is authentic before introducing it into the first channel (i.e., the primary or primary channel). The second endpoint trusts the first endpoint, and the first endpoint trusts the middlebox. Furthermore, since the handshake required to bring the middlebox into the main channel is only performed between the first endpoint and its middlebox, the second endpoint does not have to know the middlebox or upgrade in any way to identify the new protocol. From the perspective of the second endpoint, it appears to be communicating only with the first endpoint.

In an embodiment, the disclosed protocol further protects session data from third party infrastructure providers by isolating the middlebox execution environment from the third party infrastructure in a so-called "enclave," i.e., an isolated execution environment that is inaccessible to any other application running on the third party's operating system. In embodiments, the execution environment is also not accessible to the third party's operating system itself or to any hypervisor.

In other alternative or additional embodiments, the disclosed protocol provides other useful security attributes that may be advantageous in a multi-party setting. For example, in an embodiment, the disclosed protocol ensures that data accesses middleboxes in an endpoint-specified order and prevents an attacker from knowing whether the middleboxes have modified the data before continuing to forward the data.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. The claimed subject matter is also not limited to implementations that solve any or all disadvantages described herein.

Drawings

To assist in understanding embodiments of the present disclosure and to show how they can be put into effect, reference is made, by way of example only, to the accompanying drawings in which:

FIG. 1 is a schematic diagram of a communication system for communicating between a client and a server via one or more middleboxes;

FIG. 2a is a schematic diagram of a method of including a middlebox in a channel established between a client and a server;

FIG. 2b is a schematic diagram of another method of communicating via a middlebox;

FIG. 3 is a schematic diagram of a technique for maintaining middlebox order in communications conducted via a plurality of middleboxes; and

fig. 4 is a schematic signaling diagram illustrating a method of establishing a secure TLS tunnel and introducing a middlebox into the tunnel.

Detailed Description

As mentioned above, today's Internet communications typically involve intermediate middleboxes, such as caches, compression agents, or virus scanners. As encryption becomes more prevalent, these middleboxes become blind and fail to provide their security, functionality, and performance advantages. Despite efforts both in the industry and academia, there is currently no way to integrate middleboxes into secure sessions while preserving the functionality of middleboxes and secure sessions.

The following presents a protocol for introducing one or more middleboxes into a secure channel, e.g. for use in a secure multiparty communication session. The protocol provides a set of security attributes for a session, such as a multi-party communication session. In an embodiment, the protocol is still valid even if one of the endpoints (client or server) is still a legacy endpoint that has not been upgraded to recognize the protocol. In an embodiment, the protocol uses an SGX enclave or the like to provide security guarantees on untrusted hardware. In an embodiment, if multiple middleboxes are introduced in the chain, the protocol also preserves the order in which traffic passes through each middlebox.

This protocol advantageously addresses two competing requirements. On the one hand, internet communications are no longer limited to two endpoints exchanging messages by dumping packet forwarding cores. Instead, the data is typically processed by an intermediate middlebox (such as a cache, compression agent, intrusion detection system, or virus scanner). On the other hand, however, as the use of online encryption increases, these middleboxes become blind and can no longer perform their work. It is desirable to be able to preserve the security of such encryption while allowing the possibility of using middleboxes, including third party middleboxes.

For example, it is increasingly considered to outsource middlebox functionality to an ISP or third party cloud provider that provides middlebox as a service. This ensures cost-effectiveness in economies of scale and eliminates the need for a network administrator to configure and manage multiple dedicated boxes. However, this arrangement also presents new challenges: the owner of the middlebox software (middlebox service provider) and the owner of the hardware running it (infrastructure provider) are different. If the infrastructure is not trusted, existing protocols cannot provide the standard security attributes that TLS provides us today because (i) the session data and keys are visible in memory, and (ii) the endpoint cannot determine whether the infrastructure provider actually runs the code that the middlebox provider expects it to run.

FIG. 1 illustrates a networked computer system according to an embodiment of the disclosure. The system includes a packet switched data network 101, preferably in the form of a wide area network such as the one commonly referred to as the internet. The system further comprises a plurality of client devices in the form of user terminals 102, each client device being used by a respective user 103. Each user terminal 102 may take any of a number of potential forms, for example, a stationary user terminal such as a desktop computer or a mobile terminal such as a laptop computer, tablet computer, smartphone, or wearable device (e.g., a smart watch or smart glasses). Each user terminal 102 is configured to connect to the network 101 via a suitable wired or, more generally, wireless access technology, e.g. a local wireless router or access point via a Wireless Local Area Network (WLAN); or via a mobile cellular network, such as a 3GPP network (e.g., a 3G, LTE, 4G, or 5G network); or via a local wired network, such as ethernet; or via a cable modem connected to network 101 via a PSTN or cable network. Those skilled in the art will be familiar with various other approaches. It should also be noted that different user terminals do not necessarily have to take the same form as each other, nor do they necessarily have to be connected to the network 101 via the same means.

The system further comprises a server 104, which server 104 is also connected to the network 101. Note that a server as referred to herein refers to any server device that may include one or more physical server units located in one or more geographic locations. In the case of multiple units (so-called "cloud" computing or cloud storage arrangements), those skilled in the art will be familiar with suitable techniques for distributed storage and distributed computing per se. Also, various suitable wired or wireless means for connecting the server unit(s) to the network 101 and, in the case of a distributed system, to each other are known to those skilled in the art (e.g., those discussed above or others).

The server 104 is configured to host the service software 106 by any means physically implemented. The service software 106 is in the form of code stored on a storage device of the server 104 and arranged to run on a processing device of the server 104. The service software 106 is configured such that when run in this manner, services are provided to the client device 102 and its user 103 via the network 101. The services provided may take any of a variety of forms, such as cloud storage services, collaborative workspace services, VoIP or video conferencing services, and so forth. Regardless of the application, the service software 106 is also configured to perform server-side functions in accordance with any of the methods disclosed herein. Where operations are attributed herein to the server 104, it should be understood that this refers to a shorthand for operations performed by the service software 106 running on the server 104.

The storage (memory) storing the service software 106 may take the form of one or more memory units implemented on one or more memory units implemented in any one or more server units, employing any suitable one or more memory media, e.g., magnetic media such as hard disk drives, electronic media such as EEPROMs, flash memory or Solid State Drives (SSDs), or even optical media. The processing device of the server 104 running the service software 106 may include one or more single-core or multi-core processing units implemented in any one or more server units. Such processing units may include, for example, a CPU and/or a work accelerator processor, such as a GPU or the like. Various suitable physical processor means will be familiar per se to those skilled in the art.

Each user terminal 102 is installed with a respective instance of a client application 105. The client application 105 is in the form of software stored on a storage means of the respective user terminal 102 and arranged to run on a processing means of the respective user terminal 102. The client application 105 is configured, when so executed, to access the service software 106 on the server 104 via any suitable wired or wireless network interface of the network 101 and the respective user terminal 102 (e.g., a network interface configured to connect via any of the aforementioned means). The client application 105 is also configured to perform client-side functions according to any of the methods described herein. Where operations are attributed herein to the client device 102 or simply to a "client," it should be understood that this refers to an abbreviation for operations performed by the client application 105 running on the respective client device 102.

The storage (memory) storing each respective instance of the client application 105 may take the form of one or more memory units of the respective user terminal 102, employing any suitable one or more memory media, for example, magnetic media such as a hard disk drive, electronic media such as an EEPROM, flash memory, or Solid State Drive (SSD), or optical media such as a CD ROM or DVD drive. The processing device of the respective user terminal 102 running the respective instance of the client application 105 may include one or more single-core or multi-core processing units. Such processing units may also include a CPU and/or a work accelerator processor, such as a GPU or the like. Various suitable physical processor devices will also be familiar per se to those skilled in the art.

Further, the computer system includes one or more middleboxes 108 running on one or more intermediate network devices 107. Middleboxes 108 are entities to which a client or server defers certain operations to be performed on a service (not just packet forwarding). Typically this will include some operations that require access to the content of the service, i.e. the plaintext (decryption) payload. Such middleboxes 108 may include, for example, any one or more of the following: a virus scanner, a child security filter (e.g., a parental control filter), an intrusion detector, a compression agent, an audio and/or video transcoder, an HTTP proxy, an application layer load balancer, and/or a cache.

Middleboxes 108 may include one or more client middleboxes 108-C to which client 102 defers one or more operations, and/or one or more server middleboxes 108-S to which server 104 defers one or more operations.

Each middlebox 108 is in the form of software stored in the storage means of its respective network device 107 and arranged to run on the processing means of the respective network device. The storage used may also include one or more physical storage units at one or more geographic locations, and one or more storage media (e.g., magnetic media such as hard disk drives, or electronic media such as EEPROMs, flash memory, or SSDs, etc.) may be used. The processing device may also include one or more single-core or multi-core processing units, such as CPUs and/or work accelerator processors and the like. Likewise, various suitable wired or wireless means for connecting middlebox apparatus 108 to network 101 are known to those skilled in the art (e.g., those discussed above or others). Likewise, various suitable physical storage devices, processors, and network interface devices will themselves be familiar to those skilled in the art. The middleboxes 108 may be implemented in separate physical units from each other or in the same physical unit. Middlebox device 108 may be external to both client device 102 and server 104, or may even be implemented in the same physical device as server 104.

Whatever form the physical implementation takes, the client 102 is configured to establish a secure transport layer channel 201 with the server 104 over the network 101 via one or more middleboxes 108-C, 108-S. The channel 201 may include one or more middleboxes of the client 102 introduced into the channel 201 by the client 102; and/or one or more middleboxes 108 of servers 104 introduced into the tunnel by server 204. The establishment of the channel is initiated by the client 102.

Preferably, the secure transport layer tunnel 201 takes the form of a TLS tunnel established using the TLS (transport layer security) protocol. Embodiments will be described below in terms of TLS tunnels, but without excluding that other types of secure transport layer protocols will be used to implement the methods disclosed herein, e.g. conventional protocols such as SSL (secure sockets layer) or future variants of TLS, which a skilled person may design using his/her skill in the art.

The transport layer is a layer of the OSI model above the packet layer, for example: above the IP layer in an IP (internet protocol) based network such as the internet. The channel is "secure" in that the content of the traffic sent over the channel is encrypted (using known cryptographic techniques per se which will be familiar to those skilled in the art). The secure transport layer channel is defined, at least in part, by a cryptographic key required to decrypt traffic sent over the channel. In case a middlebox 108 is introduced into a TLS tunnel 201, this means that it has obtained the key of the relevant tunnel and that traffic sent over this tunnel is routed via the middlebox 108 concerned.

As shown in fig. 2a, this is achieved by establishing a secondary secure transport layer tunnel 202 (preferably also a TLS tunnel) between the middlebox 108 and the endpoint (client 102 or server 104) to which the middlebox belongs. For ease of discussion, the middlebox 108 involved is that of the server 104, i.e., the middlebox 108-S to which the server 104 delegates some operation to be performed on traffic between the client 102 and the server 104 (although the same process may be used instead or in addition, mutatis mutandis, to enable the client 102 to introduce the middlebox 108-C of the client 102).

According to the protocol disclosed herein, server 104 establishes a secondary (i.e., secondary) TLS tunnel 202 with its middlebox 108-S via network 101. The server 104 then uses the channel to authenticate the middlebox. Preferably, this includes at least: verification that the contacted middlebox 108-S is provided by the intended party (e.g., the intended third party). In an embodiment, this verification includes performing authentication through the second TLS channel 202 to authenticate that the party providing the middlebox is the trusted party. This may employ any of a number of possible authentication techniques known per se in the art. Further, in embodiments, the verification performed via the second TLS channel 202 may alternatively or additionally include verifying that the contacted middlebox 108-S provides the desired service. For example, if the server requires virus scanning services, the server 104 verifies that the middlebox 108-S involved includes a virus scanner and that it is a specific virus scanner. In an embodiment, this includes verifying the binary file that initializes the enclave, which represents a particular version of a particular virus scanner.

Once this verification is complete, and in the case of a positive verification, the server 104 then shares the cryptographic security key for the primary (primary) TLS channel 201 with the middlebox 108-S through the secondary TLS channel 202.

From the beginning, the server 104 advertises its IP address or domain name to the client 102 as the IP address or domain name of the server' S middlebox 108-S, so that when the client 102 sends a message establishing the primary TLS tunnel 201 and subsequently sending traffic through the primary TLS tunnel 201, all of these messages and traffic are routed to the server 104 via the middlebox 108-S, which middlebox 108-S is set up to forward them to the server 104. An alternative is to configure routing protocols and/or forwarding mechanisms in network 101 to forward traffic destined for server 104 to middlebox 108-S. Messages and traffic sent from the server 104 back to the client 102 are also routed via the middlebox 108-S. Further, once it has the address and key, middlebox 108-C can access the actual (decrypted) content of any traffic passed via middlebox 108-S. This enables it to perform its function as a middlebox, such as a virus scanner or a parental filter.

Because the client 102 trusts the server 104 (already authenticated via the primary TLS channel 201), and the server 104 trusts the middlebox 108-S, the client 102 can actually be considered to trust the server' S middlebox 108-S-even though the client 102 does not necessarily actually need to know that it is communicating via the middlebox 108-S to do any different operations with it directly establishing a traditional TLS channel with the server 104. The latter point of view indicates that the server 104 may be upgraded with the new protocol, while the client 102 may still be a legacy client in embodiments.

If the client 102 is not a legacy client, the same process may be used with respect to the client 102 and its middlebox 108-C, mutatis mutandis. That is, the client 102 establishes a corresponding secondary TLS channel (different from the channel established by the server 104 if both use middleboxes), and uses that channel to authenticate the corresponding middlebox 108-C. It then shares the encryption key of the primary channel using that channel. Client 102 also advertises its IP address or domain name to server 104 as the IP address or domain name of client's middlebox 108-C, otherwise routing protocols and/or forwarding mechanisms in network 101 are configured to forward traffic destined for client 102 to its middlebox 108-C. Thus, traffic sent via the client's middlebox 108-C is made accessible (in clear text) to that middlebox 108-C, enabling it to perform its middlebox functions on behalf of the client 102. In an embodiment, the server 104 need not be upgraded to identify new protocols, but may be a legacy server 104. Alternatively, both the client 102 and the server 104 can use their own middleboxes 108-C, 108-S, in which case the client 102 and the server 104 each execute separate instances of the protocol via different respective secondary TLS channels 202.

An example implementation of this protocol is shown in more detail in fig. 4 to be discussed in more detail later. The steps shown with solid lines represent the steps of the primary handshake whereby the client 102 establishes a primary secure transport layer channel with the server 104. The steps shown with dashed lines represent the steps of the client-side secondary handshake, whereby the client 102 establishes a respective secondary secure channel with its middlebox 108-C, authenticates the middlebox 108-C via the secondary channel, and then shares the secure key for the primary channel 201 with the respective middlebox 108-C via the respective secondary channel. The steps shown with dashed lines represent the steps of the secondary handshake on the server side, whereby the server 104 establishes a respective secondary secure channel with its middlebox 108-S, authenticates the middlebox 108-S via the secondary channel, and then shares the secure key for the primary channel 201 with the respective middlebox 108-S via the respective secondary channel.

For client side middlebox 108-C, when client 102 sends a standard TLS message requesting initiation of the primary TLS tunnel, it includes a new type of TLS extension therein to declare its support for middleboxes. The message is sent to the server 104 via the middlebox 108-C. This extension triggers middlebox 108-C to begin a handshake with client 102 to establish the secondary TLS channel. For a server-side middlebox where a legacy client does not include a new TLS extension, the server middlebox 108-S autonomously sends a new (non-standard) TLS message stating itself to the server 104, which starts to handshake with the server 104 to establish a secondary TLS tunnel.

Once the primary TLS channel 201 is established and any required middleboxes 108 are successfully introduced, the primary TLS channel 201 can be used for any application desired by the programmer. For example, the primary TLS channel 201 may be used to conduct a multipart communication session, including a client 102 (e.g., client 102a in fig. 1) and one or more additional clients 102b, … …, 102n, each communicating with each other via the server 104 and the primary TLS channel 201. For example, the session may include a multiparty VoIP call, a video call, or other media session, such as a remote slide presentation, a screen sharing session, or a virtual whiteboard.

As shown in fig. 2b, in an embodiment, middleboxes 108 (or each middlebox 108) preferably operates in a secure "enclave" on its respective network device 108. This is a secure virtual environment in which the middlebox 108 and the data it receives over the

secure TLS tunnel

201, 202 is isolated from other applications running on the operating system of the same network device 107. That is, no other application can access the data even if running on the same physical device. Examples of suitable security enclosures include SGX (software protection extensions), TrustZone (trusted zone), SEV (secure encryption virtualization), etc. In cases such as SGX, the operating system itself, like any hypervisor, cannot access the data within the enclave.

As shown in fig. 3, in other alternative or additional embodiments, a chain of multiple middleboxes 108 can be introduced into the primary TLS channel 201, including one or more clients 102 and one or more servers 104 (such that one or both of the clients 102 and servers can have a corresponding plurality of middleboxes 108). In the case of multiple client-side middleboxes 108-C, the client 102 establishes a different respective secondary TLS channel with each in order to introduce the respective middlebox 108-C into the primary TLS channel according to the procedure described above. Similarly, in the case of multiple server-side middleboxes 108-S, the server 104 establishes a different respective secondary TLS channel with each of the server-side middleboxes 108-S, again in accordance with the above-described process.

The client 102 forwards messages and traffic to the first (nearest) client side middlebox 108-C in the chain, and the middlebox forwards them to the next client side middlebox 108-C in the chain, and so on. The farthest client side middlebox 108-C forwards messages and traffic to the server side middlebox 108-S farthest from the server 104, the server side middlebox 108-S forwards them to the next server side middlebox 108-S in the chain, and so on until the server side immediate (closest) middlebox 108-S forwards to the server 104. Note that "nearest" and "farthest" herein refer to the number of hops, and are not necessarily physical distances. When sending traffic and messages from the server 104 to the client 102, the process proceeds in the same manner but in the opposite direction.

Further, according to certain embodiments disclosed herein, a technique is applied to ensure middlebox ordering when sending traffic over the primary TLS tunnel 201 between the client 102 and the server 104. Traffic is encrypted using a first client-side encryption key, K _ C-C1, as it is routed along a direct hop between the client 102 and its direct (nearest) client-side middlebox 108-C1. When traffic is routed along the next hop between that client side middlebox 108-C1 and the client side middlebox 108-C0 that is the next farthest from the client 102, the traffic is encrypted using a different second client side encryption key, K _ C1-C0, and so on. Traffic is encrypted using the first server-side encryption key K _ S1-S as it is routed along a direct hop between the server 104 and its direct (nearest) server-side middlebox 108-S1. When traffic is routed along the next farthest hop between that server-side middlebox 108-S1 and the server-side middlebox 108-S0 that is the next farthest from the server 104, the traffic is encrypted using a different second client-side encryption key, K _ S0-S1, and so on. Note that these encryption keys are different from the encryption keys of the secondary TLS channel used to authenticate middlebox 108 and share the key of the primary TLS channel with them.

Traffic is exchanged between the client side middlebox 108-C, which is furthest away from the client 102, and the server side middlebox 108-S, which is furthest away from the server, using the primary encryption key K _ C-S of the primary TLS channel. Note that: it is assumed here that the client-side and server-side middleboxes 108-C, 108-S do not mix with each other, e.g., the server-side middlebox 108-S cannot be closer to the client than any of the client-side middleboxes 108-C. The way this is achieved is as follows: middleboxes 108 observe traffic from other middleboxes 108 and disable themselves if they see traffic from a different type of middlebox (e.g., client side middlebox 108-C sees server middlebox traffic).

Thus, traffic at each hop is encrypted using a different respective unique encryption key. That is, the receiving middlebox 108 at each hop decrypts using the key set for the previous hop and then re-encrypts the next direct hop using the new key so that the next middlebox can decrypt. This ensures that the middleboxes must process the traffic separately in the desired order in the chain, otherwise the middleboxes will not be able to decrypt the content of the traffic. Moreover, another benefit is that any malicious third party that eavesdrops on traffic cannot even determine whether any given middlebox 108 in the chain has modified the traffic, because the traffic in encrypted form will look different at any jump along the route anyway (for some security-sensitive applications, and the eavesdropper cannot see the clear content of the traffic and hopefully cannot even determine whether the content of the traffic has been modified).

Some other exemplary implementation details will now be discussed in more detail with reference to fig. 2a to 4.

As previously mentioned, internet communications are no longer limited to two endpoints exchanging messages by dumping packet forwarding cores. Instead, data is often processed by an intermediate middlebox (such as a cache, compression agent, intrusion detection system, or virus scanner). For example, all four mobile operators in the united states use HTTP proxies, and a typical enterprise network has roughly the same number of middleboxes as routers and switches. As the use of online encryption increased (almost half of all Web flows used HTTPS by 2014), these middleboxes became blind and could no longer perform their work, which prompted academia and industry to consider the following: how is the middlebox integrated into a secure communication session?

Because TLS (the standard secure communication protocol used in the internet) is designed specifically for both parties, the current practice is to "split" the connection into two separate TLS connections: the middlebox emulates the server as a client and opens a second connection to the server. This greatly weakens security, in part because the client cannot explicitly authenticate the middlebox, nor can it be assured that the middlebox properly authenticates the server. More recently, proposals such as multi-context tls (mctls) have addressed this problem by allowing endpoints to explicitly authenticate each other and middleboxes. However, the situation becomes complicated by the emerging middlebox deployment model: the middlebox functionality is outsourced to a third party cloud provider or ISP that provides middlebox as a service. This ensures cost-effectiveness in economies of scale and eliminates the need for a network administrator to configure and manage multiple dedicated boxes. This presents new challenges: the owner of the middlebox software (middlebox service provider) and the owner of the hardware running it (infrastructure provider) are different. If the infrastructure is not trusted, existing protocols like "split TLS" and mcTLS cannot provide the standard security attributes TLS provides for us today because, first, the session data and keys are visible in memory, and, second, the endpoint cannot determine whether the infrastructure provider actually runs the code that the middlebox provider expects it to run.

The current idea is to use new cryptographic techniques to protect session data from infrastructure providers. Blinbox and Embark introduced novel cryptographic techniques that allowed middleboxes to directly process encrypted data. Although attractive from a privacy perspective, BlindBox (to date) is too slow to deploy in practice, and these solutions only support middleboxes that perform pattern matching, such as intrusion detection systems. Worse yet, BlindBox and mcTLS require both endpoints to upgrade, which is a significant obstacle to deployment. The protocol referred to herein as middlebox tls (mbtls), which is a protocol for secure multiparty communication that addresses these shortcomings, is presented below.

(i) mbTLS protects session data from third party infrastructure providers. mbTLS isolates the middlebox execution environment from third party infrastructures using trusted computing technologies (e.g., Intel SGX [12, 29, 20 ]). It uses two features that are typically provided by platforms such as SGX: secure execution environment — the code, heap, and stack of the middlebox application are encrypted and integrity protected in memory; and remote attestation-the middlebox can prove to the endpoint that the execution environment is properly configured in an encrypted manner.

(ii) mbTLS interoperates with legacy TLS endpoints. Unlike mcTLS or BlindBox, an mbTLS endpoint can securely include a middlebox in a session with an unmodified TLS endpoint. In testing, the inventors used the mbTLS client to successfully load content from over 300 top-level Alexa sites.

(iii) mbTLS provides other useful security attributes unique to multiple party settings. For example, mbTLS guarantees that data accesses middleboxes in the order specified by the endpoint, and prevents attackers from knowing whether middleboxes have modified the data before continuing to forward the data.

Embodiments implement mbTLS using OpenSSL and Intel SGX SDKs. mbTLS does not increase handshake delay compared to TLS, and mbTLS reduces CPU load on middleboxes and only increases reasonable overhead on servers. Furthermore, running inside the SGX enclave does not reduce throughput. mbTLS is an important and practical step to bridge the gap between end-to-end security and the reality that middleboxes do not disappear.

Today, most network communication sessions involve more parties than just clients and servers. In general, these other parties fall into one of three categories:

network layer middleboxes (e.g., firewall, NAT, layer 3 load balancer). These middleboxes process the data on a packet-by-packet basis without requiring reconstruction or access to application layer data.

Application-level middleboxes (e.g., virus scanner, IDS, parental filters, cache, compression agent, application-level load balancer). These middleboxes do need access to application layer data.

Application layer representation (e.g., CDN). In contrast to middleboxes which act as intermediaries between clients and servers in communication, the term "delegation" is introduced herein to refer to intermediaries that act as servers during a session (although in real world relationships they are still more naturally considered intermediaries). A Content Delivery Network (CDN) is a good example; the client communicates with the CDN server and does not interact directly with the origin server.

With the improvement of security practices and the evolution towards the ubiquitous internet of encryption, it is clear that there is no suitable protocol for secure multiparty communication at present, nor is the existing literature disclosing the attributes that should be provided.

In both cases, it is well known what security attributes are ideal, and how to implement them — TLS has been used successfully for many years. But in a multi-party scenario, there are still two key unsolved problems. First, which security attributes should be held for a session involving three or more parties? Second, what is the best mechanism to enforce these properties?

The answers to these questions may be different for each of these three classes of intermediaries. The present disclosure focuses on application layer middleboxes and, in embodiments, on secure multiparty communications involving application layer middleboxes. Even in application-only middleboxes, there may be differences in security requirements. For example, intrusion detection systems and compression agents behave quite differently, as do trust relationships between administrator-specified virus scanners and compression services that opt-in, indicating that there may not be a single one-size-fits-all solution. However, in practice at least two specific requirements may be required.

One is to protect session data in the case of a packet middlebox. There is an increasing interest in deploying middleboxes in third party environments. This may take one of at least two possible forms. First, network functions can be outsourced to a cloud provider that operates a middlebox specifically, thereby eliminating the need for network administrators to learn to operate a dedicated box and reducing costs with economies of scale. Second, deploying middleboxes in client ISPs can help reduce latency or bandwidth costs (e.g., using network proxy connections of nodes in the client ISPs). In both cases, the logical owner of the network function and the operator of the hardware running it are different. Since the middlebox infrastructure may not be trusted, it is desirable to protect session data from the middlebox infrastructure in addition to traditional network attackers.

Another desirable requirement is traditional interoperability. Protocols such as BlindBox and mcTLS both require upgrading of both endpoints. Other protocols require at least an upgrade of the client, which means that the server cannot include middleboxes in a session with a legacy client. In practice, however, waiting for every client on the internet to be upgraded is not an option; this is particularly true given that up to 10% of HTTPS connections have been intercepted. Therefore, it is desirable to support legacy endpoints.

Currently, network administrators or end users running local virus/malware scanning software using the "split TLS" method sometimes insert middleboxes into encrypted connections. The middlebox (or client side software) terminates the TLS connection to pretend to be a server and opens a second TLS connection with the intended server.

The middlebox dynamically generates credentials for the domain name of the server and signs them with its own CA key, which has been pre-installed on the client. A recent study found that almost all popular middleboxes using this approach reduce connection security, and some of them introduce serious vulnerabilities; most of which are due to the inability of the client to directly authenticate or negotiate a password with the server. Recent industry recommendations provide greater transparency, but still do not guarantee to the client that the middlebox does not degrade session security.

The following threat model describes a target scenario addressed by the embodiments disclosed herein.

A role. There are six main roles. Each indicia is labeled herein as "trusted" or "untrusted," where trusted indicates that the role is authorized to access session data. Note that the last three roles are specific to multi-party communications, and the last role is specific to the outsourced middlebox scenario.

Client (C) [ trusted ]: a user, their machine, and the software (e.g., a web browser) they run. It may be assumed that any other software running on the machine is trusted (i.e., the software's misbehavior is out of range).

Service provider (S) [ trusted ]: a company that provides online services, its servers, and the software (e.g., web servers) that they run. As with the client, for present purposes, it can be assumed that no attacks are made by other software or malicious employees running on the company's own server.

Third Party (TP) [ untrusted ]: any other person who has access to network traffic (or a log of such traffic), such as a Wi-Fi interceptor (sniper) of an ISP or coffee shop.

Middlebox Service (MS) [ trusted ]: middlebox software that processes session data.

Middlebox Service Provider (MSP) [ trusted ]: an entity that provides the middlebox service and any internal servers that store information related to the service.

Middlebox Infrastructure Provider (MIP) [ untrusted ]: an entity that provides the hardware running the middlebox software, such as a customer ISP or a dedicated cloud middlebox service. It may be assumed that the company, its employees, its hardware, and any other software running on its machines are not trusted.

Adversary ability: the following assumes that an active global adversary can observe and control any untrusted parts of the system. In a network, an adversary can observe, modify, or drop any packets and inject new packets. On the middlebox infrastructure, an adversary can have full access to all hardware (e.g., it can read and manipulate memory) and software (e.g., it can execute arbitrary code, including privileged code such as a malicious OS). This includes the ability to modify or replace the middlebox code sent by the MSP for execution by the MIP. However, assume that the adversary is computationally limited (i.e., cannot break standard cryptographic primitives) and cannot compromise trusted computing hardware (e.g., Intel SGX-enabled CPU). Bypass attacks (e.g., traffic-based or cache access patterns), exploitable holes in the middlebox software, and denial of service are out of range.

Security attributes: "secure" multiparty communication with the application layer middlebox can be defined by the following four properties P1 to P4.

P1: and (6) data is kept secret. P1A: the adversary must not be able to read the session data. P1B: the communication should be forward secret (leakage of a long-term private key does not help an attacker access data of a previous session). P1C: the adversary should not learn more from observing the ciphertext (e.g., the adversary should not learn whether the middlebox modified the data before forwarding the data) than if each hop was its own independent TLS connection.

P2: and (6) data authentication. An adversary should not be able to modify, delete or inject session data. This includes replaying or reordering the data.

P3: and (4) entity authentication. The endpoints must be able to verify that they are communicating with the "correct thing". This involves two subtly interleaved properties. P3A: each endpoint may verify whether the other endpoint is operated by the intended entity and whether each MS is operated by the intended MSP (e.g., a server of a video sharing service). P3B: each endpoint can verify that the other endpoint and each MS is running the expected software and is properly configured (e.g., Apache v2.4.25 with only the strong TLS cipher suite enabled).

P4: path integrity. The endpoints repair the ordered path of the middlebox for the session. It is not possible for any other entity (including the middlebox) to cause the middlebox to process the session data in a different order (including skipping middleboxes).

Note that the first three attributes are the same attributes that TLS provides for two-party communications, but extend to multi-party settings; fourth path integrity occurs only when three or more parties are present (path order can affect security, especially when the middlebox performs filtering and/or cleaning functions).

Since TLS already provides many desirable attributes, one approach is: a conventional TLS session is established between the client and the server and the session key is then passed to the middlebox through a separate secondary TLS session. This is shown in fig. 2 a. This provides many desirable security attributes: encrypting and integrity protecting the data against changes from third parties; if a forward security cipher suite is used, the communications are forward secret and the endpoints can use credentials to verify each other's identity.

However, for the three reasons mentioned above, using TLS in this manner is a less preferred embodiment according to the threat model mentioned above: (I) since it is designed for both parties, it has no mechanism for providing path integrity (P4); (II) encryption is performed using the same key at each hop in the session so that adversaries can easily compare records entering and leaving the middlebox to see if they have changed (P1C); and (III) the infrastructure provider can access the session data in memory (P1A), access the key material in memory and use it to forge the MAC (P2), and possibly run software (P3B) other than that provided by the MSP.

In an embodiment, these problems are solved by making two further advanced changes to the method of fig. 2 a. This is illustrated in fig. 2b, where a unique key is generated for each hop and the middlebox runs in a secure execution environment. This result may be referred to herein as the middle box tls (mbtls). First, the handshake is modified to assign a unique symmetric key to each hop in the session. This prevents an adversary from passing the recording to an out-of-order middlebox and makes it impossible to determine when the middlebox forwards the data without changing the data. Second, if protection infrastructure is needed, a middlebox can be run in a secure execution environment (e.g., Intel SGX enclave) to protect session data and keys from untrusted MIPs.

Comments on trusted computing and SGXL: some features of mbTLS employ trusted computing technologies such as Intel's software protection extensions (SGX). Specifically, mbTLS uses two features provided by SGX: a secure execution environment and remote attestation.

In alternative implementations, any trusted computing technology that provides these features (such as Microsoft's Virtual Secure Mode (VSM) or ARM TrustZone) may also work properly. (other technologies such as ARM TrustZone provide similar functionality but provide slightly different security guarantees.)

A secure execution environment: SGX allows applications to run code in a secure environment called a enclave.

A bounding region is a protected memory area containing program code and data; before moving cache lines to DRAM, they are encrypted and integrity protected by the CPU. Even malicious hardware or privileged software cannot access or modify the enclave memory as long as the CPU is not physically corrupted. Running code in the enclave may result in performance degradation because (a) the cache line written to/read from memory must first be encrypted/decrypted and (b) the enclave thread must leave the enclave to make system calls, such as send () and recv (), because the OS is not trusted.

Remote attestation: the SGX may provide the code running in the enclave with a special message signed by the CPU, called a attestation, that attests to the remote party that the code in question did indeed run in the enclave on the real Intel CPU. The attestation includes a cryptographic hash of the initial state of the enclave code and the data page (so the remote verifier can see that the expected code is running), and custom data provided by the enclave application (which is used to integrate the attestation with the TLS handshake).

Example implementation details of middlebox TLS or mbTLS (a protocol for secure multiparty communication that enables endpoints to establish a secure communication session that includes an application layer middlebox) are provided below. Each

endpoint

102, 104 adds zero or more middleboxes to the session, which may be referred to as client-side and server-side middleboxes (108-C and 108-S in the figure). Each endpoint does not know the other's middlebox (or does not know the other has a middlebox at all). Importantly, this means that the mbTLS endpoint can interoperate with legacy TLS endpoints.

At a high level, the endpoints perform standard TLS handshakes to establish a primary TLS session that will ultimately be used for data transfer. The endpoints establish a secondary TLS session simultaneously with each of their middleboxes. Once an endpoint has a secure channel to the middlebox, it sends the middlebox the keying material needed to join the primary end-to-end session.

In an embodiment, the presently disclosed protocol extends TLS 1.2 handshake 2 to optionally include remote attestation, which the endpoint can use to verify whether these secondary TLS sessions terminate within the secure execution environment. In an embodiment, this is the only change to the TLS 1.2 handshake that is used as the building block for the mbTLS handshake.

At the end of the mbTLS handshake, the session is as shown in fig. 3. The example session shows two client-side middleboxes and two server-side middleboxes. Each hop encrypts and MAC protects the data using a different key-the client generates keys for the client side hops, the server generates keys for the server side hops, and the primary session keys bridge both sides. Since each hop has its own encryption/MAC key, an adversary can be prevented from causing the records to skip the middleboxes or traverse the middleboxes in the wrong order, and an eavesdropper can be prevented from detecting whether the middleboxes have modified the records. Otherwise, the recording layer is the same as the standard TLS. Each endpoint will generate keys for half of its connections (e.g., the client generates KC-C1 and KC1-C0 in the figure). The session key established due to the primary handshake KC-S acts as a "bridge" between the client-side and server-side middleboxes.

In an embodiment, messaging according to the mbTLS protocol may operate as follows. Reference is also made to fig. 4. mbTLS uses the same per-hop TCP connection for primary and secondary handshakes. A new TLS record type (encapsulated) is introduced to wrap the auxiliary TLS records between the middlebox and its endpoints. These records include an external TLS record header followed by a one byte subchannel ID and an encapsulated record. The detailed information refers to the mbTLS message format.

With respect to client side middleboxes, mbTLS allows a client to include both middleboxes that are known a priori (e.g., configured by a user or declared via DNS, DHCP, or PDP/PDN), and middleboxes discovered during session establishment (on the default routing path). To inform the on-path middleboxes that the client supports mbTLS, the primary client hello includes a new middlebox support TLS extension. When the extension is seen, the middlebox forwards the client hello forward to the server and starts its own helper handshake with the client. In this assisted handshake, the middlebox takes the role of a server. An original primary client greeting doubles as a client greeting for the secondary handshake; the middlebox responds directly with the server hello 3 (to avoid extra round trips.) although in all calculations both the client and middlebox use PRF (client random | | middlebox random).

There may be multiple client side middleboxes. The secondary handshake messages are sent in encapsulation records, each middlebox having its own subchannel ID. Middleboxes wait until they see the primary server hello, buffer it, assign themselves the next available subchannel ID, use that ID to inject their own secondary server hello into the data stream, and finally forward the primary server hello. This process may ensure that each middlebox obtains a unique subchannel ID with minimal coordination.

With respect to server-side middleboxes, they can also be prearranged (e.g., via DNS) or discovered on-the-fly. However, it was found that the server side case is somewhat more involved. Unlike the client, the server does not declare mbTLS support using the middlebox support extension for two reasons: first, the TLS specification prohibits the server from including extensions in the server hello that the client is not included in the client hello; if the client also does not support mbTLS, the server-dependent middlebox support extensions will fail. Second, if the server-side middlebox waits to declare its presence until the server's server hello, the middlebox server handshake will complete after the primary handshake, extending the entire handshake process to more than two RTTs, even if possible.

Instead, the server-side middlebox optimistically declares itself with a new middlebox declaration message before knowing whether the server supports mbTLS. If not, it will ignore the middlebox declaration according to its TLS implementation, and the handshake will proceed without middleboxes, otherwise the handshake will fail. (in either case, the middlebox will cache the information without declaring itself to the server again.) if the handshake fails, the client needs to retry. The client software can interpret this as indicating that the server is running an expired TLS stack and retry using an older version of TLS, which is potentially dangerous. Furthermore, in practice, it is expected that the server-side middlebox and the server will typically be under the same administrative control, in which case the middlebox knows that the server supports mbTLS. Like the client-side middlebox, the server-side middlebox also assigns itself an unused subchannel ID when sending its middlebox declaration message.

With respect to attestation, when endpoints handshake with their middleboxes, they may choose to require credentials, SGX attestation, or both. The credential verification works in the same way as in normal TLS handshake, so only proof is focused on in the following. The goal is to convince the endpoint that only the middlebox application running in the enclave knows the TLS session key being established. The main idea for doing so is as follows: since the proof includes the identity of the code, and assuming that the code (application + mbTLS library) is checked and trusted, we can trust it if the code tells us that it generated key material for the handshake and did not derive it. The challenge becomes identifying "the handshake" -how does the endpoint ensure that the adversary did not replay the old proof from a different handshake?

This means that, in addition to the code identity, the attestation should also include some sort of handshake identifier (SGX allows the attestation to include 64 bytes of arbitrary user data). A good handshake identifier should (a) exist in each handshake (and thus not be a session ID that the server can choose to not support), (B) not typically repeat in future handshakes, and (C) not be forced to repeat by attackers (and thus not client-side randomised). Good candidates include anything based on the temporary key exchanged in the handshake. The pre-master secret or anything derived from it is a good choice, except that the middlebox knows it only after receiving the client key exchange from the endpoint. If waiting so long to send the proof, this delays the entire end-to-end handshake. Instead, the handshake identifier may be based only on the key material of the middlebox (one implementation uses a hash of the public temporary Diffie Hellman key of the middlebox). These are irrelevant for disclosure, as they are not repeated normally and an attacker cannot force them. This requires the server to use a key exchange method with the ephemeral public key (since the fixed public key in each handshake is the same), but in any event forward secrecy using the ephemeral public key is the best practice of the standard.

With respect to key distribution, after completion of the helper handshake with its middlebox, each endpoint will generate a symmetric key for each hop on its connection side. It assigns these keys to middleboxes in an encrypted middlebox key exchange record that is sent in the encapsulation record of the data stream as the auxiliary handshake message. The client server session key (KC-S) acts as a "bridge" between the last client side middlebox and the first server side middlebox.

Now, each of the security attributes P1-P4 will be re-introduced below to explain why mbTLS addresses these issues.

P1: and (6) data is kept secret. P1A: the adversary must not be able to read the session data. Decrypting session data requires access to one of the symmetric keys shown in fig. 3. The bridging key KC-S is established during the end-to-end client server TLS handshake in which the endpoints authenticate each other' S credentials. Next, this key and the remaining session keys (e.g., KC-C1, KC1-C0, etc.) are transmitted to the middlebox over the respective secondary TLS connections; importantly, these secondary connections terminate within the SGX enclave, which means that the MIP cannot access the keys of the secondary sessions in memory, so only the MS (and not the MIP) can learn the primary session key. Remote attestation proves to the endpoints of the middlebox that the MS is indeed operating in a secure environment.

P1B: the communication should be forward secret. The bridging key (KC-S) is the result of the (standard) primary TLS handshake, and thus, if the primary handshake is forward secure, so too. The other session keys (e.g., KC-C0, KC0-C1, etc.) are regenerated for each session and sent to the middlebox over the (standard) auxiliary TLS connection. Thus, if these secondary handshakes are forward-secure, so are the non-bridging session keys.

P1C: the viewer should not learn more from viewing ciphertext than if each hop were its own independent TLS connection. Since each hop uses its own independent encryption and MAC key, each hop operates effectively like its own TLS connection after the handshake.

In particular, this prevents an adversary from knowing whether the middlebox modified the records (although it can still see the size and time of each record, including whether the middlebox increased or decreased the size of the data).

P2: and (6) data authentication. An adversary must not modify, delete or inject session data. Each record carries a Message Authentication Code (MAC), which is a small label generated using a session key for identifying the data. If the MAC does not match the data, an unauthorized change may be detected. Since the session key is known only to the endpoint and each MS (see P1A), only these entities can modify or create records.

P3: and (4) entity authentication. P3A: each endpoint may verify whether the other endpoint is operated by the intended entity and whether each MS is operated by the intended MSP. First, the client and server may require each other's credentials at the time of the primary handshake (although typically client authentication occurs at the application layer).

The credentials bind the server's public key to its identity and this public key is used in the primary handshake to negotiate a shared bridging key, so after a successful handshake the client ensures that any data encrypted using this bridging key can only be decrypted by the intended service provider (or the middlebox it chooses to add to the session). Second, the endpoint may also require credentials from the middlebox. Since the private key corresponding to the credential is stored in an enclave that is inaccessible to the MIP (and that is remotely certified as being the case), the endpoint is assured that it is communicating with software provided and configured by the intended MSP.

P3B: each endpoint can verify that the other endpoint and each MS is running the expected software and that it is properly configured. Since our threat model assumes that the SP and all software running on its server are trusted, and in P3A, we verify that the server possesses the SP's private key, the client believes that the machine is properly configured with the intended application software. The same logic applies to the middlebox, with the additional step of remote attestation convincing the endpoint that the MS is securely isolated in a secure execution environment.

P4: path integrity. Each endpoint selects an order for its middleboxes. It is not possible for any other entity (including other endpoints or any middlebox) to cause middleboxes to process session data in a different order. This is because mbTLS uses a new key for each hop. Assume that an adversary cuts a record from the chain C1-C0 in fig. 3 and then attempts to insert it into the chain S0-S1 (thus skipping the middleboxes C0 and S0). The record will be encrypted and MAC using KC1-C0, but C1 wants to protect the data using KS1-S0, so the MAC check will fail and the record will be discarded. (Note that an endpoint may inject, delete, or modify data in any location of a portion of its path, as it knows all session keys on its side.)

In an embodiment, some other security attributes of the exemplary mbTLS protocol are as follows.

End point isolation: an endpoint can only verify its middlebox and not middleboxes added by other endpoints. In fact, the end point may not even know the middlebox on the other side. This follows the way the keys are generated and distributed. It makes sense to check a certificate or proof only if the public key in the certificate is used for key exchange (then you believe that only the entity associated with that public key can decrypt what you send using the new symmetric key). Since the endpoints do not take the KE with the middlebox on the other side, they cannot authenticate each other even though credentials/proofs are exchanged. This limitation is reasonable; since the endpoints presumably trust each other, or otherwise do not communicate with each other, it is natural that the other endpoint can be trusted to properly authenticate any middleboxes it adds to the session.

Path flexibility: the client-side and server-side middleboxes cannot be interleaved. To support this, the endpoints will need to coordinate to generate/distribute keys to the interleaved portions of the paths. This means that the endpoints need extra work and that the endpoints also need to know (some) middleboxes of each other. This also means that one endpoint can modify/inject traffic after the middleboxes of the other endpoint, which may be a security issue if one of these middleboxes performs some filtering or cleaning.

Unreliable MSP: mbTLS can provide guarantees even if the service provider is not trusted. In our threat model, both SP and MSP are trusted. However, even in the more pessimistic threat model where SPs and MSPs are not trusted, remote attestation may still provide P1, P2, P3, and P4 because attestation may identify code running in a secure environment. This relies on two large assumptions: one, the software is known to be "well-behaved" (e.g., session data is not exported outside of the bounding region); second, the client knows the hash of the "known good" software. For example, if the software is open sourced and has been publicly authenticated to keep session data secret, the client may connect to an untrusted Web proxy even if the client does not trust the company operating the service nor the infrastructure running it.

Middle box poisoning: using mbTLS with a client side middlebox that preserves global state is not secure. Since the endpoint knows the keys of each hop on one side of its connection, a malicious client can read and/or modify data on any of these hops without knowing its middlebox. This is a problem when the middlebox shares state across multiple clients (e.g., Web caches). A client having access to a link between the cache and the server may request a page, discard the server's response and inject its own response, thereby poisoning other clients' caches. One possible solution is to change the handshake protocol so that the middlebox establishes keys with its neighbors, rather than the endpoint generating and distributing session keys; this means that each party only knows the key(s) for the hop(s) adjacent to it. The drawback is that the client loses the ability to authenticate the server's credentials and establish a session key using the public key in the credentials. Instead, the client must trust its middlebox to authenticate the server. This may be reasonable because SGX proves that the client should be convinced that the middlebox is running the software that will do so, but embodiments do not employ this approach in mbTLS, because relying on a password may be preferable where possible, because relying on SGX also means relying on the correctness of the protocol library code.

Bypassing the filter intermediate box: at first sight, the fact that an endpoint knows all session keys on its side could cause another attack: if the middlebox performs some filtering function (e.g., a virus scanner, parental filter, or data leak detector authorized by an administrator), this indicates that the endpoint has a key that can access the incoming data before filtering the incoming data or subsequently injecting outgoing data. However, if the endpoint is able to read or write data on the "other side" of the filter (i.e., physically retrieve/inject packets from/into the network beyond the middlebox), the filter is not useful at the outset, so mbTLS does not enable new attacks.

Some other features of the exemplary embodiments of mbTLS are now discussed.

And (3) session recovery: in an embodiment, mbTLS fully supports ID-based and ticket-based session recovery.

Each sub-handshake (primary handshake and secondary handshake) only performs a standard abbreviated handshake; the only slight difference is that the middlebox's session ticket should contain the session key for the end-to-end session (except for the endpoint middlebox session key). No new proof is required because only the bounding region knows the key required to decrypt the session ticket. The client that wishes to resume the session stores the session ID or ticket for the server and each client-side middlebox. If the server also uses mbTLS, it can cache the session ID/ticket for its middlebox, or can ask the client to cache it and send it into the client hello.

TLS 1.3: this greatly changes the TLS handshake, shortening it from two round trips to one, compared to TLS 1.2 and earlier versions. With minor modifications, the handshake of mbTLS can accommodate TLS 1.3. There is a warning: when there is a client-side middlebox, the data sent by the server in the same flight (flight) as the server completes may be delayed, in the worst case, one round trip may be delayed; however, in most cases, the client sends the application data first; in these cases, there is no problem.

mbTLS and SGX: the latter constitutes a limitation for middlebox developers. Since only the CPU is trusted, interaction with the outside world is not allowed by default (in particular, since the OS is not trusted, system calls are not allowed). Intel's SDK implements a subset of libc, but developers must add the rest of the functionality by either providing custom implementations within the enclave or developing an explicit enclave interface to get the enclave thread out of the enclave, execute untrusted code, and return the results to the enclave.

There are different ways to balance two competing factors: the size of the trusted computing base (i.e., TCB) (the more code in the enclave, the more likely it contains an available error) and the size of the enclave interface (every call outside of the enclave provides an attacker with the opportunity to inject malicious input). One extreme case is to place the entire library OS within the enclave, resulting in a large TCB and a small enclave interface. The opposite extreme is that nothing is implemented in the bounding volume and goes outside for each libc call (small TCB, large interface). Intermediate standpoints may also be employed.

Network I/O: when a system call needs to be made to a bounding region thread, there are two high-level strategies: (1) copying the parameters into an unprotected memory, exiting the bounding region, executing a call, then re-entering the bounding region, and copying the result back to the bounding region memory; or (2) place the request in a shared queue, another thread outside the enclave executes the call, passing the result back to the enclave via a response queue. These are synchronous and asynchronous system calls, respectively.

It should be understood that the above embodiments have been described by way of example only.

More generally, according to one aspect disclosed herein, there is provided a method of communicating over a network between a first endpoint and a second endpoint, the first endpoint being a client device or a server, and the second endpoint being the other of the client device and the server; the method comprises the following steps: establishing a first secure transport layer channel between the first endpoint and the second endpoint, the first secure transport layer channel being defined by a first cryptographic key required to access content of a service sent through the first secure transport layer channel; establishing a second secure transport layer channel between the first endpoint and the middlebox, the first endpoint to delegate processing of traffic sent over the first secure transport layer channel to the middlebox, the second secure transport layer channel defined by a second cryptographic key required to access content sent over the second secure transport layer channel; the first endpoint authenticates the middleboxes via respective second secure transport layer channels and shares the first encryption key with the middleboxes via the second secure transport layer channels on condition of the authentication; and causing traffic sent over the tunnel to be routed via the middlebox; the method thus enables the middlebox to process the content of the traffic sent over the first secure transport layer channel in clear text using the first cryptographic key.

In an embodiment, each of the first and second transport layer lanes may be a TLS lane.

In an embodiment, the verification may include confirming that the middlebox is provided by the prospective party.

In an embodiment, the verifying may comprise authenticating that the middlebox is provided by a trusted party.

In an embodiment, the confirming may include confirming that the middlebox provides the desired service.

In an embodiment, the middlebox may comprise at least one of: a virus scanner, a child security filter, an intrusion detector, a compression agent, an audio or video transcoder, an HTTP agent, an application layer load balancer, and/or a cache.

In an embodiment, traffic may be caused to be routed via the middlebox by providing the second endpoint with the IP address or domain name of the middlebox as the contact address of the first endpoint, or by configuring the network to redirect traffic addressed to the first endpoint to the middlebox.

In an embodiment, the method may comprise the client and at least one further client communicating with the server via the first secure transport layer channel as part of the same multiparty communication session.

In an embodiment, the middlebox may operate within a secure enclave of a network device on which the middlebox is implemented.

In an embodiment, the first endpoint may be a client and the second endpoint may be a server.

In an embodiment, the establishment of the first secure transport layer channel may include the client sending a message to the server via the middlebox, wherein the message may include a TLS extension configured to cause the middlebox to initiate a handshake with the client to perform the above-described establishment of the second secure transport layer channel.

In an alternative embodiment, the first endpoint may be a server and the second endpoint may be a client.

In an embodiment, the method may comprise: for each respective one of the first and second endpoints, establishing a different respective second secure transport layer channel between the respective endpoint and the respective middlebox, the respective endpoint to delegate processing of traffic sent over the first secure transport layer channel to the respective middlebox, each second secure transport layer channel defined by a different respective second cryptographic key required to access content sent over the respective second secure transport layer channel; each of the first and second endpoints authenticating a respective middlebox of the endpoint via a respective second secure transport layer channel and sharing a first encryption key with the respective middlebox via the respective second secure transport layer channel on condition of the authentication; and causing traffic sent over the tunnel to be routed via middleboxes of both the first endpoint and the second endpoint; the method thus enables middleboxes of both endpoints to process content of traffic sent over the first channel using the first cryptographic key.

In an embodiment, a chain of a plurality of middleboxes may be included in a first secure transport layer channel, each middlebox being introduced using a different respective second secure transport layer channel according to a respective instance of the above method.

In an embodiment, the chain may comprise a plurality of middleboxes of the first endpoint, each middlebox being introduced using a different respective second secure transport layer tunnel according to a respective instance of the method.

In an embodiment, wherein the chain may comprise a plurality of middleboxes of the second endpoint, each middlebox being introduced using a different respective second secure transport layer lane according to a respective instance of the method.

In an embodiment, the method may include forcing an order in which the middleboxes receive traffic by: traffic is sent using different respective per-hop encryption keys to encrypt traffic at each hop between an endpoint and a middlebox and each hop between middleboxes.

In an embodiment, the network may include the internet.

According to another aspect disclosed herein, there is provided a computer program product embodied on a computer readable storage device and configured so as when run on a computer system to perform the method of any of the preceding embodiments.

According to another aspect disclosed herein, there is provided a computer system comprising at least a first endpoint programmed to perform the method of any of the preceding embodiments.

Other variations will become apparent to those skilled in the art once given the disclosure herein. The scope of the present disclosure is not limited by the above-described embodiments, but only by the appended claims.

Claims

1. A method of communicating over a network between a first endpoint and a second endpoint, the first endpoint being a client device or a server and the second endpoint being the other of the client device and the server; the method comprises the following steps:

establishing a first secure transport layer channel between the first endpoint and the second endpoint, the first secure transport layer channel defined by a first cryptographic key required to access content of traffic sent over the first secure transport layer channel;

establishing a second secure transport layer tunnel between the first endpoint and a first middlebox, the first endpoint to delegate processing of the traffic sent over the first secure transport layer tunnel to the first middlebox, the second secure transport layer tunnel defined by a second cryptographic key required to access content sent over the second secure transport layer tunnel;

the first endpoint authenticates the first middlebox via the respective second secure transport layer channel and shares the first cryptographic key with the first middlebox via the second secure transport layer channel on condition of the authentication;

cause the traffic sent over the second secure transport layer tunnel to be routed via the first middlebox of the first endpoint and a second middlebox associated with the second endpoint;

the method thereby enables the first middlebox to process the content of the traffic sent over the first secure transport layer channel in clear text using the first cryptographic key.

2. The method of claim 1, wherein each of the first and second secure transport layer lanes is a TLS lane.

3. The method of claim 1, wherein the verifying comprises confirming that the first middlebox was provided by an intended party.

4. The method of claim 1, wherein the verifying comprises authenticating that the first middlebox is provided by a trusted party.

5. The method of claim 1, wherein the verifying comprises confirming that the first middlebox provides the intended service.

6. The method of claim 1, wherein the first middlebox comprises one of:

a virus scanner for scanning the virus to obtain the virus,

a child-resistant filter for a vehicle,

intrusion detector

The compression agent is a set of instructions that, when executed,

an audio or video transcoder may be provided for transcoding audio or video data,

the HTTP proxy is a proxy for the HTTP session,

an application level load balancer, and/or

And (7) caching.

7. A method according to claim 1, wherein the traffic is caused to be routed via the first middlebox by providing the second endpoint with an IP address or a domain name of the first middlebox as a contact address for the first endpoint, or by configuring the network to redirect traffic addressed to the first endpoint to the first middlebox.

8. The method of claim 1, comprising the client and at least one additional client communicating with the server via the first secure transport layer channel as part of a same multiparty communication session.

9. The method of claim 1, wherein the first middlebox operates within a security enclave of a network device on which the first middlebox is implemented.

10. The method of claim 1, wherein the first endpoint is the client and the second endpoint is the server.

11. The method of claim 10, wherein the establishment of the first secure transport layer channel comprises the client sending a message to the server via the first middlebox, and wherein the message comprises a TLS extension configured to cause the first middlebox to begin a handshake with the client to perform the establishment of the second secure transport layer channel.

12. The method of claim 1, wherein the first endpoint is the server and the second endpoint is the client.

13. The method of claim 1, comprising:

for each respective one of the first and second endpoints, establishing a different respective second secure transport layer tunnel between the respective endpoint and a respective middlebox, the respective endpoint to delegate processing of the traffic sent over the first secure transport layer tunnel to the respective middlebox, each second secure transport layer tunnel defined by a different respective second cryptographic key required to access content sent over the respective second secure transport layer tunnel; and

each of the first and second endpoints authenticating a respective middlebox of the endpoint via the respective second secure transport layer channel and sharing the first cryptographic key with the respective middlebox via the respective second secure transport layer channel on a condition of the authentication; and

the method thereby enables the middleboxes of both endpoints to process the content of the traffic sent over the first secure transport layer channel using the first cryptographic key.

14. The method of claim 1, wherein a chain of a plurality of middleboxes is included in the first secure transport layer lane, each middlebox being introduced using a different respective second secure transport layer lane.

15. The method of claim 14, wherein the chain comprises a plurality of middleboxes of the first endpoint, each middlebox introduced using a different respective second secure transport layer lane according to a respective instance of the method of any of claims 1 to 12.

16. The method of claim 14, wherein the chain includes additional middleboxes of the second endpoint, each middlebox introduced using a different respective second secure transport layer lane according to a respective instance of the method of claim 13.

17. The method of claim 14, comprising forcing an order in which the middleboxes receive the traffic by:

the traffic is sent using different respective per-hop encryption keys to encrypt the traffic at each hop between an endpoint and a middlebox and each hop between middleboxes.

18. The method of claim 1, wherein the network comprises the internet.

19. A computer-readable storage device storing instructions executable by one or more processors to perform operations comprising:

establishing a first secure transport layer channel between a first endpoint and a second endpoint, the first secure transport layer channel defined by a first cryptographic key required to access content of traffic sent over the first secure transport layer channel;

the first endpoint authenticates the first middlebox via the respective second secure transport layer channel and shares the first key with the first middlebox via the second secure transport layer channel on condition of the authentication; and

thereby enabling the first middlebox to process the content of the traffic sent over the first secure transport layer channel in clear text using the first cryptographic key.

20. A computer system including at least a first endpoint programmed to perform operations comprising: