DOCSLIB.ORG

The Security Implications of HTTP/2.0 Isobel Redelmeier Iredelmeier

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Security Implications of HTTP/2.0 Isobel Redelmeier Iredelmeier The Security Implications of HTTP/2.0 Isobel Redelmeier [email protected] Mentor: Ming Chow Isobel Redelmeier The Security Implications of HTTP/2.0 12/13/13 COMP116, Fall '13 Abstract While the main changes that HTTP/2.0, the upcoming upgrade to HTTP that is being built on a foundation of the HTTP/1.1 and SPDY protocols, focus on improving performance, these changes also have significant security relevance. Performance improvements such as multiplexing and header compression, as relatively new technologies to the World Wide Web, should be used with proper awareness that exposed vulnerabilities, such as the CRIME exploit, will not necessarily be fixed in HTTP/2.0. However, HTTP/2.0 also looks to patch existing security issues in HTTP/1.1, including limiting the cacheability of pushed resources by servers that host multiple tenants. The most significant security question of HTTP/2.0 – pervasive or selective encryption – may have important effects the Web as a whole, but it remains undecided. 2 Isobel Redelmeier The Security Implications of HTTP/2.0 12/13/13 COMP116, Fall '13 1. Introduction The Hypertext Transfer Protocol (HTTP) has existed in its current state, HTTP/1.1, since 1999. Fourteen years is a significant reign in today's world of rapidly changing technologies, and the next iteration, HTTP/2.0, is currently scheduled to be submitted for standardization at the end of 2014 [7]. As HTTP forms the backbone of the entire World Wide Web, the security of the protocol is vital to both individuals and corporations seeking privacy and confidentiality in their operations. What are the security implications of the upgrade from HTTP/1.1 to HTTP/2.0? I will examine this question through by comparing the proposed and discussed versions of HTTP/2.0 to HTTP/1.1 and SPDY, a new network protocol and significant inspiration of HTTP/2.0, with regard to the security considerations outlined in the current specifications as well as some that are not listed. Answering this question in its entirety would be impossible at the present time for two main reasons. First and somewhat trivially, perfect security of something as widespread as HTTP would be nigh on impossible – especially when one factors in all of the emerging protocols and technologies as well as the recent adaptations to existing protocols that introduce new use cases of HTTP. Second and more importantly, the specifications of HTTP/2.0 are far from completed. A time machine or crystal ball would currently be necessary to anticipate what the final version of HTTP/2.0 will entail, not to mention all of the possible exploits and vulnerabilities that it may contain. Many significant decisions are from concluded. Most obviously, the question of how to integrate Transport Layer Security (TLS) or another form of encryption remains hotly debated amongst the working group and other participants in the HTTP/2.0 community. Altogether, this 3 Isobel Redelmeier The Security Implications of HTTP/2.0 12/13/13 COMP116, Fall '13 means that in the ensuing paper I will attempt to not only address the questions already being asked about the security of HTTP/2.0, but also to reveal those which have yet to be asked. 1.1 Background While the working group acknowledges the significance of security in framing HTTP/2.0, security is not the focus of the upgrade. Instead the primary purpose is to improve the performance of the HTTP protocol, especially “end-user perceived latency, network and server resource usage,” and in part by “allow[ing] the use of a single connection from browsers to a Web site” [8]. The charter acknowledges that, among other aims, HTTP/2.0 is expected to include a method of negotiating between HTTP versions as well as between HTTP URLs and other protocols; header compression; server push; and multiplexing, which enables multiple streams to be open between one connection at the same time [7]. HTTP/2.0 is meant to stay similar enough to its predecessor, HTTP/1.1, that the same APIs and methods will still be applicable. However, it also builds heavily on SPDY, a protocol proposed by Google. SPDY offers many of the improvements planned for HTTP/2.0, including header compression, server push, and multiplexing [1]. In adddition, the protocol requires TLS. It has been available (albeit not standardized) for a couple of years in certain browsers, including Chrome, Firefox, and Opera [3]. Currently it is used by a limited but expanding set of Web sites, including Google, Twitter, Wordpress.com, and Facebook [5]. Of note, SPDY beat two other proposals including Microsoft's Speed+Mobility, which built heavily on SPDY but did not require pervasive TLS [12]. 2. To the Community 4 Isobel Redelmeier The Security Implications of HTTP/2.0 12/13/13 COMP116, Fall '13 An upgrade to HTTP may seem like an irrelevant concern to many, let alone its relative security to the present version. Few people in the industry were even particularly aware of the plans for HTTP/2.0 until the recent – and likely premature – announcement that it would require HTTP Secure (HTTPS) encryption across all Web resources accessed by way of it [13]. 1,2 Insofar as they are interested in jeeping their own data secure online, however, the security of HTTP is not a trivial matter. Corporations with any amount of confidential data available online need to be aware of any extra security measures that they need to take to ensure that confidentiality remains intact. Likewise, individuals should be aware of the risks to their privacy incurred by the use of certain Web sites and technologies. Even if a person is not responsible for an HTTP/2.0 server, they will still be likely to interact with one, and the technologically knowledgeable citizen will want to be aware of their environment online. Ultimately, anyone using the World Wide Web is only as secure as the Web itself is; and if the structure of the Web is changing, then the current security status quo may be in flux. 3. Action Items In the ensuing section I will examine a series of potential or known areas of vulnerability for HTTP/2.0. Of these, 3.3 through 3.8 are explicitly addressed in the current specification draft. The headlines of these subsections are borrowed directly from the specifications. 3.1 CRIME 1 Based on anecdotal evidence obtained through conversations with various persons in technological positions in the industry and in academia, as well as with others in the public; as well as a non-quantitative examination of the online and media responses. 2 As of writing time, the decision to enforce pervasive encryption remains unresolved and will be treated as such throughout the duration of this paper. 5 Isobel Redelmeier The Security Implications of HTTP/2.0 12/13/13 COMP116, Fall '13 Compression Ratio Info-leak Made Easy (CRIME) is a security exploit uncovered by Juliano Rizzo and Thai Duong.3 CRIME takes advantage of header compression at the time of certification renegotiation by following the same zlib pattern that the compression does, allowing an attacker to insert a dangerous path among the cookie byes that will allow them to obtain and read the cookie data. Because it involves header compression, CRIME requires a system in which both the server and the browser allow for this compression. CRIME was therefore relevant only with respect to TLS compression and SPDY at the time of its discovery. Furthermore, browsers such as Firefox, Chrome, and possibly others immediately took aims (thanks to advance warning from Rizzo and Duong) to mitigate the vulnerability by disabling header compression [6]. The current specifications of HTTP/2.0 still involve header compression, however, potentially leaving users vulnerable to the exploit. An attacker using CRIME “needs to be able to observe your network traffic and to be able to cause many arbitrary requests to be sent,” according to Adam Langley, who was involved in patching Chrome against the crime [10]. While these may seem like relatively unlikely conditions for most attackers, Matthew Green of Johns Hopkins University, in an interview with Ars Technica, posited that, “The CRIME attack is the nation-state attack. […] It's really something that Iran is going to do to try to find dissidents or China is going to do for the same reason. And it's a big deal because of that” [6]. CRIME is a significant enough vulnerability that HTTP/2.0 ought to take countermeasures against it beyond trusting browsers to provide sufficient patches for prevention. 3 Rizzo and Duong presented their findings at the 2012 Ekoparty Security Conference in Buenos Aires. Unfortunately, their paper could not be found online by this author at the time of writing. See [16] for their demonstration of the attack as performed against Stripe. 6 Isobel Redelmeier The Security Implications of HTTP/2.0 12/13/13 COMP116, Fall '13 Please see the accompanying material for a brief demonstration of how CRIME can crack compressed cookies. 3.2 Multiplexing Multiplexing, as mentioned previously, allows there to be multiple streams simultaneously open and active across the same connection. While multiplexing has been available for the Transmission Control Protocol (TCP), which provides error-checking of data sent between computers and protocols and is typically used by HTTP in the transport layer, since 1981, it was not implemented for HTTP/1.1 [4, 17]. It is, however already a significant component of SPDY. HTTP/2.0 will most likely adapt the SPDY implementation. Multiplexing does not currently appear to introduce any new security considerations. Nevertheless, it may be worth it to investigate whether the increase in streams over the same connection increases opportunities for attackers to exploit vulnerabilities in TLS or any other form of encryption that HTTP/2.0 users implement.
Load more

Recommended publications
  • HTTP Cookie - Wikipedia, the Free Encyclopedia 14/05/2014
    HTTP cookie - Wikipedia, the free encyclopedia 14/05/2014 Create account Log in Article Talk Read Edit View history Search HTTP cookie From Wikipedia, the free encyclopedia Navigation A cookie, also known as an HTTP cookie, web cookie, or browser HTTP Main page cookie, is a small piece of data sent from a website and stored in a Persistence · Compression · HTTPS · Contents user's web browser while the user is browsing that website. Every time Request methods Featured content the user loads the website, the browser sends the cookie back to the OPTIONS · GET · HEAD · POST · PUT · Current events server to notify the website of the user's previous activity.[1] Cookies DELETE · TRACE · CONNECT · PATCH · Random article Donate to Wikipedia were designed to be a reliable mechanism for websites to remember Header fields Wikimedia Shop stateful information (such as items in a shopping cart) or to record the Cookie · ETag · Location · HTTP referer · DNT user's browsing activity (including clicking particular buttons, logging in, · X-Forwarded-For · Interaction or recording which pages were visited by the user as far back as months Status codes or years ago). 301 Moved Permanently · 302 Found · Help 303 See Other · 403 Forbidden · About Wikipedia Although cookies cannot carry viruses, and cannot install malware on 404 Not Found · [2] Community portal the host computer, tracking cookies and especially third-party v · t · e · Recent changes tracking cookies are commonly used as ways to compile long-term Contact page records of individuals' browsing histories—a potential privacy concern that prompted European[3] and U.S.
    [Show full text]
  • <Document Title>
    TLS Specification for Storage Systems Version 1.0.1 ABSTRACT: This document specifies the requirements and guidance for use of the Transport Layer Security (TLS) protocol in conjunction with data storage technologies. The requirements are intended to facilitate secure interoperability of storage clients and servers as well as non-storage technologies that may have similar interoperability needs. This document was developed with the expectation that future versions of SMI-S and CDMI could leverage these requirements to ensure consistency between these standards as well as to more rapidly adjust the security functionality in these standards. This document has been released and approved by the SNIA. The SNIA believes that the ideas, methodologies and technologies described in this document accurately represent the SNIA goals and are appropriate for widespread distribution. Suggestion for revision should be directed to http://www.snia.org/feedback/. SNIA Technical Position November 20, 2014 USAGE The SNIA hereby grants permission for individuals to use this document for personal use only, and for corporations and other business entities to use this document for internal use only (including internal copying, distribution, and display) provided that: 1. Any text, diagram, chart, table or definition reproduced shall be reproduced in its entirety with no alteration, and, 2. Any document, printed or electronic, in which material from this document (or any portion hereof) is reproduced shall acknowledge the SNIA copyright on that material, and shall credit the SNIA for granting permission for its reuse. Other than as explicitly provided above, you may not make any commercial use of this document, sell any or this entire document, or distribute this document to third parties.
    [Show full text]
  • Tracking Users Across the Web Via TLS Session Resumption
    Tracking Users across the Web via TLS Session Resumption Erik Sy Christian Burkert University of Hamburg University of Hamburg Hannes Federrath Mathias Fischer University of Hamburg University of Hamburg ABSTRACT modes, and browser extensions to restrict tracking practices such as User tracking on the Internet can come in various forms, e.g., via HTTP cookies. Browser fingerprinting got more difficult, as trackers cookies or by fingerprinting web browsers. A technique that got can hardly distinguish the fingerprints of mobile browsers. They are less attention so far is user tracking based on TLS and specifically often not as unique as their counterparts on desktop systems [4, 12]. based on the TLS session resumption mechanism. To the best of Tracking based on IP addresses is restricted because of NAT that our knowledge, we are the first that investigate the applicability of causes users to share public IP addresses and it cannot track devices TLS session resumption for user tracking. For that, we evaluated across different networks. As a result, trackers have an increased the configuration of 48 popular browsers and one million of the interest in additional methods for regaining the visibility on the most popular websites. Moreover, we present a so-called prolon- browsing habits of users. The result is a race of arms between gation attack, which allows extending the tracking period beyond trackers as well as privacy-aware users and browser vendors. the lifetime of the session resumption mechanism. To show that One novel tracking technique could be based on TLS session re- under the observed browser configurations tracking via TLS session sumption, which allows abbreviating TLS handshakes by leveraging resumptions is feasible, we also looked into DNS data to understand key material exchanged in an earlier TLS session.
    [Show full text]
  • TLS Security Upgrade Effective Thursday, May 3, 2018
    TLS Security Upgrade Effective Thursday, May 3, 2018 You May Need to Upgrade Your Browser/Operating System to Ensure Online and Mobile Banking Functionality. Apple Bank is informing you of a change to our security protocol. We will be officially retiring TLS 1.0 security protocol support on all of our services and upgrading to TLS 1.1 or higher to align with industry best practices and ensure that your data continues to be highly secure. TLS stands for “Transport Layer Security.” It is a protocol that provides privacy and data integrity between two communicating applications. It’s the most widely deployed security protocol used today, and is used for web browsers and other applications that require data to be securely exchanged over a network. On or before May 3, 2018, we will disable the TLS 1.0 encryption protocol, which may prevent users like you from accessing some or all of your online and mobile banking functionality. This means that you may need to upgrade your browser/operating system to disable TLS 1.0 and use TLS 1.1 or higher. This security upgrade will not affect you in any other way. We want to make this process as smooth as possible for you with specific instructions below. Our primary goal for users is to maintain the highest possible security standards and help keep your data secure. Depending on your browser/device, you may need to upgrade to the following versions that support TLS 1.1 or higher. Browser • Microsoft Internet Explorer (IE): version 11 and higher • Microsoft Edge: all versions • Mozilla Firefox: version
    [Show full text]
  • Torward: DISCOVERY, BLOCKING, and TRACEBACK of MALICIOUS TRAFFIC OVER Tor 2517
    IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, VOL. 10, NO. 12, DECEMBER 2015 2515 TorWard: Discovery, Blocking, and Traceback of Malicious Traffic Over Tor Zhen Ling, Junzhou Luo, Member, IEEE,KuiWu,Senior Member, IEEE, Wei Yu, and Xinwen Fu Abstract— Tor is a popular low-latency anonymous communi- I. INTRODUCTION cation system. It is, however, currently abused in various ways. OR IS a popular overlay network that provides Tor exit routers are frequently troubled by administrative and legal complaints. To gain an insight into such abuse, we designed Tanonymous communication over the Internet for and implemented a novel system, TorWard, for the discovery and TCP applications and helps fight against various Internet the systematic study of malicious traffic over Tor. The system censorship [1]. It serves hundreds of thousands of users and can avoid legal and administrative complaints, and allows the carries terabyte of traffic daily. Unfortunately, Tor has been investigation to be performed in a sensitive environment such abused in various ways. Copyrighted materials are shared as a university campus. An intrusion detection system (IDS) is used to discover and classify malicious traffic. We performed through Tor. The black markets (e.g., Silk Road [2], an comprehensive analysis and extensive real-world experiments to online market selling goods such as pornography, narcotics validate the feasibility and the effectiveness of TorWard. Our or weapons1) can be deployed through Tor hidden service. results show that around 10% Tor traffic can trigger IDS alerts. Attackers also run botnet Command and Control (C&C) Malicious traffic includes P2P traffic, malware traffic (e.g., botnet servers and send spam over Tor.
    [Show full text]
  • Designing a Better Browser for Tor with BLAST
    Designing a Better Browser for Tor with BLAST Tao Wang Department of Computer Science and Engineering Hong Kong University of Science and Technology [email protected] Abstract—Tor is an anonymity network that allows clients unwilling to trade off utility for its better privacy. Having to browse web pages privately, but loading web pages with more users improves the anonymity of Tor Browser by creating Tor is slow. To analyze how the browser loads web pages, we larger anonymity sets, reducing the chance that eavesdroppers examine their resource trees using our new browser logging and could deanonymize a Tor user using side information. simulation tool, BLAST. We find that the time it takes to load a web page with Tor is almost entirely determined by the number Anonymity network optimization is a well-studied privacy of round trips incurred, not its bandwidth, and Tor Browser problem with a decade of research, generally focused on incurs unnecessary round trips. Resources sit in the browser Tor [4], [5], [12], [14], [18]. Researchers have proposed various queue excessively waiting for the TCP and TLS handshakes, each solutions to optimize Tor’s performance on the network level of which takes a separate round trip. We show that increasing so as to improve user experience. On the other hand, the resource loading capacity with larger pipelines and even HTTP/2 problem of browser design for anonymity networks remains do not decrease load time because they do not save round trips. academically untouched, with many open problems that are We set out to minimize round trips with a number of protocol just as significant for user experience as network design and browser improvements, including TCP Fast Open, optimistic problems.
    [Show full text]
  • Warptcptm SPDY
    What Warp TCP TM does for SPDY WHITE PAPER Turbcharge Web Performance BADU networks - Improving the way the world connects - WarpTCP TM & SPDY Web performance is increasingly becoming a key focal point One among them is SPDY – a companion protocol to HTTP for many web properties. There are several approaches to that is aimed at reducing web page load latency and improv- help deliver rich, dynamic content with significantly lower ing web security among other things. latencies and improved user experience. Google’s “Make the Web Faster” initiative has proposed several techniques to This document describes how SPDY and Badu technology can improve web performance. These techniques are currently be combined to boost web performance. The approaches are being evaluated for inclusion in future standards. different but complementary to each other and can be implemented individually or together for maximum benefit. * The following diagram illustrates where SPDY and WarpTCP™ sit in the network protocol stack. Application Layer Web Cloud Computing Video File Transfer Amazon AWS HTML JS CSS H.264 MP4 Flash - EC2, S3 HTTP HTTP/REST/SOAP RTSP RTMP HLS FTP SCP SPDY Presentation Layer SSL Transport Layer WarpTCPTM SPDY SPDY operates at the Application/Session Layer. SPDY does not replace HTTP; it modifies the way HTTP requests and responses are sent over the Internet. This means that all the existing server-side applications can be used without modification if a SPDY-compatible translation layer is put in place. SPDY is similar to HTTP, with particular goals to reduce web page load latency and improve web security. SPDY achieves reduced latency through compression, multiplexing, and prioritization.
    [Show full text]
  • How Speedy Is SPDY?
    How Speedy is SPDY? Xiao Sophia Wang, Aruna Balasubramanian, Arvind Krishnamurthy, and David Wetherall, University of Washington https://www.usenix.org/conference/nsdi14/technical-sessions/wang This paper is included in the Proceedings of the 11th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’14). April 2–4, 2014 • Seattle, WA, USA ISBN 978-1-931971-09-6 Open access to the Proceedings of the 11th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’14) is sponsored by USENIX How speedy is SPDY? Xiao Sophia Wang, Aruna Balasubramanian, Arvind Krishnamurthy, and David Wetherall University of Washington Abstract provides only a modest improvement [13, 19]. In our SPDY is increasingly being used as an enhancement own study [25] of page load time (PLT) for the top 200 to HTTP/1.1. To understand its impact on performance, Web pages from Alexa [1], we found either SPDY or we conduct a systematic study of Web page load time HTTP could provide better performance by a significant (PLT) under SPDY and compare it to HTTP. To identify margin, with SPDY performing only slightly better than the factors that affect PLT, we proceed from simple, syn- HTTP in the median case. thetic pages to complete page loads based on the top 200 As we have looked more deeply into the performance Alexa sites. We find that SPDY provides a significant im- of SPDY, we have come to appreciate why it is chal- provement over HTTP when we ignore dependencies in lenging to understand. Both SPDY and HTTP perfor- the page load process and the effects of browser compu- mance depend on many factors external to the protocols tation.
    [Show full text]
  • The Fundamentals of Http/2 the Fundamentals of Http/2
    Ali Jawad THE FUNDAMENTALS OF HTTP/2 THE FUNDAMENTALS OF HTTP/2 Ali Jawad Bachelor’s Thesis June 2016 Information Technology Oulu University of Applied Sciences ABSTRACT Oulu University of Applied Sciences Degree Programme, Option of Internet Services Author: Ali Jawad Title of the bachelor’s thesis: Fundamentals Of HTTP/2 Supervisor: Teemu Korpela Term and year of completion: June 2016 Number of pages: 31 The purpose of this Bachelor’s thesis was to research and study the new ver- sion of HTTP ”HTTP2.0”, which is considered to be the future of the web. Http/2 is drawing a great attention from the web industry. Most of the Http/2 features are inherited from SPDY. This thesis shows how HTTP/2 enables a more efficient use of network re- sources and a reduced perception of latency by introducing a header field com- pression and allowing multiple concurrent exchanges on the same connection ”multiplexing” and more other features. Also, it discusses the security of Http/2 and the new risks and dangerous at- tacks that resurfaces with the arrival of this new protocol version. The simulation results show how HTTP/2 influences the page load time compar- ing to the other previous versions of HTTP. Keywords: HTTP1, HTTP/2, SPDY, SNI, DOS, CRIME, Downgrade-attack. 3 PREFACE This thesis was written for Oulu University of Applied Sciences and done during 1 February – 23 May 2016. The role of the instructor was guiding the thesis from the requirements and bases of writing a thesis document through meet- ings. The role of the supervisor was instructing the thesis plan and its require- ments which were done by the author.
    [Show full text]
  • Instructions for Setting TLS 1.2
    Instructions for Setting TLS 1.2 In order to better protect your agency’s financial transactions, ASAP.gov is updating its minimum computer and internet browser requirements. Starting in August 2016, ASAP.gov will no longer support Transport Layer Security (TLS) 1.0 and 1.1. As a result, your computers need to use an operating system and internet browser that supports TLS 1.2. As outlined in the table below, organizations using Windows 7 or above must ensure their internet browsers support TLS 1.2. Computers using either a Windows XP or Vista operating system or an Internet Explorer version prior to version 8 will become unsupported. Minimum Computer Software Required to use ASAP.gov Software Supported Unsupported (no longer able to use ASAP.gov) Operating System Windows 7 and above Windows XP or Vista Internet Browser Browsers that support TLS 1.2 Internet Explorer version 7 or below The ASAP.gov team is providing this information now so you can start updating internet browsers and changing workstation security policies today. The following are a condensed list of instructions for adjusting the settings of supported internet browsers. Please communicate this change to your recipient organizations so they too can start today. Internet Explorer Instructions 1. Select [Tools] from the menu bar 2. Select [Internet Options] 3. Click on the [Advanced] tab. 4. Scroll down and determine if the “Use TLS v 1.0”, “Use TLS v 1.1”, and “Use TLS v 1.2” boxes are selected. If they are not selected, select them. This ensures your browser is able to use the most secure connection ASAP.gov.
    [Show full text]
  • Privacy and Performance Trade-Offs in Anonymous Communication
    Privacy and Performance Trade-offs in Anonymous Communication Networks A DISSERTATION SUBMITTED TO THE FACULTY OF THE GRADUATE SCHOOL OF THE UNIVERSITY OF MINNESOTA BY John D. Geddes IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF Doctor of Philosophy Nicholas J. Hopper February, 2017 c John D. Geddes 2017 ALL RIGHTS RESERVED Acknowledgements There are a great many people who I owe a debt of gratitude for their support during this dissertation. First and foremost is my advisor Nick Hopper, who not only helped contribute and shape this work, but provided endless guidance and encouragement from start to finish. I would like to thank all my collaborators and co-authors { Rob Jansen, Max Schuchard, and Mike Schliep. Your input and contributions have been paramount to getting me here, and this work is undeniabley better off because of it. Additionally I want to thank everyone I have had the great pleasure to work with during my tenure in graduate school { Shuai Li, Zi Lin, Yongdae Kim, Denis Foo Kune, Aziz Mohaisen, Se Eun Oh, Micah Sherr, Paul Syverson, Chris Thompson, and Chris Wacek. I would like to thank my other committee members { Stephen McCamant, Andrew Odlyzko, and Jon Weissman { for their comments and time volunteered during this process. I would especially like to thank my parents and brother who have been there since the beginning. Never in a million years could I have accomplished this without your continous support and encouragement. And last but certainly not least, I thank my best friend and wife, Dominique. This work would not exist without you and your never ending support.
    [Show full text]
  • An Analysis of the SPDY Protocol and the SPDY Proxy
    April 2014 An Analysis of the SPDY Protocol and the SPDY Proxy Executive Summary Web-based commerce and content continues to grow, with mobile devices accounting for an increasing portion of network traffic. In a bid to enhance the speed of the web, browser and application developers are implementing new protocols to improve performance. At the same time, end-to-end encryption is increasing being used to improve user privacy and security. Google’s SPDY, described as “an experimental protocol for a faster web”, is one of the new protocols being introduced to reduce web page load times. Deployment is increasing, but as of today many web servers still do not support SPDY. To accelerate adoption of the protocol, SPDY proxy services have been deployed to offer some of the benefits of SPDY even when downloading content from web servers that have not yet implemented the SPDY protocol. However, by bundling multiple requests and encrypting all web traffic for a user inside a single connection, the SPDY proxy creates an opaque tunnel, hiding the true source of the content and breaking network management, content distribution, and many services offered by the network operators. This would be equally true for any proxy service that bundled all traffic from a given user inside an opaque tunnel, irrespective of the protocol used. The Problem Web content is becoming more complex both in size and in the number of separate connections/requests. Web pages are dominated by images and scripts, both of which are easily compressible, but are not compressed by current implementations. Mobile devices over wireless networks are constrained in terms of bandwidth and latency.
    [Show full text]