Love all, trust few: On trusting intermediaries in HTTP Thomas Fossati Vijay K. Gurbani Vladimir Kolesnikov Alcatel-Lucent Alcatel-Lucent, Bell Labs Alcatel-Lucent, Bell Labs Cambridge (UK) Naperville, IL 60566 (USA) Murray Hill, NJ 07974 (USA) thomas.fossati@alcatel- [email protected] [email protected] lucent.com labs.com ABSTRACT middleboxes provide a variety of services such as parental fil- Recent pervasive monitoring of Internet traffic has resulted tering, caching, accelerating content across slow access links, in an effort to protect all communications by using Trans- anti-malware scanning and traffic shaping to avoid conges- port Layer Security (TLS) to thwart malicious third par- tion; the effect of using TLS is to prohibit such legitimate ties. We argue that such large-scale use of TLS may poten- uses of middleboxes. tially disrupt many useful network-based services provided The absence of a well-understood and standard manner by middleboxes such as content caching, web acceleration, by which to introduce a middlebox in the two-party TLS anti-malware scanning and traffic shaping when faced with model leads to dangerous point solutions like TLS intercep- congestion. As the use of Internet grows to include devices tion proxies that have the effect of destroying end-to-end se- with varying resources and capabilities, and access networks curity completely. Furthermore, thin clients (tablets, smart with differing link characteristics, the prevalent two-party phones) and the prevalence of computing resources in the TLS model may prove restrictive. We present EFGH, a cloud are engendering a new architecture, the split browser pluggable TLS extension that allows a trusted third-party to [4]. Split browsers offload network-intensive computation to be introduced in the two-party model without affecting the servers in the cloud, leaving the thin client to render content underlying end-to-end security of the channel. The exten- more efficiently. By their definition, split browsers introduce sion stresses the end-to-end trust relationship integrity by HTTP proxy middleboxes between the client and the origin allowing selective exposure of the exchanged data to trusted server. middleboxes. Contributions: It is important that the end-to-end na- ture of TLS is preserved while accounting for the complexi- ties of the currently deployed Internet. To do so we propose 1. INTRODUCTION End-to-end Fine Grained HTTP (EFGH) security, a plug- The Internet community has viewed the recent pervasive gable extension to the TLS protocol that allows middleboxes monitoring efforts as an attack on the Internet [1], [2]. Such to be explicitly introduced in the client-server path without large scale pervasive monitoring is indeed an attack, there affecting the security guarantees of the end-to-end channel. is simply no arguing that it is not. However, encrypting The trusted middlebox is granted access to a subset of the all traffic as a defence mechanism leads to the preclusion of traffic that the principals have agreed upon. The capability middleboxes that provide services that benefit networks and is negotiated between the principals through the TLS hand- users. shake extension mechanism. Upon completion of the hand- Encryption on the Internet is performed by the Transport shake, and if both parties support EFGH, a one round-trip Layer Security (TLS, [3]) protocol. TLS, and its predeces- message exchange is required for key establishment between sor, Secure Socket Layer (SSL) were developed at a time the client, the server and the proxy. EFGH strongly stresses in the trajectory of the Internet where electronic commerce the end-to-end trust relationship integrity and allows the was the primary application that required end-to-end se- client and server to selectively expose exchanged traffic to curity between a browser and a web server. Middleboxes, trusted intermediaries via a modified TLS record format. when they existed at this time, were mostly network/port The rest of this paper is structured as follows: Section 2 translators. Today's Internet is much different. It is char- puts our work in context with existing literature. Section 3 acterised by plurality of end-user devices, access networks, describes the protocol building blocks; Section 4 discusses and middleboxes that apply value-added services (VAS) to its security properties. We conclude in Section 5. the traffic transiting through them. In managed networks, 2. RELATED WORK Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed In the absence of techniques like EFGH that allow mod- for profit or commercial advantage and that copies bear this notice and the full cita- erated access of the traffic to intermediaries, enterprises and tion on the first page. Copyrights for components of this work owned by others than service providers often resort to questionable solutions that ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re- publish, to post on servers or to redistribute to lists, requires prior specific permission have the adverse and detrimental effect of degrading the and/or a fee. Request permissions from [email protected]. overall security. TLS interception proxies [5] are a good ex- HotMiddlebox’15, August 17-21, 2015, London, United Kingdom ample; such proxies straddle two separate sessions and act c 2015 ACM. ISBN 978-1-4503-3540-9/15/08. $15.00 as a man-in-the-middle (MitM) to decrypt and re-encrypt DOI: http://dx.doi.org/10.1145/2785989.2785990 the content as it traverses through them. The user is not 1 notified and cannot give consent to the presence of such in- ClientC ProxyP ServerS terception proxies; thus they erode any expectation the user has of the connection being end-to-end secure. In addition, certP they carry other risks: an organisation may be open to le- connect(2) gal exposure as a result of inspecting communications that 1 are intended to be private and such solutions act as an at- CONNECT server:443 HTTP/1.1 tack target themselves since they are a single point where 2 encrypted sessions are decrypted and available as plaintext. Loreto et al. [6] improve on transparent interception prox- connect(2) 3 ies by allowing a client (browser) to discover and authenti- cate a trusted proxy and for the user to explicitly provide HTTP/1.1 200 OK consent for traffic to flow through that proxy. Unlike our 4 approach, once the trusted proxy has been identified and ClientHello + efgh(proxy) consented to, it (the proxy) has cleartext access to the in- 5 formation flowing between the client and the server. Loreto et al. further constrain the trusted proxy such that URIs ServerHello [+ efgh(proxy)], 6 that are available over the https scheme do not traverse the Certificate, ServerKeyExchange, ServerHelloDone proxy. This has the effect of precluding the proxy from per- ClientKeyExchange, ChangeCipherSpec, Finished forming services that may be of benefit to the user. Peon [7] 7 allows clients to use explicit proxies as well but encourages ChangeCipherSpec, Finished the use of secure hashes to detect if the proxy applied any 8 transforms to the message. However, unlike our work, it de- scribes a binary proposition for security: either the proxy is cert , cert , ms cert cert , ms trusted and has access to decryption keying material or it P S S P is not and traffic through it is encrypted end-to-end. Mc- Grew et al. [8] introduce a TLS extension to allow a chain Figure 1: DHE TLS handshake with EFGH option of TLS proxies to inform a client about the capabilities of the (proxied) server, so that the client could make knowl- edgeable access control decisions about the server as if the • the policy language (Section 3.4) determines which proxies were absent. The main problem with this proposal subset of the application protocol traffic needs to be is that it breaks the TLS end-to-end security assumption by disclosed to the third party. allowing the proxies to actually be MitM entities. Moving down from application to the transport layer, tcp- 3.1 EFGH TLS extension crypt is a transport layer encryption protocol [9, 10] that EFGH does not modify the normal TLS handshake; in- cryptographically protects TCP segments. While tcpcrypt is stead it moves the necessary three party key negotiation a good solution for opportunistic encryption, it does not re- protocol into a separate construct with a well defined inter- place TLS. Some drawbacks of tcpcrypt are its use of short- face to the TLS handshake (see Section 3.2). There are two lived keys to provide some forward secrecy and the lack of a main reasons for this: first, we want to simplify as much as key confirmation step in its 4-way handshake. Further down possible the formal analysis required to prove (or disprove) at the IP layer, Kasera et al. [11] and Zhang et al. [12] de- the security of EFGH by building on top of the extensive scribe allowing trusted middleboxes in an IPsec association literature that has been produced regarding the security of between two endpoints. In Kasera et al. [11] the part of the TLS handshake [13], [14]. Secondly, we want to allow the message that is destined for the proxy is sent in clear- independent evolution of the two mechanisms, especially in text. Zhang et al. [12] propose dividing the payload into these early stages of development. multiple zones, each encrypted with a different key. The Therefore, the only modification required by EFGH con- primary drawbacks for an IPsec-based solution remain the sists of a new TLS extension [15] sent by the client along need for an separate key management scheme, the cost of with the ClientHello, which is intended to introduce the incurring double encryption when TLS is used on top of an identity of the proxy to the server, together with the associ- IPsec channel, and its primary use in managed networks to ated fine-grained disclosure policy.