Skip to content

Multi-context TLS (mcTLS): Enabling secure in-network functionality in TLS

June 20, 2016

Multi-Context TLS (mcTLS): Enabling secure in-network functionality in TLS Naylor et al. SIGCOMM 2015

We’re rushing to deploy HTTPS everywhere – and about time – but this has interesting implications for middleboxes since it’s hard for them to do their job when traffic is encrypted end-to-end. Say you want to add caching, compression, an intrusion detection system (IDS), parental filter, tracker blocker, or WAN optimizer to TLS sessions – how do you do this? You can’t, at least not without breaking the end-to-end TLS guarantees.

Consider an enterprise network that wants to insert a virus scanner in all employee sessions. A common solution is to install a custom root certificate on the client. The middlebox can then create a certificate for itself purported to be from the intended server and sign it with the custom root certificate. After the client connects to the middlebox, the middlebox connects to the server and passes the data from one connection to the other.

This Split TLS solution provides no mechanism for authenticating the middlebox (or even realising it’s there), provides no guarantees to the client beyond the first hop, and gives middleboxes full read/write access to the data stream while it is decrypted between TLS sessions.

Given these problems, it should not be a surprise that users are concerned about (transparent) middleboxes. One could even argue that using TLS with a middlebox is worse than not using TLS at all, since clients and servers are under the illusion that they have a secure session, while some of the expected security properties do not actually hold.

So it seems we have three choices: (a) the status quo, in which HTTPS is subverted to pretend to give guarantees that aren’t really there, (b) stop using middleboxes and place all functionality at the endpoints, or (c) design a principled mechanism for middleboxes in TLS sessions. This paper of course, is all about option (c), with a protocol the authors call multi-context TLS (mcTLS).

There’s a camp that argue we should just stop using middleboxes (option b), on the basis that they violate the original Internet architecture and the end-to-end principle. Pragmatically, the authors put forward the case that middleboxes are here to stay:

  • They have proven to be useful, and can add functionality not provided by endpoints such as virus scanners inside an enterprise.
  • Some middlebox functionality is inherently more effective when placed in the network, and relying on client-side implementations may be problematic (just consider the upgrade cycle for a start).
  • Real-world deployments tend to have about the same number of middleboxes as they do L3 routers, and all actors in the Internet use them. “Given this investment, middleboxes are unlikely to go away, so we need a clean, secure way to include them in encrypted sessions.
  • The Internet is not a centrally managed monopoly, but a market-driven ecosystem with many actors making independent decisions.

The bottom line is simple: just like end-to-end encryption, middleboxes are an integral, useful part of the Internet and they are here to stay.

The basic idea

The first goal is to make middleboxes explicit, so that endpoints have both knowledge and control over which network functions are part of the session. Once this path is set up, mcTLS allows the content flowing over the connection to be divided up into multiple contexts, for example: request headers, request body, response headers, and response body (though any division is possible). Middleboxes may be granted no access, read-only access, or read-write access to each context independently. Endpoints can detect any modifications made, whether legal or illegal.

Consider the following examples of application layer middleboxes and the permissions they need – note that none of them read/write access to all of the data.

A data compression proxy for example would need write access to HTTP responses, or going further separate contexts could be used for images (accessible by the proxy) and the rest of the page artefacts (which may not be). A parental filter may only need access to the HTTP request headers. A corporate firewall may give read-only access to the IDS (and security appliances no longer need to impersonate end servers). In an online banking scenario, a server can prevent unknown middleboxes from participating in the session, regardless of what level of access the client assigns. And with HTTP/2 streams, mcTLS would allow browsers to easily set different access controls for each stream.

mcTLS upholds the properties provided by TLS (R1-R3 below), and adds two new requirements of its own (R4 and R5):

  • R1 Endpoints should be able to authenticate with each other (and all middleboxes).
  • R2 Only the endpoints (and trusted middleboxes) can read or write the data.
  • R3 All members of the session must be able to detect in-flight modifications by unauthorized third-parties, and endpoints must be able to check whether the data was originated by the other endpoint (vs. having been modified by a trusted middlebox).
  • R4Endpoints must always be able to see all trusted middleboxes in a session, and middleboxes can only be added with the consent of both endpoints.
  • R5 Middleboxes should be given the minimum level of access needed to do their jobs.

Protocol details

To satisfy the requirements above, mcTLS adds two features to TLS: encryption contexts and contributory context keys.

An encryption context is simply a set of symmetric encryption and message authentication code (MAC) keys for controlling who can read and write the data sent in that context. Applications can associate each context with a purpose (opaque to mcTLS itself) and access permissions for each middlebox.

The two endpoints of the connection each generate half of each context key (hence contributory context keys) and send their halves to each of the middleboxes. Thus a middlebox can only gain access if it receives both halves of a key, ensuring the client and server are both aware of every middlebox and agree on their access permissions.

The initial handshake is very similar to the TLS handshake. It’s purpose is to:

  • Allow the endpoints to agree on a cipher suite, a set of encryption contexts, and a list of middleboxes and their permissions.
  • Allow the endpoints to authenticate each other and all of the middleboxes (if they choose to)
  • Establish a shared symmetric key Kendpoints between the endpoints.
  • Establish shared symmetric keys Kwriters and Kreaders for each context.

