Since you have read about TLS, we can now have a look at the proposed mcTLS, inspect the motivation behind it and show some first indications, why it might be not that much of a bright idea.

Motivation

Let’s start off by looking into the reasons for researchers to design a new protocol, especially when TLS has seen such a widespread adoption.

There are several lucrative business models important use cases that have severe problems with TLS based on the same problem: The data transferred with TLS cannot be read and cannot be altered. Let’s have a look at two technologies that are in wide spread use but just don’t mix well with TLS:

• Enterprise Firewalls are firewalls that are deployed by your companies administrators and work on the network level to protect you and the companies equipment from a various set of threats. If the traffic is encrypted those devices just cannot view the content of the traffic and won’t be able to distinguish between good and bad traffic.
• Caching proxies are devices in the network that are able to read and write on your traffic. They are able to cache data you have downloaded in your company and re-introduce that data in other connections of you coworkers without them to have it re-download over the internet. Think of the cute cat-picture you have just seen is saved on some device in your company and when your coworker clicks on the link you have sent them, the caching proxy redirects the request to that saved image.

Since those two technologies are in wide-spread use and TLS is also used by most connections, there obviously has to be a way to break open the secure connections to analyze and alter the protected data. But before we investigate how this is currently done in most cases, let me cite the mcTLS paper:

How do you add a middlebox to a TLS session? In short: you do not.

In my opinion the discussion should stop right here. But then there would not be a blog post to write.

Introducing middleboxes

Let’s start with the enterprise firewall. Your IT-department sets up your computer to open all connection to the outside world trough that device and simply instructs the network to deny all other connections. That way you have no chance to circumvent the firewall in any way. So the firewall is now able to view and edit any traffic passing in and out of the company. If that traffic is encrypted, it cannot know what is going on in that connection and that is not acceptable for the promised security guarantees.Now let’s have a look on how they break open TLS: One way to try to prevent attacks via encrypted connections, is to simply drop them. This can be done by instructing the firewall to deny all traffic that it is not able to read and understand.Since this would break the internet for most users and introduce large security problems, the choose a worse other way: Intercepting TLS connections.The firewall acts as a middlebox and impersonates the server, decrypts the received traffic, investigates it and re-encrypt the traffic and send it to the original destination server.TLS enables the client to authenticate the server and therefore such a man-in-the-middle attack should not be feasible. However, your browser relies on installed CAs (see the last article on what they do) to verify the authenticity of the destination. So if your firewall could forge trusted certificates, it can impersonate every server and that is exactly what they do: Your IT-Person of choice installs a custom root-CA on your machine and thereby allows the firewall to create a certificate trusted by your machine for every connection you make. It is important to note, that with the possession of the signing key of that CA, one can impersonate every endpoint without the clients noticing (except they inspect the certificate chain). This means that most users are not aware of the middlebox in the first place.

The caching proxy works in a similar manner, in addition to reading and policing your connections, it may also edit the contents of your data transfer for performance reasons.

Problems with custom root certificates

There are several problems with the aforementioned technique of inserting hardware into the network that is possible to impersonate every entity on the network:

• Middleboxes might have sloppy implementations of verifying the target certificate
• The middleboxes might have outdated or even deprecated cryptographic technologies in place that allow an attacker to trick the box into revealing secret information or worse
• Often, those middleboxes are actual, dedicated hardware, that is hard to update by design. Some vendors stop providing updates after some time and perhaps just are not able to provide solutions for found problems.
• Once an attacker gains control of a middlebox, he can mount serious attacks on all clients in the network without them noticing.
• The client cannot verify what the middlebox does with the connection and if how they secure the connections on the other side
• Often users don’t even know that there is a middlebox in place and therefore have a false sense of security and intimacy (remembering the nice photos you received on your phone lately?)

The inventors of mcTLS realized those problems and tried to solve them with the following protocol.

The mcTLS protocol

The mcTLS protocol was presented here: https://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p199.pdf

In this section we have a quick look on how the protocol works and especially look at the differences to the original TLS. This section is heavily inspired by the paper but tries to explain the components used in a more accessible fashion.

First off, I want to make a obvious but blunt point: the mcTLS is more complex than the original TLS and therefore provides more attack surface and is harder to understand. Just have a look at the diagram depicting the message exchange:

Design considerations

A multi-party key-exchange is waaaay more complex than a two party one.

I won’t go into the details of the protocol here, just read the official paper if you are interested.

One thing that is needed to understand is the calculation of MACs in the protocol: The middlebox is able to compare the Fin messages but since it is not aware of the client-server channel key, which is used to compute the MAC, it cannot verify that the message transcript at its own endpoints match the one of the client and server.

Breaking Entity Authentication

Imageine the following scenario: A caching proxy is used in an enterprise setting to speed up client downloads and acts as a middlebox.A client C wants to download from a trusted server S.

The attacker A1 can now intercept the handshake between C and MB and change the request from “Connect to S” to “Connect to A2”, where A2 is an attacker controlled server. Now the middlebox is going to think C wants to connect to A and rightly opens up a connection to A2. The attacker controlled server A2 then connects to S, the original destination of the client connection and restores the original request parameters (“Connect to S”).

On the way back, A2 changes the Key and Certificate provided by S to its own, so that MB is not aware of the tampering. Before MB is sending those keys to C, the attacker A1 again changes the keys, this time to the original keys provided by S.

The connection will then succeed, with C and S thinking they have a connection exclusively proxied by MB and MB (correctly) thinking it proxies a connection between C and A. So the complete setup is:

C -> A1 -> MB -> A2 -> S

Since the attacker restores the handshake parameters for C and S repectively, the transcript at that endpoints matches, so do the transcript MACs. Unfortunately, the transcript at MB does not match but since it does not know the Client-Server channel key, it cannot verify its own transcript.

This attacks completely breaks the entity authentication for mcTLS if it is used with a caching proxy. The attacker can not read any of the messages between C and S but is able to let MB retrieve malware infected ressources from A, delivering them to to C.

Conclusion

To conclude:

Don' use mcTLS.

Ok, now seriously: Try to avoid building such complex protocols by modifying existing ones. This create serious security problems and changes the semantics of the handshake. Even if you do, try not to reuse names for your product, that are already used somewhere else in the industry (Looking at you JavaScript), especcially if the authors of the original protocol urge you to choose a different name.

A better approach would be to try to define the security problems you try to solve, define the assuptoions you have and the requirements that need to be met. Then - and only then - design your protocol and try to prove how it is impossible for an attacker to break it. This has been tried by Bhargavan et al. in their paper, it remains to discuss how well they did their job here, since their proofs are sloppy at best.