A Survey of Privacy-Preserving Techniques for Encrypted Traffic Inspection over Network Middleboxes

Two common techniques widely used in the industry (in particular to deploy MBs at enterprises (Broadcom, 2020a)) to inspect encrypted traffic is (1) the split-TLS technique, which is also known as a man-in-the-middle (MitM) approach, and (2) key sharing and delegation.

The difficulty of administering the myriad devices (Sherry, 2016) has fuelled the development of new middlebox services that departs from the traditional on-premise enterprise middlebox setting. The emerging trend is to outsource MB functionality to cloud-based services, commonly known as MB as a services. Figure 3 illustrates a general architecture of outsourced MBs. It relieves an enterprise from needing to purchase related hardware, install (both software and hardware), configure, operate and maintain middleboxes. Outsourcing of MBs therefore reduces, or virtually removes, operational costs, and thereby enables the enterprise to focus on its key business. However, outsourcing MBs to a third-party provider exacerbates privacy concern when compared to the on-premise enterprise setting, since now, data that are normally inspected internally, has to be routed to the provider for processing. Therefore, many research works have proposed to secure MB services in the cloud, including privacy-preserving inspections on encrypted traffic. In addition to this, cloud-based MB must provide low-latency operations since traffic has to be rerouted to the cloud. An example solution that enables privacy-preserving inspections with low-latency is Embark, proposed by Lan et al. (Lan et al., 2016). Low-latency is achieved through an architecture known as Appliance for Outsourcing MBs (APLOMB) introduced in (Sherry et al., 2012). The general idea is to create a tokenised encrypted traffic along the TLS traffic. Searchable encryption method is used to match the tokenised encrypted traffic with the encrypted rulesets at the MB, all of which are setup under the APLOMB architecture.

In addition, many more recent outsourced-based MB proposals develop techniques that are based on secure enclave (i.e. Intel SGX). These include, for example, SafeBricks (Poddar et al., 2018), ShieldBox (Trach et al., 2018) and SPlitBox (Asghar et al., 2016). The general idea of these techniques is to perform packet inspections in the secure enclave so that the cloud provider does not learn the content of the encrypted packets. We discuss in more details these proposals in Section 4.5.

In essence, one is looking for an optimal solution between two extremes, (1) of not being able to perform in-depth inspection due to the traffic being encrypted; and (2) inspection of decrypted traffic using MitM and key sharing approach. Many solutions have been proposed in the recent years to address this issue. We categorise them into four categories based on the techniques they used. We discuss these techniques in Section 4. We also include the MitM approach as a fifth category in the beginning of the discussion for comparisons. We believe the different designs and properties of the growing list of proposals should be studied in order to clearly characterise their advantages and limitations. Our study provides insights on security assurance and performance over different use case scenarios, as well as appeals of the techniques to real-world deployment:

• •

  We define a general architecture, identify use cases and their constraints (Section 2). We define three system models under the prescribed architecture that illustrates the flow of network traffic through the MBs. We term them client-oriented, server-oriented and client-server accountable settings. Our models provide a more fine-grained categorisation and enhancement on the one-sided and two-sided definition in the ETSI standard (ETSI, 2018a, 2020).

• •

  We define a trust model encompassing the different actors in a network system that contains MBs (Section 3). It provides a foundation on which security model can be defined clearly. We state trust assumptions based on the architecture and settings that we defined, and define threats and security requirements based on these assumptions.

• •

  We classify existing privacy-preserving techniques into two types, passive and active. Here, passive inspection encompasses techniques that analyse encrypted traffic without decryption or, modify the traffic of the underlying protocol. Active inspection analyses the traffic by decryption or modification of the underlying protocol. These techniques are categorised as access control, searchable encryption, machine learning and trusted hardware, as well as the MitM approach for comparison (Section 4). We compare the main features, advantages and pitfalls of each category.

• •

  We identify the research challenges and discuss the potential research directions (Section 5). We examine the current security model and analyse the existing attacks. This leads us to believe that some of the existing proposals require further improvements for industry adoptions. For example, a protocol that utilises searchable encryption mechanisms will need to be analysed against well-established notion of information leakages in the field. We give insights, especially on the reason that existing MitM approaches, with combination of a configurable policy engine, are still preferred in the industries.