For full details of the mcTLS extensions to the TLS handshake, see section 3.5 of the paper. Once the handshake has completed, the mcTLS record protocol handles communication.

The TLS record protocol takes data from higher layers (e.g., the application), breaks it into “manageable” blocks, optionally compresses, encrypts, and then MAC-protects each block, and finally transmits the blocks. mcTLS works much the same way, though each mcTLS record contains only data associated with a single context; we add a one byte context ID to the TLS record format. Record sequence numbers are global across contexts to ensure the correct ordering of all application data at the client and server and to prevent an adversary from deleting an entire record undetected.

Endpoints can limit read access to contexts by withholding the corresponding Kreaders key from a middlebox. MACs are used to ensure that only legal modifications (made by middleboxes with write-permissions) are made, and that any illegal modifications can be detected. mcTLS follows an endpoint-writer-reader approach, in which every mcTLS record contains three keyed MACs…

  1. An endpoint MAC generated with Kendpoints which the endpoints can use to check for any modifications
  2. A writers MAC generated with Kwriters (shared by endpoints and writers), and
  3. A readers MAC generated with Kreaders (shared by endpoints, readers, and writers).

Endpoints generate all three MACs when assembling a record. If a writer middlebox modifies a record, it generates new writers and readers MACs based on its modifications, and forwards the endpoint MAC unchanged. Reader middleboxes simply forward all MACs unchanged of course.

Each party receiving a record can now determine its status by examining the message received and the MACs:

  • An endpoint can check if any modifications have been made by checking the endpoint MAC. It can confirm that no illegal modifications were made by checking the writers MAC.
  • A writer can check that no illegal modifications have been made in the chain before it by checking the writers MAC.
  • A reader can check that no illegal modifications have been made by checking the readers MAC.

In the protocol as described, readers cannot detect illegal modifications made by other readers, but the moment a writer or endpoint is reached the modification will be detected. The authors describe extensions to provide this additional protection if required, but consider the benefits insufficient to justify the additional overhead.

What about the overhead?

The authors compared mcTLS to an unencrypted session, an end-to-end TLS connection (E2E-TLS) in which middleboxes blindly forward the encrypted data, and a split TLS scenario in which TLS connections are split at middleboxes with decryption and subsequent re-encryption for each leg. The main results are as follows:

  • mcTLS’s handshake is not discernibly longer that Split TLS’s or E2E-TLS’s, based on a measurement of time-to-first-byte.
  • mcTLS transfer times are not substantially higher than SplitTLS or E2E-TLS irrespective of link type, bandwidth, or file size.
  • mcTLS has no impact on real-world web page load time
  • In terms of data volume, apart from the initial handshake overhead (negligible for all but short connections), mcTLS adds less than 2% overhead for web browsing
  • mcTLS servers can serve 23-35% fewer connections per second than Split TLS, but mcTLS middleboxes can serve 45-75% more.

(Click to enlarge).

Introducing middleboxes into TLS while maintaining the security expectations of clients, content providers, and network operators is not easy…

… We show that building such a protocol is not only feasible, but also introduces limited overhead in terms of latency, load time, and data overhead. More importantly, mcTLS can be incrementally deployed and requires only minor modifications to client and server software to support the majority of expected use cases. By using mcTLS, secure communication sessions can regain lost efficiencies with explicit consent from users and content providers.

2 Comments leave one →
  1. gasche permalink
    June 20, 2016 9:35 pm

    Now that we understand the wide-spread usage of Deep Packet Inspection (DPI) technologies for human abuse (Lybia, Syria, Bahrain, etc.: see for example ), I find it highly questionable for networking researchers to continue investing their efforts in furthering this technology and finding a compromise between its needs and encryption (which was designed specifically to prevent these situations).

    (It would of course be easier to understand in the case of research and development efforts inside companies using DPI technologies internally, or networking companies selling middlebox-related products. Yet the recent publications on this topic that I have seen come from research universities such as CMU or Berkeley.)

    Said research is certainly not done with the intent to harm, but was there a serious analysis of the costs and benefits of the range of known and predicted applications? I think that technologies that fundamentally imply being out of end-user controls (or knowledge and intent) are very dangerous, to say the least.

    Some uses of DPI may be in the general interest and unquestionable, but surely there are fascinating research challenges in realizing those uses in another way that has less potential for harm? It is certainly possible to think of caching strategies, for example, that do not require middleboxes, and I hope there should also be a way for competent system administrators to design company-level security policies that prevent outside attacks without encouraging the private sector to develop a dictator’s dream toolbox.

    (Someone may counter-argue that research effort could also help “do DPI better”; for example the present article has, among others, the laudable goal of making sure that middlebox presences is not invisible to the end-user, reducing some of the potential for harm. But I think that there is still strong potential for danger in solutions that mitigate and improve DPI practices, and make it more desirable for companies or more acceptable for users. Once the branch is manifestly rotten, maybe it’s time to start working on something fresh and positive instead.)

  2. June 21, 2016 10:54 am

    I wonder if mcTLS is likely to amplify the existing asymmetry in power relationships on the internet. For example…

    – Will any website let me connect to it if there’s a tracker blocker on the path?
    – When I sign to to internet banking, will my bank use their knowledge of the presence of any middlebox to deny all liability for any future fraudulent transaction?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: