maTLS: How to Make TLS Middlebox-aware?

An image will be inserted

▸ Implementation

     We implement the maTLS protocol with OpenSSL and the simple applications in C for evaluation. A client application performs the maTLS handshake with the middleboxes and the server. Then, the client sends an HTTP GET request message and finally receives an HTTP RESPONSE message from the server (or the middlebox). A server application executes the maTLS handshake with the client and the middleboxes, receives the HTTP request message, and response with the HTTP RESPONSE. A middlebox application simply executes the maTLS protocol with the client-side entity, reads the SNI field to know the intended server from the received ClientHello, and performs another maTLS handshake with the server-side entity. After the session is established, the middlebox simply forwards the received message from one side to the other side.

▸ Testbed

    We set three different scenarios according to the place where the server and the server-side middlebox are located. The three scenarios are an intra-country, an intra-region, and an inter-region scenarios. The client and the client-side middlebox are located in Seoul National University in Korea in three scenarios. In the intra-country scenario, the server and the server-side middlebox are located in the AWS Seoul data center in Korea. In the intra-region scenario, the server and the server-side middlebox are situated in the AWS Tokyo data center in Japan. In the inter-region scenario, the server and the server-side middleboxes are in the AWS Virginia data center in USA.

An image will be inserted

▸ HTTP Page Load Time result shows the maTLS protocol incurs a slight delay compared with the SplitTLS protocol and the mcTLS protocol

    The maTLS protocol incurs delay time from 10.22ms to 32.52ms, compared with the SplitTLS protocol and the mcTLS protocol.

▸ Most of delay time is due to a initial setup of the maTLS session

    When we measured the delay time for data exchange after the session is established, three schemes show similar result. This means that most of delay time of the maTLS protocol is due to an initial setup of the session. We conclude that once the session is established, maTLS provides similar performance to the others while preserving all security merits that we have discussed.

An image will be inserted

▸ The overhead of the three audit mechanisms with regard to the number of middleboxes is almost negligible.

    The overhead increases linearly with the number of middleboxes but the increments are marginal. For example, only an extra 0.045ms and 0.063ms overhead are required for the explicit authentication and security parameter verification, respectively. Note that only 0.026ms is needed for valid modification checks, even with 8 middleboxes.

An image will be inserted

▸ CPU Processing Time is also marginal

    In the server's perspective, the CPU processing time is also increased linearly, but the increment is marginal. The increment was only 0.398ms per a middlebox.