As a side note, for practical and efficient deployment with optimal inspection capability, it seems decryption of the encrypted payload is one of the better approaches. What remains to be studied is how much encrypted data should be decrypted and revealed to the MBs in order to preserve privacy. It is, we believe, based on this fact that a new MB security protocol (MSP) was proposed and is undergoing standardisation efforts (ETSI, 2018b). It may also be the case that trusted hardware approaches, such as using Intel SGX, are being developed where encrypted traffics are decrypted in a way protected by the hardware so that MBs have no access to the decrypted data. The techniques and challenges are discussed in details in Section 4 and Section 5.

A short survey related to the issue that we studied was provided by Wang et al. in (Wang et al., 2018). It studied the various mechanisms for secure outsourcing of MBs in a general manner, focusing solely on cloud-based MB. Our work complements theirs in a way that we provide broader investigation that also covers non-outsourced specific literature, hence our definition of different system models and use cases. The European Union Agency for Cybersecurity (ENISA) also published a survey on encrypted traffic analysis (Dimou et al., 2019). The survey describes in detail in particular $6$ key use cases (i.e. application identification, network analytics, user information identification, detection of encrypted malware, file/device/website/location fingerprinting and DNS tunnelling detection) and techniques based on machine learning. Most recently, Carnavalet and Van Oorschot (de Carné de Carnavalet and van Oorschot, 2020) presented a comprehensive survey on TLS interception mechanisms and motivations, focusing on practical considerations between the use cases and incentives of the stakeholders. They listed $19$ use cases where access to unencrypted traffic is crucial, in order to understand the motivation of the various proposals in inspecting encrypted traffic. One of the key insights from their survey is the identification of gaps between the proposed mechanisms, use cases and incentives. Extensive details on the various MitM and key sharing techniques were studied and compared. Here, our focus is on privacy-preserving techniques with compilations, categorisation of the state-of-the-arts, in-depth examinations and comparisons of these various techniques, which complement these recent surveys.

We first describe a typical client-oriented setting that is common in an enterprise network. Figure 1 illustrates a high-level model of the setting, where the goal of the middleboxes is to protect the clilent(s), and therefore are often placed closer to the client(s). Here, a client connects to a server using a secure channel. The encrypted traffic flows, both inbound and outbound, are routed through a host of MBs that inspect the traffic. MBs receive in-bound and out-bound traffic from multiple clients and server endpoints. It normally involves installing specific software, or modification on the connections at the client device in order to enable the MBs to perform the inspections.

A server-oriented MB is also common in an enterprise network (Figure 2). This is to secure the servers hosted in an enterprise, for example web servers. A server in an enterprise establishes secure channels with requesting clients that are often outside the enterprise network, in particular, the Internet. The encrypted traffic to/from the server endpoint are routed through a host of MBs at the server-side (or outsourced to a third-party service provider) that inspect the encrypted traffic. The main technical difference in this setting compared to the previous one is that connections are all requested by clients, and in general the purpose is to secure one specific server. Server-oriented MBs are developed to protect servers, such as web servers, database servers, and so on. A typical example is a web application firewall that inspects incoming HTTP requests to a web server. As the web server itself has moved to the cloud since a few years now, having server-oriented MBs in the cloud is not uncommon these days (Akamai, 2020).

In terms of system models, many of the schemes cater for client-oriented and server-oriented setup (C-O and S-O) as discussed in Section 2. These schemes can be straightforwardly deploy on either the client enterprise network, or at the server (e.g. web application provider). Schemes based on the searchable encryption (SE) technique such as BlindBox (Sherry et al., 2015) (c.f. second row of Table 1), however, further assumes the existence of a (semi-)honest rule generator that provides rulesets to MB. There are also schemes that cater for client-server accountability (c.f. row 3), in which both endpoints have visibility of the MBs deployed and are able to authenticate these MBs. On the other hand, EndBox (Goltzsche et al., 2018) and SplitBox (Asghar et al., 2016) focus on client-oriented model, with EndBox providing stronger security assurance where client can be malicious. In summary, there are two main trust assumptions considered by the existing schemes:

• •

  Trust Assumption (TA) I: Middlebox (or MB provider) is (semi-)honest and one of the endpoints (i.e. client or server) must be honest. Schemes based on this assumption in general deploy MitM, SE, AC, ML techniques.

• •

  Trust Assumption (TA) II: Cloud service provider and one of the endpoints (i.e. client or server) can be malicious. Alternatively, both endpoints can be malicious, but the MB provider is honest. Schemes based on this assumption in general deploy TH techniques.

The discussed schemes cover only assumptions that relate to the perceived use cases and scenarios. Certainly, there are obvious trust combinations that are not feasible, for example:

