That's the Way the Cookie Crumbles: Evaluating HTTPS Enforcing

That’s the Way the Cookie Crumbles: Evaluating HTTPS Enforcing Mechanisms

Suphannee Sivakorn Angelos D. Keromytis Jason Polakis Columbia University Columbia University University of Illinois at Chicago New York, NY, USA New York, NY, USA Chicago, IL, USA [email protected] [email protected] [email protected]

ABSTRACT 1. INTRODUCTION Recent incidents have once again brought the topic of en- SSL/TLS offer significant protection and are fundamen- cryption to public discourse, while researchers continue to tal components for securing our communications. Unfortu- demonstrate attacks that highlight the difficulty of imple- nately, a recent study [27] found that the majority of top web menting encryption even without the presence of“backdoors”. services do not support ubiquitous encryption and expose However, apart from the threat of implementation flaws in their users to HTTP cookie hijacking. Its findings exposed encryption libraries, another significant threat arises when a sad state of affairs, as major services like Google, Bing and web services fail to enforce ubiquitous encryption. A recent Yahoo fail to fully utilize existing security mechanisms and study explored this phenomenon in popular services, and protect their users. demonstrated how users are exposed to cookie hijacking at- Even though surveys report that 40.5% of popular web- tacks with severe privacy implications. sites now support HTTPS [29], many websites do not enforce Many security mechanisms purport to eliminate this prob- ubiquitous encryption which leads to the significant privacy lem, ranging from server-controlled options such as HSTS threats demonstrated in recent work [16, 27, 34]; users are to user-controlled options such as HTTPS Everywhere and vulnerable to surveillance and information leakage through other browser extensions. In this paper, we create a taxon- non-secure cookies, as well as exposed account functionality omy of available mechanisms and evaluate how they perform and potential account takeover. in practice. We design an automated testing framework for Migrating to HTTPS is a daunting task with multifaceted, these mechanisms, and evaluate them using a dataset of 30 yet diminishing, costs [23], which has resulted in a tangled days of HTTP requests collected from the public wireless web of partial support of encryption across websites and network of our university’s campus. We find that all mecha- flawed access control [26]. Many security mechanisms have nisms suffer from implementation flaws or deployment issues been proposed [13, 18, 19] for enforcing encryption in on- and argue that, as long as servers continue to not support line communications, ranging from server-side mechanisms ubiquitous encryption across their entire domain (including to client-side solutions. The main server-side mechanism is all subdomains), no mechanism can effectively protect users HTTP Strict Transport Security (HSTS) which was stan- from cookie hijacking and information leakage. dardized and specified in RFC 6797 [18]. While HSTS is gaining traction, this technology is still in a relatively early CCS Concepts state of adoption, with a recent study also showing that many sites deploy the protocol incorrectly [20]. All this •Security and Privacy → Web protocol security; Browser has necessitated the emergence of client-side mechanisms, security; Privacy protections; •Networks → Network pri- which take the form of browser extensions that allow users vacy and anonymity; to better protect themselves against server-side omissions or errors. HTTPS Everywhere [13], which is the most popular Keywords option, was implemented by Tor and the Electronic Frontier Foundation (EFF) and modifies HTTP requests to HTTPS Web Security; Privacy; Eavesdropping; HTTPS; HTTP Strict based on a set of community-written rulesets. Transport Security; HTTPS Everywhere In this paper we study existing security mechanisms and defenses, both server- and client-side, explore their modus operandi, and evaluate their effectiveness in enforcing HTTPS and preventing cookie hijacking attacks. We study available mechanisms that are already deployed by web services Permission to make digital or hard copies of all or part of this work for personal or or can be deployed by end users without requiring server classroom use is granted without fee provided that copies are not made or distributed modification1. While one might expect that enforcing en- for profit or commercial advantage and that copies bear this notice and the full cita- cryption is fairly straightforward, as simple as adding an “s” tion on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re- in “http://”, in practice enforcing encryption is far more publish, to post on servers or to redistribute to lists, requires prior specific permission complicated, confirmed by the fact that we discovered is- and/or a fee. Request permissions from [email protected]. sues in every mechanism we inspected. Our study focuses WPES’16, October 24 2016, Vienna, Austria on HSTS and HTTPS Everywhere as they are the most c 2016 ACM. ISBN 978-1-4503-4569-9/16/10. . . $15.00 1 DOI: http://dx.doi.org/10.1145/2994620.2994638 Thus, we omit mechanisms like tcpcrypt [7]. widely adopted server- and client-side mechanisms, respec- 2.1 HSTS tively, but also explores lesser-used options such as upgrad- The HTTP Strict Transport Security (HSTS) mechanism ing insecure connections through CSP, and several browser enables websites to instruct browsers to only establish con- extensions with varying popularity. nections to their servers over HTTPS. It is specified in RFC Our experimental approach lies in empirically identify- 6797 published in 2012 [18]. The policy is declared from ing instances where each mechanism fails to instruct the the web servers via the Strict-Transport-Security HTTP browser to connect over an encrypted channel, and under- header field. To enforce this, the browser maintains a record standing the underlying pathology. At the core of our study of the sites that have responded with an HSTS header. Then lies a dataset of approximately 1.4 billion HTTP requests if the domain the user is connecting to matches a record, the collected from the public wireless network of Columbia Uni- browser will redirect itself (through a 307 Internal Redi- versity’s campus over the period of one month, which allows rect) or directly modify hyperlinks to HTTPS. This cov- us to extensively simulate real-world user browsing behavior. ers any request that would normally be transmitted over We extract the target URLs, and process them with our test- HTTP. HSTS is currently supported by approximately 75% ing framework that validates and analyzes the presence of of browsers [10]. While this mechanism is gaining significant the server-side mechanisms, and also replicates the function- traction, a recent study [20] reported that only 1.1% of the ality of the client-side solutions. Subsequently, we inspect all top 1 million Alexa sites set an HSTS header. instances of unencrypted connections observed, and conduct HSTS Header. The HSTS header in the server’s re- an in-depth analysis of unencrypted connections towards do- sponse contains the following attributes. mains that have adopted mechanisms for enforcing HTTPS. : this directive instructs the user’s browser for how Among other issues, we have identified deployment issues in max-age long to cache the HSTS policy after the receiving the HSTS the HSTS preload list for the default browser in iOS, even header, i.e., for how many seconds to maintain an entry for in the latest available version of the browser, which results specific domain. This value is updated after each received in significantly reduced coverage. We study client-side solu- response from the given domain. tions and identify their design flaws that result in incorrectly handled unencrypted connections. To our knowledge, this includeSubdomains: this optional flag indicates whether is the first study that offers a comprehensive evaluation of the HSTS policy will be applied not only to this domain, HTTPS enforcing mechanisms by also studying client-side but also all the subdomains. mechanisms. The main contributions of this paper are: preload: this optional flag specifies whether the site is • We provide a taxonomy, and conduct a comprehensive currently in the HSTS preload list (see below) or under experimental evaluation, of existing security mecha- submission to the preload list. nisms that force connections over HTTPS or block 2.1.1 HSTS Preloading connections over HTTP, including server-side mechanisms like HSTS and client-side solutions like HTTPS While technically HSTS preload lies on the client-side and Everywhere. is enforced by the browser, the server has to fulfill a set of requirements and apply for inclusion within the list. Thus, • Using a real dataset of 1.4 billion HTTP requests from we categorize this mechanism as a server-controlled solution. the public WiFi network of our university’s campus, we As HSTS instructs the browser to connect over HTTPS explore the server-side adoption of HTTPS enforcing after the request has been transmitted, i.e. in the response, mechanisms. Surprisingly, we find that Apple’s update the HSTS mechanism does not protect the initial request cycle for mobile browsers results in an outdated and towards a specific domain. While this is a significantly re- severely limited HSTS preload list, exposing users to duced attack window, nonetheless, users remain vulnerable eavesdropping and cookie hijacking attacks. during the initial connection. To rectify this, major browsers have adopted HSTS preloading. These browsers maintain a • We present an extensive analysis of HTTPS Every- list of domains that have a hard-coded HSTS policy, and do where, the most popular client-side mechanism for se- not rely on the HSTS header in the response for caching a curing user communications, which is also a default policy, thus protecting even the initial request. component of the Tor browser. We identify a series of In addition to upgrading traffic to HTTPS, HSTS preload- flaws in the rulesets that result in the mis-handling of ing is also used to enforce certificate pinning [25], which unencrypted connections and the subsequent exposure is designed to prevent attacks that employ rogue certifi- of users. cates [28]. However, this functionality is out of the scope of our study and, thus, we do not explore it in detail. 2. SERVER SECURITY MECHANISMS Chrome preload. The Chromium project is in charge Figure 1 presents our taxonomy of existing security mech- of maintaining the preload list which is shipped with the anisms, based on the endpoint that has to deploy the mech- Chrome browser [11]. Most of the domains contained in anism. As can be seen in the figure, a number of options the preload list have the force-https mode set. However, exist for both the server and end-user, which vary in terms some domains do not set that mode, indicating that they of breadth and effectiveness, as well as intended use. In this are assigned to the Opportunistic mode in Chrome. For section, we explore the mechanisms currently available to domains with the Opportunistic mode set, Chrome will servers for enforcing connections over HTTPS or preventing not enforce HTTPS, but will perform certificate pinning. If HTTP connections. the user connects over an encrypted channel (by explicitly typing “https://” in the address bar, or if the website redi- rects to HTTPS), Chrome will verify the certificate pinned in the preload list. HTTPS Enforcing Mechanisms

