maTLS: How to Make TLS Middlebox-aware?

Network Distributed System Security '19

Introduction

In general, TLS cannot be compatible with middleboxes,
since the TLS protocol prohibits man-in-the-middle attacks

TLS with Middleboxes

An image will be inserted

▸ Middleboxes are widely used

    Middleboxes such as anti-virus software and a firewall are widely used to enhance security and performance in networking.

▸ TLS does not allow a man-in-the-middle

    TLS is an end-to-end security protocol; thus, TLS does not permit middleboxes to be involved in the session.

▸ Middleboxes cannot be used with TLS

    Middleboxes that should read application data become dumb with TLS.

SplitTLS is risky

▸ Middleboxes perform man-in-the-middle attacks

    To utilize functionalities of middleboxes, the current approach splits the TLS session by using private key sharing or custom root certificates

▸ One approach: Private key sharing

    A middlebox such as web application firewalls previously gets the private key and the corresponding certificate from the server and impersonates the servers, when the client initiates a TLS handshake with the middlebox.

▸ The other approach: Custom root certificate

    A middlebox such as anti-virus software initially installs the custom root certificate into the client's trusted store and forges the certificate, when the client initiates a TLS handshake with the middlebox
An image will be inserted

Problems

The current TLS-interception scheme (a.k.a. SplitTLS) is risky in terms of authentication, confidentiality, and integrity, which are guaranteed by the TLS protocol

Authentication

An image will be inserted

▸ Authentication is a process to confirm the identity of the other point

    Generally, the client authenticates the server to confirm the server is intended. This prevents the attacker from being involved into the session.

▸ Clients cannot directly authenticate servers with SplitTLS

    It is continuously reported that some middleboxes failed to validate invalid certificates and established a valid-looking session with the client.

Confidentiality

▸ Confidentiality means that no one between the endpoints can read the messages

    The TLS session between the client and the server is established with a strong ciphersuite and a key stream is only once used.

▸ Clients cannot know the security of the segments after the immediate middlebox

    Some middleboxes are known to advertise weak ciphersuites.
An image will be inserted

Integrity

An image will be inserted

▸ Integrity means that no one but the endpoints can modify the messages

    With the message authentication code (MAC), the unintentially modified messages are detected.

▸ Client cannot detect whether the message is modified after the immediate middlebox

    It is known that some middleboxes insert unwanted messages, some of which are even malicious.

Main Causes

The main cause of the problems is because the client has no idea of the involved middleboxes

Two Causes

▸ Client cannot be aware of the involved middleboxes

    With SplitTLS, the client always believes its peer is the intended server.

▸ Client is forced to trust behavior of the middleboxes

    Even if the middlebox incorrectly behaves or violates the client's policy, there is no way for the client to detect it.
An image will be inserted