• •

  In the case whereby the client and the server are honest then MBs would be redundant. The client and the server communicates directly through encrypted traffic. Their main security requirements would be to prevent outsiders from listening or modifying their communication.

• •

  It is obvious that if all three entities are malicious then there is nothing to protect from.

New trust assumptions may be required due to new requirements and scenarios that were not addressed by existing studies. Here we give an example, on the possibility of collusion between the service provider hosting the MBs and one of the endpoints, when we consider the outsourced MB scenario.

The main goal of schemes advocating privacy-preserving inspection of encrypted traffic is to protect data privacy of the encrypted network traffic, while maintaining similar utility of inspection on plain data traffic. The main security requirement is thus to ensure data privacy, in such a way that only the endpoints know the underlying message of the encrypted traffic while the entity that performs the inspection does not learn any information it is not allowed to learn. Depending on schemes, the information that is learned by the inspecting entity can vary. For instance, in a Man-in-the-Middle (MiTM) approach that decrypts the network traffic is able to learn all the information if it chooses to.

The Man-in-the-Middle (MitM) technique is commonly deployed in enterpise solutions for encrypted traffic analysis, for example as presented in (de Carné de Carnavalet and Mannan, 2016; Durumeric et al., 2017; Waked et al., 2018; Broadcom, 2020a). There are also widely available open source tools such as MitMProxy (Cortesi et al., 2018) and SSLSplit (Roethlisberger and contributors, 2018). MitM uses active inspection. The main idea is to enable the middlebox provider to act as the server endpoint so that it can decrypt, inspect and then re-encrypt network traffic of the client. The traffic is then forwarded to the server endpoint. In general, for a client-oriented model (Figure 1), this is achieved by first installing a certificate of the MB provider in the client device (e.g. trusted CA store for browsers). When a client initiates a secure session with the server, the MB provider hosting the MBs intercepts the traffic and forges a certificate using the server credentials. In this way the service provider masquerades as the server, setups a session with the client, decrypts and inspects the data. After inspection, the service provider initiates on behalf of the client a secure session with the server. In an enterprise network, installation of the root certificate on every client device can be performed by the network administrator. The inspection can be performed by MBs hosted locally in the premise of enterprise network or through outsourced MB service.

In the server-oriented model (Figure 2), similar approach can be deployed. Nevertheless, if the server subscribes to a content delivery network (CDN), the conventional approach is to pass the server certificate, together with the secret key to the CDN provider (Bhargavan et al., 2018). In more recent approach, the secret key is not given, but a program interface is provided to the CDN provider to have access to the key. There are various key sharing and content delegation approaches as discussed in (de Carné de Carnavalet and van Oorschot, 2020). Durumeric et al. (Durumeric et al., 2017) listed some commercial solutions and explored the security issues of these solutions. They found that nearly all the solutions they investigated have reduced connection security and five of the solutions contain severe vulnerabilities. The technique can be coupled with a policy engine, in which a whitelist of websites can be created by an administrator so that these websites will not be inspected by the MBs (Symantec, 2018). This serves as an approach to mitigate privacy concerns, especially for financial transactions such as online banking and purchases. Nevertheless, the administrator has to be fully trusted to configure the policy engine correctly and honestly. Figure 4 illustrates the MitM settings for client-oriented MB model and the server-oriented MB model (for the use cases involving content delivery network). Here, we use the outsourced MB architecture since it can be used for all three system models that we have presented. Furthermore, it is the emerging direction in both industry and research.

In the followings we discuss the main advantages and limitations of the MitM approach.

• •

  Advantages:

  • –

    Changes to TLS: The technique can be deployed straightforwardly without changing the underlying protocol (e.g. TLS) since the service provider sits in the middle and manages secure sessions between the client-service provider and service provider-server.

  • –

    Functionality: The MB decrypts the encrypted traffic. This means after the data is decrypted, it is able to run similar functions as in the case where the traffic is not encrypted. Hence it maintains full functionality as if the traffic is not encrypted.

  • –

    Performance: It is relatively efficient compared to the other techniques that require additional cryptographic computations, machine learning operations or computation in the trusted hardware. As most modern CPUs support AES-NI instructions, the time to encrypt or decrypt a block of bits take 3$\mu$s per packet of 1500 bytes. According to (Sherry et al., 2015), the vanilla TLS setup phase takes 73ms on a 20 Mbps throughput network. Certainly, it incurs higher overhead compared to inspection on plain data since the MB is required to decrypt and re-encrypt the traffic. For commercial solutions, the middlebox latency can be less than 40$\mu$s, and depending on the device variant, TLS inspection throughput ranges from 250Mbps-10Gbps. These are based on publicly available information from the enterprises that we surveyed (Broadcom, 2020b; Gigamon, 2020).

• •

  Limitations:

  • –

    Security: The main issue in MitM is that the MB provider learns the content of the traffic and this may cause privacy concern, for example, for an enterprise that subscribes to an outsourced MB service. Another issue is that we must trust the MB providers to implement the underlying protocol correctly and uses the up-to-date version of the protocol. As discussed in Section 1 and Section 1.1, weaknesses were found in some of the solutions due to implementation of the TLS protocol using old versions or deprecated ciphers. In addition to this the gateway (or the service provider) becomes highly valuable target for attacker and the administrator must be fully trusted.

A second technique that was proposed is to detect malicious traffic via token matching without decrypting the underlying encrypted traffic. We categorise the technique as searchable encryption (SE) because the main idea is to use searchable encryption scheme to map between encrypted keywords and the encrypted rulesets. SE uses active inspection. Sherry et al. (Sherry et al., 2015) introduced BlindBox, the first privacy-preserving deep packet inspection scheme using SE technique. In BlindBox, a client initiates a TLS session with the server, as well as another connection for token matching. Both the connections route through the MB. The general idea is that the MB hosts rulesets that are encrypted using a key derived from the session key of the TLS session. The client then tokenizes and encrypts its message using the same key, and transmits the tokenized traffic through the second connection. The MB then try to match the tokenized traffic with the encrypted rulesets. If there is a match, the traffic is considered malicious and blocked. Figure 5 shows a general setting for SE-based schemes.

The MB should not know the key used to encrypt the rulesets and to generate the token since if this is the case, it is able to decrypt all tokens in the tokenized traffic and learns the message. This is akin to having access to the plaintext. BlindBox mitigates this issue by performing encryption of the rulesets through garbled circuit and oblivious transfer for every session. This means BlindBox is computationally expensive, at least in the initial handshake of the TLS protocol. Furthermore, the scheme must be able to verify that the tokenized traffic is identical to the TLS session. This is because the client can send malicious message through the tokenized traffic and a benign one through the TLS session, thus defeating the inspection. Here, verification is performed by the server. The server receives data from both connections, and since the server has the session key, it can decrypt the TLS traffic as well as generate the token to verify that the content from both connections are the same. However, inspection based on token matching of the encrypted traffic is rather limited as it would not be able to cater for regular expression inspection. BlindBox proposed a probable cause privacy mechanism to mitigate this issue by allowing decryption of the underlying traffic based on the session key (without revealing the session key).

The BlindBox mechanism is extended to the setting of outsourced MB by Lan et al. (Lan et al., 2016). The scheme is termed Embark. It enhanced the token matching technique to include prefix matching, as well as different searchable encryption functionalities catering specifically for different MB services such as IP firewall, NAT, HTTP Proxy, data exfiltration and intrusion detection. It also proposed a different, but practical setting. In order to mitigate the computation overhead of BlindBox, Canard et al. (Canard et al., 2017) proposed BlindIDS. It uses a different approach in that pairing-based public key operation is deployed for token matching and for the client to communicate with the server through the MB. This also means existing TLS protocol must be replaced with their scheme. Another scheme that uses public key operation is a scheme termed SPABox by Fan et al. (Fan et al., 2017). In contrast to BlindIDS, the public key operation based on homomorphic encryption is used only to perform machine learning based inspection. The scheme also uses Diffie-Hellman based oblivious pseudo-random function for encrypted rule preparation, which is performed interactively between the MB and the server. For regular expression matching, the scheme deploys a variant of garbled circuit that is more efficient than the general construction. Yuan et al. (Yuan et al., 2016) proposed a scheme that is more efficient than BlindBox using a high-performance encrypted filter. Their scheme also extends the token matching mechanism of BlindBox to work for multi-condition rulesets. Though efficient, their scheme requires the server to first register with the administration service of the enterprise hosting the client. Only then the client may initiate the TLS session with the server. The performance of BlindBox is improved significantly by Ning et al. (Ning et al., 2019a) in their scheme termed as PrivDPI. The computation time during the initial handshake was greatly reduced when compared to BlindBox, and a reusable obfuscation mechanism generates intermediate values that can be reused across subsequent sessions for repeated tokens, which could further speedup token encryption. The efficiency of PrivDPI is further improved in a scheme called Pine, which is also proposed by Ning et al. (Ning et al., 2020). In addition, Pine enables rule hiding as middlebox services migrate to third-party cloud setting, rule privacy may be a concern. Ren et al. proposed EV-DPI (Ren et al., 2020). EV-DPI is a two-layered architecture design and is deployed over two non-colluding servers to outsource the middlebox. First layer filters out legitimate packets using encoded bloom filters. The second layer supports exact rule matching for packet inspection using conjunctive searchable encryption scheme proposed by lai et al. (Lai et al., 2018). The scheme allows inspection results to be efficiently verified using cuckoo hashing. A related scheme that uses a different approach under the cloud setting for NFV is SplitBox proposed by Asghar et al. (Asghar et al., 2016). They suggest the use of two cloud systems where every rule in the rulesets is XOR with a random string and split into many blocks to the various MBs resided in one of the cloud system. Both cloud systems collaboratively compute the blocks in order to perform inspection on the traffic.

• •

  Advantages:

  • –

    Changes to TLS: The main advantage of this technique is that modification on the underlying protocol (i.e. SSL/TLS) is not required (except for BlindIDS which proposes a new protocol that may replace SSL/TLS), yet it allows privacy-preserving inspection. Some of the constructions can also be efficient in specific scenarios. As an example, assuming a trusted rule generator (which is the case for a few of the schemes stated in Table 1), encryption of the rulesets can be performed efficiently if it can be assumed that the rulesets are encrypted by the client or another trusted third party and passed to the MB. Inspections require only comparing the rulesets with the tokenized data, and does not require decryption and re-encryption as in the MitM approach.

  • –

    Security: It provides better security guarantee than the MitM technique and the access control technique (Section 4.3) since the inspection is performed without decrypting the encrypted traffic. Hence the MB and the service provider would not be able to learn the content of the traffic, except for those tokens that match the rules. An exception is that there are schemes such as BlindBox, PrivDPI and EV-DPI which follows probable cause privacy where the middlebox gets to see the decrypted traffic if and only if the flow is deemed to be suspicious.

• •

  Limitations:

  • –

    Functionality: The main drawback is that utility can be limited due to simple mapping of encrypted tokens and rules. This may not be sufficient especially for inspection requiring regular expression. Some of the schemes address this problem by allowing the MB to decrypt the traffic when there is a match. Alternatively, compute-intensive primitive such as homomorphic encryption is used to enable expressive inspection. Furthermore, in may cases a separate channel is required to communicate the tokenized traffic, as shown in Figure 5. For the MB to be able to inspect inbound and outbound traffic, both endpoints, meaning the client and the server must have the scheme installed. This is in contrast to the MitM technique (as well as the machine learning and trusted hardware approach, which we will discuss in the subsequent sections).

  • –

    Performance: At the client, there is the compute-intensive overhead due to the additional operations of tokenizing and encrypting the data stream compared to pure TLS connection, and the MitM technique. At the MB, however, only matching is performed. Hence, generally the setup phase for SE techniques contribute more to the overall performance delay than the inspection phase. For BlindBox, the setup time is 97s for 3000 rules and 33$\mu$s for inspecting 1 packet with 3000 rules. BlindIDS limits the setup time to 73ms but increases the inspection time to 74s for same setting. By replacing garbled circuits with reusable exponentiations in group, PrivDPI prepares 3000 encrypted rules in 0.64s which is 288 times more efficient than BlindBox. PrivDPI also reduces the bandwidth usage(from GBs to KB) by replacing the garbled tables with reusable obfuscated rules. Pine further improves the one-round connection time of PrivDPI with hash operations. For SPABox, lack of hardware support for operations results in slower(9 times than BlindBox) performance for encrypting a token at setup phase. However, SPABox saves on average 29.5% time in inspection phase compared to BlindBox due to hashing technique.

This is a technique that advocates client and server accountability, where the client and the server are aware of all the MBs deployed in between the two of them. Also, they are given the ability to authenticate and assign access rights to these MBs. Hence the term access control (AC). AC uses active inspection. Figure 6 illustrates a typical setting for AC-based schemes.