Server-controlled Client-controlled

Domain URL Domain URL

HSTS upgrade-insecure-requests Rule-based Heuristic Rule-based Heuristic

HSTS Preload block-all-mixed-content Redirect to HTTPS KB SSL Enforcer HTTPS Everywhere Smart HTTPS HSTS CSP HTTPtoHTTPS

Browser Extensions HTTPS by Default Figure 1: Taxonomy of HTTPS enforcing and HTTP blocking mechanisms.

To be added and remain on the HSTS preload list web- Table 1: Support of CSP directives in current ver- sites must satisfy a set of requirements set by the Chromium sion of major browsers. upgrade- block-all- project [2], which includes sending an HSTS header at all Browser times. The project also specifies ways to be removed from insecure-requests mixed-content the list, which has a slow turn-around time to reach the Firefox 47.0 Chrome 52.0 users, due to the manual nature of this process. Domains are Safari 9.1 also suggested to continue to serve an HSTS header without Opera 38.0 the preload directive and max-age set to 0. As the HSTS preload record does not sync, update or expire automati- cally during a domain transfer, new owners of domains will This can therefore mitigate threats by preventing insecure have to check and make sure that service is not accessibility requests from being transmitted over the network. How- is not disrupted due to the lack of support for HTTPS and ever, as webpages may reference resources that are hosted HSTS. Naturally, as adoption increases, this approach for on third party servers that do not support encryption, it populating the preload list will encounter significant scala- is not always feasible for a website to instruct the browser bility issues. to upgrade all connections to HTTPS without breaking the Firefox preload. Firefox currently builds a custom list user’s browsing experience. This can result in pages with that is derived from the entries in Chrome’s list that have mixed content. the force-https mode set, but filters out hosts that do not respond with valid HSTS header or do not meet certain requirements (e.g., set a max-age of less than 18 weeks). When 2.2.1 Mixed Content a mismatch is found between the HSTS policy in Chrome’s Mixed content occurs when content is referenced over an list, and the one returned by the server in the HSTS header, insecure HTTP connection within a page that is served over Firefox assigns higher priority to the one contained in the HTTPS [32]. The support for mixed content exposes users server response, and uses that policy in the preload list. Fur- to risks, as it allows man-in-the-middle attackers to change thermore, if a server responds with max-age=0, Firefox con- website functionality by modifying the HTTP request con- siders those sites to be knockout entries (e.g., a domain might tents of a webpage’s active resources, e.g., script (