Towards Efficient Privacy-Preserving Deep Packet Inspection

Abstract

Secure Keyword-based Deep Packet Inspection (KDPI) allows a middlebox and a network sender (or receiver) to collaborate in fighting spams, viruses, and intrusions without fully trusting each other on the secret keyword list and encrypted traffic. Existing KDPI proposals have a heavy-weighted initialization phase, but also require dramatic changes to existing encryption methods used to the original network traffic during the inspection phase. In this work, we propose novel KDPI schemes CE-DPI and MT-DPI, which offer highly competitive performance in initialization and guarantee keyword integrity against malicious middlebox. Moreover, our methods work readily with AES-based encryption schemes that are already widely deployed and well-supported by AES-NI. We show that our KDPI schemes can be integrated with TLS, adding marginal overhead.

A Integration with TLS

Since the TLS protocol is the most widely used security protocol in practice, we integrate MT-DPI into TLS. We extend the TLS protocol following the extension mechanism described in [16]. In the TLS protocol, two endpoints exchange their supporting extensions with corresponding extension messages during the first round-trip of the TLS handshake protocol. Our TLS extension is based on TLS 1.3 [55] where the extension messages from the TLS server are encrypted.

TLS Extension for the DPI Protocols. As TLS is a two-party protocol, it is challenging to introduce MB in the TLS session. To address such a challenge, our TLS extension should provide 1) a way to make an agreement between S and R to use a particular MB and 2) a way to negotiate parameters for MT-DPI with MB. To this end, we make S and R execute the two different TLS extensions – one with each other and the other with MB– and use the TLS extension messages to negotiate necessary parameters, resulting in two TLS sessions per each entity. We design the TLS handshake for the latter session to be executed within the TLS handshake for the former session; thus, we refer to the former TLS extension as the master TLS extension and the latter as the slave TLS extension. We also consider how to bind two resulting TLS sessions while designing the two extensions.

Master TLS Extension. The main objective of the master TLS extension protocol is to agree on what MB to use in DPI and share secrets between S and R. Although both S and R can be either of a TLS client or a TLS server in the master TLS extension, we refer to a TLS server as S and a TLS client as R for ease of presentation. During the master handshake, R includes its list of preferred MBs in its extension message. Then, S selects which MB to be used, and responds with the name of the MB and the DPI key in its extension message. We also let S send a nonce to bind the master and the slave. Note that the extension message from the TLS server is encrypted in TLS 1.3; thus, the DPI key and the nonce are secret. If there is no DPI key usable with MB, S should perform the initialization protocol with MB before sending its extension message. Then, S and R respectively execute the slave TLS extension protocol with MB.

Slave TLS Extension. The slave TLS extension protocol aims to authenticate MB, negotiate parameters for MT-DPI between endpoints and MB, and bind master and slave sessions. In the slave TLS extension protocol, S and R are the TLS clients and MB is the TLS server. S and R can authenticate MB with the name negotiated in the master extension and the certificate provided by MB according to the TLS handshake protocol. With the extension messages, S and R respectively exchange parameters with MB, such as the token size or the initial counter value, to be used for the token computation and the token inspection. All the parameters are finally decided by MB and the values are sent to S and R via the MB ’s extension message.

Binding the Master and the Slave Extensions. To bind the master and the slave sessions, the endpoint can include the nonce from the master TLS extension in its extension message of the slave TLS extension. However, the extension message from the TLS client is not encrypted; thus, the nonce should not be sent as it is. If only the nonce is sent by one party (say, S), a network adversary can know the nonce and argue to be the other endpoint (say, R) to MB. To address this issue, we leverage the random values exchanged between the TLS server and the TLS client in the master TLS protocol. Before the extension messages, in the first round-trip of the TLS protocol, the endpoints exchange two random values in the plaintext – a server random and a client random, generated by the TLS server and the TLS client. We let S and R send a hash of the nonce and its random value of the master TLS extension to MB respectively in the slave TLS extension. Then, MB forwards the hash from S (or R) to R (or S). Then, R (or S) verifies the hash and aborts the connections with S (or R) and MB if the hash is not verified. Otherwise, S begins with sending the actual data to R in the master TLS session while performing the DPI protocol with MB in the slave TLS session.

Implementation. To show feasibility of the TLS extensions with the DPI protocols, we implement the master and the slave TLS extensions in the OpenSSL-1.1.1l library, which we will release at the public repository. We also design our implementation so that it does not require any revision to the off-the-shelf applications. That is, all the applications can use our protocol immediately by replacing their OpenSSL shared object with our shared object. We show that the protocol is immediately deployable in our testbed where cURL [13] is used as a TLS client and open-source web servers (Nginx [46] and Apache [13]) are used as TLS servers in the master TLS extension.