Naylor et al. (Naylor et al., 2015) introduced a scheme of this type, termed mcTLS. It modifies existing TLS protocol to allow the client, the MBs and the server to establish secure and authenticated channel, and exchange read and write secret keys in addition to the session key. The mcTLS protocol partitioned the network traffic according to a least privilege MB access policy. Each MB is assigned a read and/or a write key. This involves providing different level of access control to read and/or write on the encrypted traffic. The encrypted traffic is partition so that some portions of the payloads can be decrypted. The benefit of such a technique is that there is a fine-grained control and flexibility in preserving privacy on portions of the data that should not be decrypted. In other words, mcTLS only partially preserve privacy of the underlying payload, since a MB has the keys to decrypt the portions of the traffic where authorisation is given.

The main issue with mcTLS is that it is a new protocol. For adoptions, existing TLS protocol that is widely used must all be replaced with mcTLS. Acknowledging this issue, Naylor et al. (Naylor et al., 2017) further proposed another scheme, termed mbTLS. It does not change the underlying TLS protocol, except in introducing extensions that can be readily adopted using existing protocol. It is designed to be scalable for implementation in the outsourced MB setting. In more details, mbTLS considers the problem of outsourcing MB functions to multiple third parties. For example, there maybe multiple MBs contracted out by a client, in addition there can also exist a set of MBs for the server, all residing in untrusted cloud environment. They discussed several important properties desired in such a scenario, and designed mbTLS to meet some of such important properties. In mbTLS, a different TLS session exists between every two entity (client, MB, server), with each session operating using its own secret key. This design is such that, the client is only aware of the client-side MBs and none on the server side; and vice versa. The MBs in the cloud uses Intel SGX to protect the data and keys from the cloud infrastructure provider. The initial control messages between the different entities are multiplexed over a single TCP connection, thus adding no additional round trip time. In mbTLS, MBs are able to view the entire payload, as the sessions are handed over to participating entities.

Bhargavan et al. (Bhargavan et al., 2018) demonstrated attacks on mcTLS, and proposed a formal model on analyzing the protocol. In brief, one of the attacks exploit the fact that mcTLS does not perform authentication and the handshake finished message for the session initiation between the client and the MB, and between the MB and the server. Due to this, Bhargavan et al. further proposed a protocol that addresses these attacks under the security model that they defined. It does not require any changes to the TLS protocol, in contrast to mcTLS. In response to the attack, the ETSI draft standard that is based on mcTLS proposed a fix to the mcTLS based on message authentication code in their MB Security Protocol (MSP) specification (ETSI, 2018b). At the moment, it remains to be seen how the industries will accept a secure but MB-friendly new protocol for encrypted traffic, since it may mean replacing TLS with MSP. Lee et al. (Lee et al., 2019) proposed maTLS, a middlebox-aware protocol to address the MitM pitfalls. Middleboxes are made visible so that server can be explicitly authenticated, the encryption parameters used can be verified and whether messages are modified. Every middlebox is issued a certificate by a CA, and the certificate is logged in a middlebox transparency log server. Through the log server, a middlebox certificate is publicly verifiable and revocable. However, as stated in (de Carné de Carnavalet and van Oorschot, 2020), while the middlebox certificates are vetted by the CA, the client (or end user) still need to decide to accept these certificates. An attacker may launch a phishing attack by obtaining a certificate with convincing name.

• •

  Advantages:

  • –

    Security: The main provision of the AC technique is that it provides accountability. It means the endpoints will be able to authenticate the deployed MBs, which is unique to this technique.

  • –

    Performance: The technique does not require special cryptographic primitives as in SE and hence is more efficient. It is less efficient as the MitM approach, but provide more flexibility in terms of preserving privacy of the data. It does not require installation of certificate at the client, nor allowing any of the MBs to decrypt and view the full payload of the traffic. For example in mcTLS, the performance during handshake protocol depends on number of contexts and middleboxes. Time required for the first byte to reach the endpoint is 400ms with 10 contexts and 560ms with 14 contexts.

  • –

    Functionality: It provides full functionality as in the MitM technique. This is because for a specific MB, such as an IDS, access would be given to decrypt the portions of the encrypted traffic for the IDS to perform the required inspections.

• •

  Limitations:

  • –

    Changes to TLS: The main pitfall of this approach is it would require all parties, meaning the two endpoints and all the MBs to fully co-operate in order for the scheme to work. This is because the client, and the server must know the type of MBs that they are communicating with. The client, the server and all the MBs must agree on the scheme to be used. It is also not clear how the client and the server may define context (which portion of the data can be reveal, to which MB), especially for data in different domain and then set the access policy for these MBs.

  • –

    Security: Union of the access read/write keys for the scenario whereby MBs are hosted at the service provider will allow the service provider to decrypt most probably all portions of the encrypted traffic.

Inspecting encrypted traffic based on machine learning (ML) technique represents an ideal solution in terms of security and application setting since it does not require any changes to the existing setup. The idea is to analyse the plain metadata and header of the protocol, extract features from the encrypted payloads, as well as analyse telemetry data from the network traffic. For examples, throgh observing behavioural properties (e.g. the round trip time, number of packets sent), observing the encrypted payloads, and observing additional information such as protocol handshakes. It has been shown to be effective in particular for use cases such as traffic clustering, application type and protocol classification, anomaly detection and file identification (Dimou et al., 2019). Among all the techniques, it is the only technique that uses passive inspection. Figure 7 shows a high-level setting of the ML technique.

There are many proposals using ML technique for use cases such as for application type and protocol classification, anomaly detection and file identification. These were comprehensively surveyed in (Dimou et al., 2019). Another proposal for anomaly detection is the technique proposed by Yamada et al. (Yamada et al., 2007). Their scheme performs anomaly detection using only size of data and timing information of the encrypted traffic. More recently, Anderson et al. (Anderson and McGrew, 2016, 2017; Anderson et al., 2018) proposed techniques for malware detection that in addition of utilising sequence of data size and timing, also uses the various TLS header information and DNS data. Anderson et al. demonstrates that some of the malware-based encrypted traffic possess distinct characteristics compared to enterprise network traffic. These characteristics when combined with other telemetry data, allows accurate classification of the malware traffic. They have also showed that random forest method outperforms other methods in terms of classifying malware traffic (Anderson and McGrew, 2017). Yet by careful engineering of the features, including recommendations by domain experts, linear regression using more expressive features actually outperforms random forest method.

There are also techniques that identify malware traffic based on fingerprinting. For example, JA3/JA3S proposed by Althouse et al. (Althouse et al., 2020) generates malware fingerprints based on the TLS metadata (e.g. handshake messages). Anton (Tyurin, 2018) proposed a technique that creates rules by observing the packet byte stream of the traffic to create fingerprint. Specific malware can be detected based on the unique packet byte stream transmitted from the client to the server. The technique is specifically created for use with Suricata. Both the above proposals can be considered as signature-based techniques and require prior knowledge of the malware.

• •

  Advantages:

  • –

    Changes to TLS: The main advantage of the ML technique compared to all the other techniques is that it does not require any changes to existing encrypted traffic setup. No modification is required at the client or the server. The MB installs the ML module so that it is able to analyze the metadata of the encrypted traffic.

  • –

    Security: Since no changes are required to the setting and the underlying protocol, it preserves the security guarantee of the original setting. For example, using ML technique maintains end-to-end encryption of a TLS session between the client and the server. This represents another main advantage compared to all other techniques that require changes to the protocol (i.e. AC technique) or changes to the client and server settings (i.e. MitM, SE, and trusted hardware). However, we remark that machine learning-based analysis and fingerprint techniques may also be used to learn information about a user. For example, it is possible for an attacker to learn about the websites a user surfs or find out the files a user downloads and shares even though the traffic is encrypted (Dimou et al., 2019). It is an interesting area of study as to how pervasive ML techniques can also be used to learn about an entity, in contrast to the techniques being used as a privacy-preserving approach for analysing encrypted traffic without knowing the payloads.

• •

  Limitations:

  • –

    Functionality: The main concern is whether the technique is sufficiently comprehensive to cover most of the detection requirements of MBs performing security functions. As was stated in (Dimou et al., 2019), there are inherent limitation to what can be analysed based on Ml techniques, and as was discussed in (de Carné de Carnavalet and van Oorschot, 2020), there are use cases that will require inspection on the payloads, not just the headers and metadata. As of now, the most successful ML mechanism of Anderson et al. (Anderson and McGrew, 2016, 2017; Anderson et al., 2018) only cater for malware detection. All in all, the technique will need to be able to cater for different types of middlebox services.

  • –

    Performance: It remains to be seen how the performance of the technique as compared to other techniques. Training must be performed before detection can be carried out on real-time data. The timely dataset and accuracy of the training model are area to be further explored. As was discussed by Anderson and McGrew (Anderson and McGrew, 2017) in their work on malware classification using machine learning technique, it took approximately $200$ seconds to train and less than $10$ seconds to test. This is for their best performed random forest algorithm, on the enhanced feature. The timing is a rough estimation from Figure 5 in their work (Anderson and McGrew, 2017). Also, solutions based on this approach need to continuously feeding high fidelity labelled data for training, which can be hard to obtain.

Trusted hardware (TH) has also been deployed for privacy-preserving packet inspection. The emerging practice is to utilize the secure enclave of the Intel SGX trusted hardware. The general idea is for the client or the server to share the session key securely with the enclave residing in the MB. The decryption, inspection and re-encryption is performed in the enclave. The MBs and the service provider hosting these MBs are not able to discern or learn the data and processes. The challenge is how to implement middlebox functionalities efficiently and securely to fully utilize the capability of the trusted hardware. We may classify this technique as using active inspection, but the inspection is hidden from the view of the entity hosting the trusted hardware. Figure 8 shows a high-level setup of the TH technique.

Han et al. (Han et al., 2017) proposed a scheme, SGX-Box, using this technique. In their scheme, the server shares the session key with the Intel SGX’s secure enclave through an out-of-band secure channel. They presented an efficient implementation of performing the inspection inside the secure enclave.

It is also possible to push the MB functions to the network edge (or to the client’s device). This is anologous to hosting the MB at the client, except that inspection are performed in the secure enclave embedded in the client device. This is beneficial in that all outbound traffic is analyzed before it is transmitted from the client device. Inbound traffic on the other hand is verified before it is released to the client device. EndBox, proposed by Goltzsche et al. (Goltzsche et al., 2018), provides such a solution.

There are also works that propose comprehensive secure Network Function Virtualization (NFV) systems using TH technqiue. These NFV systems provide inspection of encrypted traffic as one of their functionality. For example, SafeBricks proposed by Poddar et al. (Poddar et al., 2018). SafeBricks provides MB as a cloud service construction. It ensures the cloud provider only sees the encrypted traffic, where the application header (normally visible under TLS) is also encrypted based on IPSec. Additionally, it shields the rulesets and the network function codes from the cloud provider. LightBox further improves on existing TH-based schemes, including SafeBricks, in terms of efficiency and properties. For instance, LightBox additionally protects privacy of metadata of the traffic, including packet size, count and timing. Two related works are ShieldBox proposed by Trach et al. (Trach et al., 2018) and LightBox proposed by Duan et al. (Duan et al., 2017). ShieldBox and LightBox provide secure middlebox functionalities by provision of NFV systems in SGX. However, both are geared towards efficient deployment of MBs on untrusted cloud providers and would require adaptation to specifically cater for encrypted traffic inspection.

• •

  Advantages:

  • –

    Changes to TLS: One advantage is that it does not require changes to the underlying protocol. However, it must be able to transport the session key to the trusted hardware securely, either by the client or the server.

  • –

    Functionality: Another advantage is it provides MitM-type full functional inspection without the drawbacks of the MitM approach. It allows a MB to inspect the encrypted traffic in a shielded environment, so that no decrypted packets are leaked. It may represent the most practical solution if hardware deployment, cost and security of the trusted hardware is not an issue.

• •

  Limitations:

  • –

    Security: The current main concern is that security of the trusted hardware (i.e. Intel SGX) is still being actively study. As was presented by Lindell (Lindell, 2018), there has been successful side-chanel attacks on Intel SGX. It remains to be seen how serious such attacks are in practical deployment.

  • –

    Performance: It is less efficient for inspection, at least when compared to SE scheme as discussed in (Lan et al., 2016). Take SafeBricks for example, it introduces 16% bandwidth overhead when compared to Embark’s 21% bandwidth overhead. Nevertheless, SafeBricks also incurs 0-15% throughput performance overhead at the middlebox due to SGX compared to negligible overheads of Embark and BlindBox. However, Embark(at gateway) and BlindBox(at client) incur high latency in order to encrypt the packets at the endpoints, where SafeBricks does not pay such cost. Another issue is the availability of the hardware and cost. While most recent devices would have a secure enclave embedded (i.e. Intel SGX), issues remain for those that are not, especially legacy systems.

As a summary for what we have discussed thus far, Table LABEL:tbl:compare provides comparisons between the models, use cases, characteristics (e.g. security, types, models, outsourced MB to cloud), the five techniques and performances.

In terms of utility, schemes based on AC and TH have the capability to provide full functionality similar to inspection on plaintext data. This is because both techniques enable MBs to decrypt the underlying traffic.