On the Effective Prevention of TLS Man-in-the- Middle Attacks in Web Applications Nikolaos Karapanos and Srdjan Capkun, ETH Zürich https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/karapanos
This paper is included in the Proceedings of the 23rd USENIX Security Symposium. August 20–22, 2014 • San Diego, CA ISBN 978-1-931971-15-7
Open access to the Proceedings of the 23rd USENIX Security Symposium is sponsored by USENIX On the Effective Prevention of TLS Man-In-The-Middle Attacks in Web Applications
Nikolaos Karapanos and Srdjan Capkun Department of Computer Science, ETH Zurich firstname.lastname @inf.ethz.ch { }
Abstract ety of purposes, such as spying on the user [18, 48]. This In this paper we consider TLS Man-In-The-Middle attack is known as TLS Man-In-The-Middle (MITM). (MITM) attacks in the context of web applications, TLS server authentication is commonly achieved where the attacker is able to successfully impersonate through the use of X.509 server certificates. A server cer- the legitimate server to the user, with the goal of imper- tificate binds a public key to the identity of a server, des- sonating the user to the server and thus compromising ignating that this server holds the corresponding private the user’s online account and data. We describe in detail key. The browser accepts a certificate if it bears the signa- why the recently proposed client authentication protocols ture of any trusted Certificate Authority (CA). Browsers based on TLS Channel IDs, as well as client web authen- are typically configured to trust hundreds of CAs. tication in general, cannot fully prevent such attacks. An attacker can thus successfully impersonate a legit- Nevertheless, we show that strong client authentica- imate server to the browser by presenting a valid certifi- tion, such as Channel ID-based authentication, can be cate for that server, as long as she holds the correspond- combined with the concept of server invariance, a weaker ing private key. In previous years, quite a few incidents and easier to achieve property than server authentica- involving mis-issued certificates [2, 9, 11, 48, 49] were tion, in order to protect against the considered attacks. made public. Even in the case where the attacker simply We specifically leverage Channel ID-based authentica- presents an invalid (e.g., self-signed) certificate not ac- tion in combination with server invariance to create a cepted by the browser, she will still succeed in her attack novel mechanism that we call SISCA: Server Invariance if the user defies the browser’s security warning. with Strong Client Authentication. SISCA resists user In order to thwart such attacks, various proposals have impersonation via TLS MITM attacks, regardless of how emerged. Some proposals focus on enhancing the certifi- the attacker is able to successfully achieve server imper- cate authentication model. Their objective is to prevent sonation. We analyze our proposal and show how it can an attacker possessing a mis-issued, yet valid certificate, be integrated in today’s web infrastructure. from impersonating the server (e.g., [20, 33, 36, 52]). Other proposals focus on strengthening client authen- 1 Introduction tication. Strong client authentication prevents user cre- Web applications increasingly employ the TLS pro- dential theft or renders it useless, even if the attacker tocol to secure HTTP communication (i.e., HTTP over can successfully impersonate the server to the user. One TLS, or HTTPS) between a user’s browser and the web such prominent proposal is Channel ID-based client au- server. TLS enables users to securely access and inter- thentication, introduced in 2012. TLS Channel IDs [4] act with their online accounts, and protects, among other are experimentally supported in Google Chrome and are things, common user authentication credentials, such as planned to be used in the second factor authentication passwords and cookies. Such credentials are considered standard U2F, proposed by the FIDO alliance [22]. weak; they are transmitted over the network and are sus- In this paper we show that Channel ID-based ap- ceptible to theft and abuse, unless protected by TLS. proaches, as well as web authentication solutions that Nevertheless, during TLS connection establishment, it focus solely on client authentication are vulnerable to is essential that the server’s authenticity is verified. If an attack that we call Man-In-The-Middle-Script-In-The- an attacker successfully impersonates the server to the Browser (MITM-SITB), and is similar to dynamic pharm- user, she is then able to steal the user’s credentials and ing [32] (see Section 4). This attack bypasses Channel subsequently use them to impersonate the user to the le- ID-based defenses by shipping malicious JavaScript to gitimate server. This way, the attacker gains access to the the user’s browser within a TLS connection with the at- user’s account and data which can be abused for a vari- tacker, and using this JavaScript in direct connections
USENIX Association 23rd USENIX Security Symposium 671 with the legitimate server to attack the user’s account. In other words, the attacker is able to successfully imper- Nevertheless, we show that TLS MITM attacks where sonate the server to the user. We distinguish between two the attacker’s goal is user impersonation can still be pre- types of MITM1 attackers. vented by strong client authentication, such as Channel The MITM+certificate attacker holds (i) a valid cer- ID-based authentication, provided that it is combined tificate for the domain of the target web server, binding with the concept of server invariance, that is, the re- the identity of the server to the public key, of which she quirement that the client keeps communicating with the holds the corresponding private key. The attacker, how- same entity (either the legitimate server, or the attacker) ever, has no access to the private key of the target web across multiple connections intended for the same server. server. This, for example, can happen if the attacker com- Server invariance is a weaker requirement than server au- promises a CA or is able to force a CA issue such a cer- thentication, and thus, it is easier to achieve as no ini- tificate. Such attacks have been reported in the recent tial trust is necessary. Building on this observation, we years [2, 9, 11, 48]. Moreover, in this category we also propose a solution called SISCA: Server Invariance with consider a weaker attacker that only holds (ii) an invalid Strong Client Authentication, that combines Channel ID- (e.g., self-signed) certificate. In this case, the attacker based client authentication and server invariance. will still succeed in impersonating the server to the user SISCA can resist TLS MITM attacks that are based if the latter ignores the security warnings of the browser2, on mis-issued valid certificates, as well as invalid certifi- which is a common phenomenon [51]. cates, requiring no user involvement in the detection of The MITM+key attacker holds the private key of the the attack (i.e., no by-passable security warnings when legitimate server. While we are not aware of publicized server invariance violation occurs). SISCA also thwarts incidents involving server key compromise, such attacks attackers that hold the private key of the legitimate server. are feasible, as the Heartbleed vulnerability in OpenSSL Contributions. In this work we analyze TLS MITM has shown [1], and can be very stealthy, remaining unno- attacks whose goal is user impersonation and make the ticed. Thus, they are well worth addressing [28, 30, 35]. following contributions. (i) We show, by launching a From the above it follows that the attacker is able to ob- MITM-SITB attack, that Channel ID-based client au- tain the user’s weak credentials, namely passwords and thentication solutions do not fully prevent TLS MITM HTTP cookies. She is not, however, able to compromise attacks; (ii) we further argue that effective prevention the user’s browser or his devices (e.g., mobile phones). of MITM-based user impersonation attacks requires 2.2 TLS Channel IDs strong user authentication and (at least) server invariance; (iii) we propose a novel solution that prevents MITM- Channel IDs is a recent proposal for strengthening based user impersonation, based on the combination of client authentication. It is a TLS extension, originally strong client authentication and server invariance; (iv) we proposed in [15] as Origin-Bound Certificates (OBCs). implement and evaluate a basic prototype of our solution. A refined version has been submitted as an IETF Internet- Draft [4]. Currently, Channel IDs are experimentally sup- 2 Channel ID-based Authentication and ported by Google’s Chrome browser and Google servers. MITM Attacks In brief, when the browser visits a TLS-enabled web server for the first time, it creates a new private/public 2.1 Attacker Model and Goals key pair (on-the-fly and without any user interaction) Attacker Goals. The attacker’s goal in a MITM attack and proves possession of the private key, during the TLS is typically to impersonate the user (victim) to the legit- handshake. This TLS connection is subsequently iden- imate server (e.g., a social networking, webmail, or e- tified by the corresponding public key, which is called banking website) in order to compromise the user’s on- the Channel ID. Upon subsequent TLS connections to line account and data. This is indeed the case where the the same web server, or more precisely, to the same web attacker wishes for example to spy on the user [18, 48], origin, the browser uses the same Channel ID. This en- or abuse his account for nefarious purposes, e.g., perform ables the web server to identify the same browser across fraudulent financial transactions. Alternatively, the at- multiple TLS connections. tacker could aim to only impersonate the server to the 2.2.1 Channel ID-Based Authentication user (and not the user to the server), such that she serves the user with fake content (e.g., fake news). In this paper, By Channel ID-based authentication we refer to the we focus on the first, more impactful, scenario. use of Channel IDs throughout the user authentication process, designed to thwart both types of MITM attack- Attacker Model. We adopt the attacker model consid- ers presented in Section 2.1 [4, 6], [13, 3]. ered by Channel IDs [4]. The adversary is able to posi- § § tion herself suitably on the network and perform a TLS 1We use the terms “TLS MITM” and “MITM” interchangeably. MITM attack between the user and the target web server. 2We use the term “browser” to refer to any “user agent” in general.
672 23rd USENIX Security Symposium USENIX Association PhoneAuth Channel ID
Auth.)Protocol Auth.)Protocol Set$Cookie) TLS TLS TLS
Channel)ID)witnessed) Channel)ID)of)the) by)the)server: ≠ browser: , : TLS Channel IDs
Figure 1: PhoneAuth and FIDO U2F; leveraging Channel IDs TLS TLS to secure the initial login against MITM attacks. , : TLS Channel IDs
Figure 2: Binding authentication tokens (e.g., cookies) to the Initial Login. When the user attempts to login to browser’s Channel ID (green). A MITM attacker who steals his online account for the first time from a particular such a cookie, cannot use it to impersonate the user, since the browser, the web server requires that the user authenti- attacker has a different Channel ID (red). cates using a strong second factor authentication device, as in PhoneAuth [13] and FIDO Universal 2nd Factor user. This is due to the way web applications are run (U2F) [22] protocols. These protocols leverage Chan- and interact with the servers, which differs from other nel IDs to secure the intial login process against MITM internet client-server protocols (e.g., IMAP over TLS). attacks. In brief, as part of the authentication protocol, In particular, web servers are allowed to send script- the second factor device compares the Channel ID of the ing code to the browser, which the latter executes within browser to the Channel ID of the TLS connection that the the security context of the web application (according server witnesses. If they are equal, then the browser is di- to the rules defined by the same-origin policy [5]). In rectly connected to the web server through TLS (because fact, client-side scripting and especially JavaScript, is the they share the same view of the connection), and thus foundation of dynamic, rich web applications that vastly there is no MITM attack taking place. On the other hand, improve user experience, and its presence is ubiquitous. if the Channel IDs differ, then the server is not directly Moreover, a browser can establish multiple TLS con- connected to the user’s browser. Instead, as shown in Fig- nections with the same server. In addition, a typical web ure 1, there is an attacker in the middle, and the device application loads resources, such as images and scripts, aborts the authentication protocol, stopping the attack. from multiple domains (cross-origin network access [5]). Subsequent Logins. Upon successful initial authentica- Assuming that all communication is TLS-protected, this tion the server sets a cookie to the user’s browser, and means that the browser needs to establish TLS connec- binds it to the Channel ID of the browser. As proposed tions with multiple servers while loading a web page. in [15], a server may create a channel-bound cookie as Given the above, there is a conceptually simple attack follows: v, HMAC(k,v cid) , where v is the original | that a MITM+certificate or MITM+key attacker can per- cookie value, cid is the browser Channel ID and k is a form, which bypasses the security offered by Channel secret key only known to the server, used for computing IDs. We assume that the user tries to access the target a MAC over the concatenation of v and cid. The channel- web server, say www.example.com. The attacker then bound cookie is considered valid only if it is presented proceeds as follows: over that particular Channel ID. Therefore, subsequent interaction with the server from that particular browser is 1. She intercepts a single TLS connection attempt protected by the channel-bound cookie. An attacker that made by the browser to www.example.com, and by manages to steal a channel-bound cookie, e.g., through presenting a valid certificate (or invalid with the user a MITM attack, cannot use it to impersonate the user to ignoring the browser’s warning), she successfully the web server, since she does not know the private key impersonates the legitimate server to the browser. of the correct Channel ID. Figure 2 illustrates this con- cept. Note that at this stage, the second factor device is 2. Through the established connection, the browser not required for authenticating the user [12]. makes an HTTP request to the server. The attacker replies with an HTTP response, which includes a 2.3 MITM Attack on Channel ID-Based malicious piece of JavaScript code. This script will Authentication execute within the origin of www.example.com. We show how Channel ID-based authentication still 3. The attacker closes the intercepted TLS connection. allows a MITM attacker to successfully impersonate the This forces the browser to initiate a new TLS con-
USENIX Association 23rd USENIX Security Symposium 673 Channel ID Attack
Phone Auth / U2F Attack
1. Intercept connection! 1. Intercept connection! 2. Push malicious script! 1 2. Push malicious script! 3. Close connection! 1 3. Close connection! HTTP 4. Gain control 4. Gain control 2 TLS 2 TLS 3 3 4 Auth.)Protocol 4 TLS TLS Channel)ID)witnessed) Channel)ID)of)the) by)the)server: browser: = Figure 4: MITM-SITB attack on Channel ID-based authentica- tion after the initial login, where requests are protected with a channel-bound cookie. Figure 3: MITM-SITB attack on Channel ID-based PhoneAu- th/U2F, used for the initial login. The attacker’s JavaScript code is executed within the origin of the target server (shown by the dotted arrow). hijack it. This ensures that the user authentication is per- formed over a direct connection between the browser and the server, but with the attacker’s code running in the nection in order to transmit subsequent requests, or browser. The view of the TLS channel will be the same use another existing one, if any (this behavior con- for the browser and the server, and the Channel ID com- forms with the HTTP specification [23]). At the parison made by the second factor device will pass. same time, the attacker allows subsequent TLS con- Figure 4 shows how the attack works in the case when nection attempts to pass through, without interfer- the user has already logged in on www.example.com in ing with them. As a result, once the attacker closes the past, and the server has set a channel-bound cookie that single intercepted connection, all other connec- in the user’s browser. Like before, the attacker ships ma- tions, existing and new, are directly established be- licious JavaScript code to the browser by intercepting a tween the browser and the legitimate server. TLS connection to www.example.com. She then termi- nates the intercepted connection. This forces the browser 4. The attacker gains full control over the user’s ses- to establish a new TLS connection, which is not inter- sion in that particular web application. Her script cepted by the attacker. This ensures that any subsequent has unrestricted access over the web documents be- requests, either legitimate or malicious (issued by the longing to www.example.com and can monitor all attacker’s script) are accepted by the legitimate server, the client-side activity of the web application. More- since they will carry the channel-bound cookie, which over, she can issue arbitrary malicious requests to authenticates the user, over the correct Channel ID. the target server using the XMLHttpRequest ob- ject [3], in order to perform a desired action or From the above attack description there are various extract sensitive user information. The malicious details that remain unclear. For example, which TLS code can upload any extracted data to an attacker- connection the attacker should intercept, whether to controlled server. As another example, if the web “hit and run” or persist as much as possible, etc. De- application is Ajax-based, the attacker can perform pending on the scenario, there are various alternatives, Prototype Hijacking [46]. This allows her to eaves- which are mostly implementation decisions. The at- drop and modify on-the-fly all the HTTP requests tacker can for example choose the following strategy. made through XMLHttpRequest. She intercepts the very first TLS connection, i.e., the one that the browser initiates once it is directed to In summary, the MITM attacker “transfers” herself www.example.com. Depending on the situation, the (via the malicious script) within the user’s browser, and attacker’s HTTP response could contain the expected continues her attack from there. We call this attack Man- HTML document of the website’s starting page, together In-The-Middle-Script-In-The-Browser (MITM-SITB). with the appropriately injected malicious script, or it Figure 3 illustrates the MITM-SITB attack in the could only contain the malicious script, which will take case when the user is about to initially authenti- care of loading the starting page in the browser. Then, as cate to www.example.com using PhoneAuth or U2F. described before, the attacker closes this first connection The attacker intercepts a TLS connection, pushes her and subsequent communication (malicious or not) takes JavaScript code to the user’s browser, and terminates place through a direct connection to the legitimate server. the connection. The browser then establishes a new The Cross-Origin Communication Case. Visiting a sin- TLS connection for subsequent communication, only gle web page typically involves cross-origin communica- this time with the legitimate server; the attacker will not tion with different domains in the background. For exam-
674 23rd USENIX Security Symposium USENIX Association 1. Fetch main page! 4. Forward request! web applications, it does not seem possible to prevent 2. Fetch external script! 5. Inject malicious script! 3. Intercept connection! 6. Gain control www.example.com TLS MITM attacks via client authentication alone. 1 GET)/),)Cookie:) We provide the following informal reasoning for the 200)OK) TLS above claim. Client authentication does not prevent an attacker from impersonating the legitimate server. This …
TLS 5 TLS tion), executes it within the target server’s origin. The at- tacker accesses the user’s account through requests initi- 6 ated by her code and transmitted over another, direct con- TLS nection between the browser and the legitimate server. As a result, schemes such as traditional TLS client au- Figure 5: MITM-SITB attack on Channel ID-based authentica- thentication [14] and TLS Session Aware User Authenti- tion leveraging cross-origin communication. Channel IDs for cation [42, 43] are still susceptible to TLS MITM attacks, static.example.com are of no use. via MITM-SITB. The attacker succeeds in impersonating the user to the web server and compromising his account. ple a typical network optimization technique is to have 3 Addressing TLS MITM Attacks the browser load the static resources of the website, such As shown in Section 2, strong client authentication as images, style sheets and scripts, from so-called cook- alone is not sufficient to prevent MITM attacks that lead ieless domains (e.g., Google websites usually load static to user impersonation in web applications. So, how can resources from gstatic.com [24]). These domains, as we effectively prevent such attacks? In this section we their name suggests, do not set any cookies, so as to min- show that there are two orthogonal solutions; (i) the imize network latency. As a matter of fact, on such do- known solution of preventing the attacker from imper- mains, client authentication does not apply at all, as they sonating the legitimate server at all, i.e., ensuring correct are just used to serve static resources, which anyone, in- server authentication; (ii) our novel approach of combin- cluding the attacker, can access. Hence in those cases, ing strong client authentication with server invariance. the attacker can perform a conventional MITM attack against a cookieless domain, and inject her malicious 3.1 Prevent Server Impersonation code at the moment when the target web server requests The known and straightforward solution to the prob- a legitimate JavaScript file from that domain (Figure 5). lem at hand is to prevent the attacker from impersonating 2.4 Proof of Concept Attack the server in the first place. This way, the attacker can neither steal weak user credentials in order to mount a We validate our attack against Channel IDs through a conventional MITM attack, nor ship malicious Javascript proof of concept implementation. We use two Apache in order to mount a MITM-SITB attack. Note that in TLS-enabled servers (one for the attacker, one for the this case, strong client authentication (e.g., Channel ID- legitimate server) and an interception proxy that can se- based) is not necessary for preventing MITM attacks (it lectively forward TLS connections to either server. The is, however, still useful for preventing other attacks, such legitimate server uses a patched OpenSSL version that as phishing and server password database compromise). supports Channel IDs and leverages them for creating The solutions that try to prevent server impersonation channel-bound cookies. We use Google Chrome as the essentially address the issue of forged server certificates user’s browser, since it supports Channel IDs, and ensure (and thus defeating MITM+certificate attacks), by per- that it accepts the certificates of both servers. We are then forming enhanced certificate verification. Such solutions able to inject JavaScript code to the user’s browser from are mainly based on pinning [20, 38], multi-path prob- the attacker’s server and issue HTTP requests that are ac- ing [33, 36, 37, 52] and hybrid approaches [19, 29] (a cepted and processed by the legitimate server. thorough survey can be found in [10]). 2.5 Scope and Implications of the Attack 3.2 Our Proposal: SISCA The MITM-SITB attack presented in Section 2.3 is not 3.2.1 Main Concept specific to Channel ID-based client authentication proto- cols. In fact, it applies to any web client authentication The fact that strong client authentication alone cannot method. This attack demonstrates that, in the context of effectively prevent MITM attacks in web applications,
USENIX Association 23rd USENIX Security Symposium 675 SISCA Overview
Conventional)MITM) as MITM+key attacks under the assumption that the at- prevented)by)strong) client)auth.)(e.g.,) tacker does not persistently compromise the server (see Channel)ID$based) Section 3.2.2). The details of our solution follow below. 3.2.2 Design Goals and Assumptions MITM$SITB)prevented) by)server)invariance In SISCA we seek to satisfy the following require- ments: (i) incremental deployment, (ii) scalability, (iii) minimal overhead, (iv) account for cross-origin com- munication, assuming that the involved origins belong to, Figure 6: TLS MITM attacks in web applications can be and are administered by the same entity, (v) mitigation of thwarted by combining strong client authentication with server MITM+key attacks (besides MITM+certificate attacks). invariance. We make the following assumptions. First, strong client authentication, which prevents the conventional way of implementing MITM attacks (Figures 1, 2) is raises the following question. Is there a way to some- in place. Specifically, we assume that SISCA-enabled how still benefit from strong client authentication with servers implement Channel ID-based client authentica- respect to addressing MITM attacks? tion. As mentioned before, Channel IDs are already ex- To answer, we make the following observation. In the perimentally supported in Google Chrome. Moreover, context of web applications, a MITM attacker can per- FIDO U2F leverages Channel IDs, as metiononed in Sec- form user impersonation via two approaches: tion 2.2.1, so it is likely that Channel ID-based authenti- cation will become available in the foreseeable future. 1. The conventional MITM attack, in which the at- Second, we assume that SISCA-enabled servers sup- tacker compromises the user’s credentials and uses port TLS with forward secrecy by default [28, 30, 35]. them for impersonation. This attack can be effec- As we discuss below, this is only required for preventing tively prevented by strong client authentication e.g., MITM+key attacks (not relevant for MITM+certificate using Channel ID-based protocols (Figures 1, 2). attacks). Moreover, we assume that TLS is secure and 2. The MITM-SITB attack, presented in Section 2.3 cannot be broken by cryptographic attacks, such as those (Figures 3, 4, 5). As discussed in Section 2.5, client surveyed in [10]. authentication alone cannot prevent this attack. We finally assume that the MITM+key attacker does not persistently compromise the target web server. As we For the MITM-SITB attack to be successful, the user’s discuss later, this enables SISCA to resist server key com- browser needs to communicate with two different enti- promise (i.e., MITM+key attackers) through frequent ro- ties, namely the attacker and the target web server. Com- tation of the server secrets that are used in SISCA (see municating with the attacker is, of course, necessary for Section 3.2.8). We also note that if an attacker gained injecting the attacker’s script to the browser through the persistent control over the target server, she would prob- intercepted TLS connection. In addition, communication ably not need to resort to MITM attacks to compromise with the target server is essential, so that the attacker ac- the users’ accounts, but at the same time she would in- cesses the user’s account and data, through her script. crease the probability of being detected. As a result, we can prevent MITM-SITB by making 3.2.3 Server Invariance Versus Authentication sure that the browser communicates only with one entity, either the legitimate server, or the attacker, but not with As stated above, our goal is to combine strong client both, during a browsing session (a browsing session is authentication with server invariance. Invariance is a terminated when the user closes the browser). In other weaker property than authentication, and thus, easier to words, we need to enforce server invariance. When com- achieve, as no a priori trust is necessary. In contrast, au- bined with strong client authentication (e.g., Channel ID- thentication requires some form of initial trust so that the based), which stops the conventional MITM approach, client can correctly authenticate the server [17]. this technique manages to effectively thwart MITM at- Consequently, we stress the following very important tacks. Figure 6 illustrates the concept. difference. Server authentication (and solutions that try In the remaining section we present a novel solution, to enforce it, like those mentioned in Section 3.1) implies called Server Invariance with Strong Client Authentica- that every single TLS connection should be established tion (SISCA), which stems from the above result. SISCA with the legitimate server. If the attacker attempts to in- is able to resist MITM+certificate attacks, offering ad- tercept such a connection, she should be detected by the vantages compared to existing solutions that focus at pre- browser, i.e., no server impersonation should be possible. venting server impersonation (see Section 3.2.9), as well In contrast, server invariance, embraces the fact that
676 23rd USENIX Security Symposium USENIX Association the attacker can successfully impersonate the server. implementing server invariance. As such, we distinguish two scenarios concerning the During initialization (first connection), the server browser’s first connection to a particular server: (i) The sends a list of all the involved domains and all their pub- first connection is not intercepted by the attacker. Then, lic keys to the browser, and the latter uses the witnessed server invariance implies that the attacker is allowed to in- key as well as the list as the point of reference. Then, in tercept none of the subsequent connections to that server. subsequent connections, the browser verifies (i) that the (ii) The first connection is intercepted by the attacker. public key which the server presents is contained in the Then, server invariance implies that the attacker has to list which was received during initialization, and (ii) that intercept all subsequent connections to that server. In the server agrees on the legitimacy of the public key that either scenario, if the attacker violates server invariance, was originally witnessed by the browser during initializa- she will be detected. tion. Notice how this differs from pinning, which oper- We consider server invariance as a transient property ates under the assumption that the initial connection is whose scope is one browsing session. Server invariance trusted, and thus does not seek to verify the legitimacy of is reset whenever the browser restarts, i.e., the attacker is the initial connection, and consequently of the received allowed again to choose whether to intercept or not the pins, upon subsequent connections. first connection to the server. The above technique is indeed useful when consider- ing MITM+certificate attacks and can be used to imple- 3.2.4 Towards Implementing Server Invariance ment the server invariance protocol in SISCA. Neverthe- In order to implement server invariance, it is impor- less, in the following sections we present an alternative tant to understand the implications of the fact that the approach that does not leverage server public keys, and attacker is allowed to impersonate the server. Namely, aims to mitigate MITM+key attacks, as well. We note the attacker can intercept the first connection and influ- that the security analysis as well as most of the design ence the entire HTTP response, which clearly cannot be patterns that are discussed in the approach that follows blindly trusted. Therefore, techniques that assume the (e.g., how to prevent downgrade attacks and allow for attacker is able to influence only a part of the HTTP re- partial support and exceptions – Section 3.2.6, how to sponse, such as Content Security Policy (CSP) [50] for secure resource caching – Section 3.2.7, etc) would simi- mitigating Cross-Site-Scripting (XSS) [44], as well as larly apply to the previously sketched technique, too. techniques that assume the first connection is trusted (i.e., Our High-Level Approach. In SISCA we choose to im- not intercepted by the attacker), such as pinning, cannot plement server invariance as a simple challenge/response be directly applied for implementing server invariance. protocol. In the initialization phase (first connection) the Instead, a server invariance protocol should consist browser sets up a fresh challenge/response pair (which of two phases, namely invariance initialization and in- acts as the point of reference) with the server. Then, variance verification – initialization and verification for in the verification phase (subsequent connections) the brevity. In the initialization phase, which is executed browser challenges the server to verify server invariance, in the first connection to the server during a browsing i.e., that it is the same entity with which the browser exe- session (and could be intercepted by the attacker), the cuted the initialization. browser establishes a point of reference. Then, in sub- SISCA has to be executed before any HTTP traffic in- sequent connections to the same server, the verification fluenced by the attacker is processed by the browser or phase is executed, where the browser verifies that the the server. We choose to implement the protocol at the point of reference remains unchanged, i.e., the browser application layer, over established TLS sessions via an keeps connecting to the same entity. HTTP header, named X-Server-Inv, and transmitted Server Public Keys. Assuming that we only consider together with the first HTTP request/response pair over a MITM+certificate attackers, we can leverage the servers’ particular TLS connection. For the protocol to be secure, public keys as the point of reference. Even if the attacker on the client side this header is controlled solely by the intercepts the first connection, she will not be able to let browser. It cannot be created or accessed programmati- any subsequent connections reach the legitimate server, cally via scripts (similar to cookie-related headers [3]). because the server’s public key will be different from the Alternatively, we could implement the server invari- attacker’s. Nevertheless, servers of the same domain may ance protocol in SISCA as a TLS extension, i.e., at the use different public keys and also, cross-origin interact- transport layer. We deem the application layer more ap- ing domains will have different keys. To solve this issue, propriate, since server invariance encompasses semantics we need to “tie” all the involved public keys together, to that are naturally offered by the application layer, such as reflect the fact that they belong to the same entity and cross-origin interaction and content inclusion. thus server invariance should hold across all these do- Figure 7 depicts a simple example of how a protocol mains and keys. We sketch the following technique for based on our approach can look like. In this example
USENIX Association 23rd USENIX Security Symposium 677 Server Invariance - state at the server Server Invariance
1. Initialization! 1a, 2a: First HTTP request! 1. Initialization! 1a, 2a: First HTTP request! 2. Verification 1b, 2b: First HTTP response 2. Verification 1b, 2b: First HTTP response
1 1 Keys ks1, ks2 rb 1a rb 1a rs ‘Init’, rb rs ‘Init’, rb t1 = MAC(ks1,‘1’|rb|rs|cidb) store: [rb, cidb, rs] 1b rs rs rs, t1, t2 rs, t1, t2 1b t2 = MAC(ks2,‘2’|rb|rs|cidb) TLS TLS cidb cidb (forget t1, t2, rb, rs, cidb) 2 2 2a ‘Verify’, rb 2a ‘Verify’, rb, rs, t1 t1 ≟ MAC(ks1,‘1’|rb|rs|cidb) lookup: r′s from [rb, cidb] rs ≟ r′s r′s 2b t2 ≟ t′2 t′2 2b t′2 = MAC(ks2,‘2’|rb|rs|cidb) TLS TLS cidb cidb
Figure 7: An example challenge/response-based server invari- Figure 8: Basic SISCA protocol. ance protocol requiring per-client server state.
mentioned, the protocol consists of two phases. protocol, during the initialization phase the browser and Initialization. The initilization phase occurs server generate random numbers rb and rs, which they once the browser establishes a TLS connection to both store (the server also stores the browser’s Chan- www.example.com, for the first time in a browsing nel ID cidb). The browser subsequently uses rb as a session (upper connection in Figure 8). The browser picks a random number r . It then sends ‘Init’,r to challenge during the verification phase, expecting the re- b b sponse rs by the server. The latter looks up rs by using rb the server (‘Init’ is a string constant), within the first 3 and cidb. For the shake of brevity, we do not analyze this HTTP request over that connection. Upon receiving example, but we make the following important remarks. this message, the server chooses a random number rs and First, this example requires the server to store per- computes the following message authentication tags: client state. This may be undesirable and it also makes it t = MAC(k ,‘1’ r r cid ) (1) harder for multiple servers belonging to the same entity 1 s1 | b| s| b t = MAC(k ,‘2’ r r cid ) (2) to share the common state which is needed in order to 2 s2 | b| s| b be able to correctly execute the protocol. For this reason, where ‘1’ and ‘2’ are strings constants. Notice that the SISCA uses symmetric cryptography (MAC), in order to server binds the computed tags to the browser’s Channel securely offload the state to the clients. ID cidb. rb, rs and the MAC tags will be used in subse- Second, during the verification phase, the server quent TLS connections to verify server invariance. should process the incoming HTTP request, only if the Finally, the server sends r ,t ,t to the browser s 1 2 lookup succeeds. If it fails, it means that the attacker within its first HTTP response. The browser stores intercepted the first connection (initialization phase) and r ,r ,t ,t , while the server does not store any client- b s 1 2 that the incoming request may be malicious. We explain specific information. At this point, the initialization this concept further in the analysis of the SISCA protocol. phase is complete. Subsequent HTTP requests and re- We note that due to this fact, SISCA uses a second MAC sponses over that particular TLS connection do not in- tag in order to enable the server perform this check. clude an X-Server-Inv header. 3.2.5 Basic Protocol Verification. The verification phase takes place upon ev- ery subsequent TLS connection to www.example.com, We now describe the server invariance protocol of which occurs within the same browsing session (lower SISCA in detail. We follow a structural approach, mean- connection in Figure 8). Like in the first phase, ing that we start with a basic version of our protocol, de- the protocol messages are exchanged within the first scribed in this section. Then, in subsequent sections, we HTTP request/response pair. The browser sends incrementally add features. ‘Veri f y’,r ,r ,t to the server, as part of the first re- b s 1 Figure 8 illustrates the protocol, assuming no at- quest. After receiving the request, and before processing tack. Prior to the protocol execution, the server, it, the server first checks if www.example.com, generates two keys ks1 and ks2, ? called SISCA keys. The same SISCA keys are used for t1 = MAC(ks1,‘1’ rb rs cidb). (3) all protocol executions (i.e., not for a specific client) and | | | are never disclosed to other parties. Moreover, recall that Here, cidb corresponds to the Channel ID of the TLS the server and client deploy Channel ID-based authentica- session within which the protocol is currently being exe- tion. Each TLS connection will therefore have a Channel 3Note that this is a request that browser would anyway submit, i.e., ID cidb, that is created by the user’s browser. As already required for loading the web page. It is not an extra request.
678 23rd USENIX Security Symposium USENIX Association Server Invariance - attacker second Server Invariance - attacker first
1. Initialization! 1a, 2a: First HTTP request! 1. Initialization! 1a, 2a: First HTTP request! 2. Verification 1b, 2b: First HTTP response 2. Verification 1b, 2b: First HTTP response
1 Keys ks1, ks2 1 Keys ka1, ka2 rs ra rb 1a ‘Init’, rb rb 1a ‘Init’, rb t1 = MAC(ks1,‘1’|rb|rs|cidb) t1 = … (Relaying computations to t2 = MAC(ks2,‘2’|rb|rs|cidb) t2 = … rs, t1, t2 rs, t1, t2 1b ra, t1, t2 ra, t1, t2 1b server doesn’t help, TLS TLS different Channel ID ) cidb cidb X$Server$Inv)header)out) of)attacker’s)control
2 Keys ka1, ka2 2 Keys ks1, ks2 2a ‘Verify’, rb, rs, t1 (cannot compute 2a ‘Verify’, rb, ra, t1 t′2 = … t1 ≠ MAC(ks1,‘1’|rb|ra|cidb) correct t′2) t2 ≠ t′2 t′2 2b ‘Alert’ 2b (cannot relay t′2 computation to TLS server, different Channel ID ) TLS cidb cidb (a) Attacker intercepts the verification phase. (b) Attacker intercepts the initialization phase.
Figure 9: Resilience of SISCA to MITM-SITB (conventional MITM is prevented by Channel-ID based authentication). cuted, which, if under attack, might differ from the Chan- After the browser establishes a connection with the nel ID that was used in the initialization phase. If the legitimate server, the two of them execute the verifica- check passes, the server computes tion phase, as part of the first HTTP request/response pair. The server, before processing the HTTP request t = MAC(k ,‘2’ r r cid ), (4) 2 s2 | b| s| b (which might as well be malicious), checks whether Con- processes the received request, and passes t within dition (3) is true. Since the attacker does not have ac- 2 the HTTP response to the browser. Finally, the browser cess to key ks1, she could not have computed the cor- ? checks if t2 = t2 and if it succeeds, it means that server rect t1 (Eq. (1)). Thus, during the initialization phase, invariance holds for this TLS connection. she sends a t1 value to the browser that is not the cor- Analysis When Under Attack. Figure 9 illustrates rect one. Consequently, Condition (3) will not be sat- how the protocol prevents MITM attacks. Recall that, isfied. In this case the server does not process the due to the usage of Channel ID-based authentication, request, and instead notifies the browser by sending the attacker cannot perform the conventional attack (Fig- an empty HTTP response containing ‘Alert’ in the ures 1, 2) – the attacker’s TLS sessions will have a differ- X-Server-Inv header. This indicates violation of the ent Channel ID than the client’s and will thus be rejected. server invariance and the browser aborts the session. Instead, she has to execute a MITM-SITB attack. We remark that in the second scenario, it is the legit- In Figure 9 we illustrate two possible attack scenarios imate server that checks server invariance, detects the (based on the discussion of Section 3.2.3) and we show ongoing MITM attack and notifies the browser. This is why the attacker fails in both. In Figure 9a the attacker important in order to prevent even a single malicious re- intercepts the verification phase of SISCA. Since the at- quest from being accepted and processed by the server. tacker didn’t participate in the initialization phase of the We conclude our analysis, with a few remarks that are protocol, she does not know the correct MAC response relevant for both of the scenarios described above. First, t2 to the client’s challenge. Moreover, since she does not note that the attacker cannot relay any of the necessary have access to ks2, she cannot calculate the correct t2 ei- MAC computations to the legitimate server. In other ther (Eq. (4)). As a result, the user’s browser rejects the words, she cannot manipulate the server to compute for attacker’s response and terminates the session, notifying her the values needed for cheating in the protocol. This is the user (no user decision is required). Even if the at- because the server binds all its computations to the chan- tacker pushes a malicious script in her response, it will nel ID of the client with whom it communicates (the at- not get a chance of being executed. tacker’s channel ID will be different from the user’s). In the second scenario, depicted in Figure 9b, Second, note that the protocol is secure so long as the the attacker intercepts the first TLS connection to attacker cannot “open” already established TLS connec- www.example.com. She thus executes the initialization tions between the browser and the legitimate server (i.e., phase with the browser and injects her script, which is ex- connections that she chose not to intercept). If she could ecuted within the web origin of www.example.com. To do that, she would be able to extract the correct values successfully complete her attack, the attacker needs to let of both t1 and t2 and successfully cheat. Recall that, the a subsequent TLS connection reach the legitimate server, MITM+key attacker holds the private key of the legiti- and access the user’s account via that connection. mate server. Therefore, in order to prevent such an at-
USENIX Association 23rd USENIX Security Symposium 679 Server Invariance - Different channel ID tacker from eavesdropping on already established TLS 1. Initialization! 1a, 2a: First HTTP request! 2. Verification 1b, 2b: First HTTP response connections, it is essential that these connections have www.example.com 1 Keys ks1, ks2 TLS forward secrecy enabled. s rb 1a ‘Init’, rb r Third, when considering MITM+key attacks it is rea- t1 = MAC(ks1,‘1’|rb|rs|cidb) sonable to assume that the attacker can also extract the rs, t1, t2 rs, t1, t2 1b t2 = MAC(ks2,‘2’|rb|rs|cidb) TLS SISCA keys, similar to the private key of the server. As cidb (pkb, skb) stated in the assumptions (Section 3.2.2) and explained …
680 23rd USENIX Security Symposium USENIX Association ecuted using cidb, the verification phase will have to be example.com. In such a case, the attacker can attack executed over a TLS connection with Channel ID cidb . the user account at shop.example.com, by intercepting As Figure 10 shows, the browser needs to tell the the first connection to www.example.com (or any other example.com server (examplestatic.com) to use cidb instead of cidb , subdomain), or vice versa. but do so in a secure way. To achieve this, the browser To prevent such an attack, the browser has to verify endorses cidb , by signing it with skb, and thus proving that server invariance holds across each pair of origins to the server that it owns the private keys of both Chan- that change their effective origin to a common value, be- nel IDs cidb and cidb . The browser extends the ‘Veri f y’ fore allowing any interaction between them. Each origin message by appending cidb and a signature over cidb (i.e., has its own SISCA instance established, and we must en- the Channel ID of that TLS connection) and the rest of sure that both SISCA instances were initialized with the the message parameters using skb. The server, before same remote entity. This can be achieved by running the processing the request, verifies the signature on cidb us- verification phase of both instances over the same TLS ing the supplied cidb (i.e., pkb). If it passes, then the connection (established to either origin). The browser server uses cidb for the subsequent steps of the verifica- can reuse an already established and verified connection tion phase, which remain unchanged. with one origin, and just verify the connection with the Overlapping Cross-Origin Access. Browsers typically SISCA instance of the other origin. If no such connec- send multiple HTTP requests over the same network con- tion exists at that time, then the browser can create a new nection (persistent connections [23]). Due to the ex- one to either origin and execute the verification phase of istence of cross-origin communication, a TLS connec- both SISCA instances. If there is no actual HTTP request tion to a particular domain, say static.example.com, to be sent at that time, the browser can make use of an can be used by the browser to transmit cross-origin re- HTTP OPTIONS request. quests to static.example.com made by different ini- Partial Support and Downgrade Attacks. SISCA must tiating origins. For example, the browser uses the same be incrementally deployable, which means that it must TLS connection to static.example.com, to transmit, maintain compatibility with legacy web servers, without first, a request originating from a document belong- compromising the security of the SISCA-enabled servers. ing to www.example.com and then, a request originat- Moreover, websites must be able to opt for partial sup- ing from a document belonging to shop.example.com port. As an example, a domain implements SISCA but (we still assume that all three domains belong to the still needs to perform cross-origin requests to another do- same entity). In this case, the TLS connection to main, called incompatible, that either does not support static.example.com has to be verified using SISCA SISCA, or supports it but belongs to a 3rd party, i.e., it for both initiating domains, independently. has different SISCA keys (we discuss on the security of In the above scenario, the browser executes such design choices at the end of this section). the verification phase with the SISCA instance of The above can be achieved by allowing exceptions. If www.example.com, upon establishing the TLS con- a particular domain does not support SISCA (including nection to static.example.com and sending the first legacy servers that are not aware of SISCA at all), then HTTP request, originating from www.example.com. it can simply ignore the X-Server-Inv header, sent dur- Subsequently, when the browser wants to reuse the ing the initialization phase, and reply without including same connection to send a cross-origin request from any SISCA-related information. This will be received by shop.example.com to static.example.com, it once the browser as an exception claim. Moreover, if a domain again executes the verification phase, only this time with supports SISCA but performs cross-origin communica- the SISCA instance of shop.example.com. This takes tion with one or more incompatible domains, then it can place upon transmitting the first HTTP request, which append an exception list in its response, during the initial- originates from shop.example.com. ization phase, designating the incompatible domains. Origin Change. A web page is allowed to change However, we note that if the attacker intercepts the ini- its own origin (effective origin) to a suffix of its tialization phase of the protocol, then she could perform domain, by programmatically setting the value of a protocol downgrade attack, by providing false excep- document.domain [40]. This allows two pages be- tion claims or exception lists in her response. longing to different subdomains, but presumably to To prevent downgrade attacks, the browser should ver- the same entity, to set their origin to a common ify any exception that was received during the initializa- value and enable interaction between them4. For ex- tion phase, upon every subsequent connection. If the ample, a page from www.example.com and a page attacker intercepted the initialization phase and replied from shop.example.com can both set their origin to with fake exception claims, then if any of the subsequent connections reaches the legitimate server, the browser, 4Both pages have to explicitly set document.domain. with the help of the legitimate server, would detect the
USENIX Association 23rd USENIX Security Symposium 681 Exception claim
1a: Init message! 2a: Verify exception claim! ally there are ways of avoiding it [41]. Furthermore, de- 1b: Exception claim 2b: Invariance violation www.example.com pending on the use case, it may be possible to use iframes to isolate active 3rd party content, instead of directly em- rb 1a ‘Init’, rb bedding it within the target origin, in order to mitigate exception claim 1b the risk (the sandbox attribute can help even further). TLS cidb Exception)claim:)“I)don’t) The embedding of passive content only, such as im- support)SISCA” ages, does not give the attacker the ability to execute “www.example.com)do)you) www.example.com really)not)support)SISCA?” her code within the target origin. Hence, with respect to Keys ks1, ks2 2a preventing user impersonation, such embeddings are safe ‘Verify’, … “False,)I) do)support) and do not undermine the security offered by SISCA. ‘Alert’ 2b SISCA” TLS 3.2.7 Resource Caching cidb Caching of static resources, such as scripts and images, Figure 11: Preventing downgrade attacks (same-origin case). helps reduce web page loading times as well as server resource consumption. However, the way caching is cur- rently implemented [23, 25] can give a MITM attacker attack. This scenario is illustrated in Figure 11. the opportunity to subvert SISCA. Regarding cross-origin communication, in order to In brief, during one browsing session, the attacker in- help SISCA-enabled legitimate servers detect fake excep- tercepts all TLS connections and ensures that a legiti- tion lists previously received by the browser, SISCA pro- mate, yet maliciously modified script that is required by tocol messages should include (in the X-Server-Inv the target web server is cached by the browser. Then, dur- header) the origin associated with the SISCA instance. ing a second browsing session, the attacker lets all con- Suppose for example, that the browser executes the nections pass through. When the legitimate web page initialization phase with www.example.com which sup- asks for the inclusion of the aforementioned script, the ports SISCA (executes the protocol normally), but also browser will load it from cache, essentially enabling the includes an exception list stating that it performs cross- execution of the attacker’s malicious code. The attacker origin requests to shop.example.com which does not will thus be able to access the target web server. support SISCA. Whenever the browser connects to To prevent the above attack, we need to change the shop.example.com to perform a cross-origin request way caching is performed for active content that would from www.example.com, the browser includes the ori- enable this attack (JavaScript and CSS files). We need to gin of the SISCA instance (www.example.com) and asks make sure that the browser always communicates with shop.example.com whether it indeed does not sup- the server in order to verify that the cached version is port SISCA with respect to that origin. Assuming that the most recent and also the correct one (i.e., not mali- the connection was not intercepted, shop.example.com ciously modified). Thus, caching of such files should be can leverage the supplied origin information to decide performed only using Entity Tags (ETags) [23], but in a whether the exception reported by the browser is valid. more rigorous way than specified in the current HTTP If not, then it should abort processing the request and specification. In particular, if a web server wishes to in- notify the browser of the detected attack. Note that the struct a browser to cache a JavaScript or CSS file, the above assumes that each SISCA-enabled server is aware server should use an ETag header which always contains of all the domains that is compatible to execute SISCA a cryptographic hash of the file. The browser, before us- with (i.e., domains with which it shares the same SISCA ing, and caching the file should verify that the supplied keys), which is not difficult to implement. hash is correct. Subsequently, before the browser uses 3rd Party Content Inclusion. As mentioned above, a the cached version of the file, it first verifies that the lo- domain, say www.example.com, implementing SISCA cal version matches the version of the server (using the can still perform cross-origin requests to incompatible If-None-Match header, as currently done). 3rd party domains as long as it designates those domains 3.2.8 Key Rotation as exceptions for the protocol. This of course means that TLS connections to those domains will not be protected In SISCA, the server has a pair of secret keys, ks1 and by SISCA, and could be MITM-ed by the attacker to per- ks2. To resist key compromise (i.e., MITM+key attack- form a user impersonation attack on www.example.com. ers), these keys, unlike the server’s private key, can be This can be indeed the case if www.example.com in- easily rotated. This is because the SISCA keys need not cludes active content [39] (in particular, JavaScript and undergo any certification process, and can thus be rotated CSS) from those domains. Embedding JavaScript from frequently, e.g., weekly, daily, or even hourly. The more 3rd party sites is generally not recommended, and usu- frequent the rotation the smaller the attacker’s window of
682 23rd USENIX Security Symposium USENIX Association opportunity to successfully mount MITM attacks. with any of these techniques. Finally, SISCA requires co- The key transition, of course, has to be performed such ordination between an entity’s different domains, in the that it does not break the execution of active browser sense they must have access to the same SISCA keys. SISCA instances that rely on the previous keys. At a This is needed for securing cross-origin communication high level, one way of achieving this, is to have the server and, depending on the scale of the entity, can be challeng- keep previous keys for a certain period of time (i.e., allow ing from an engineering perspective to set up. partial overlap of keys). This can enable browsers with 3.2.10 Interaction With Other Web Technologies active SISCA instances that rely on the previous keys to securely transition to new protocol parameters, i.e., t1 SPDY. SPDY [6] multiplexes concurrent HTTP requests and t2, computed using the new server SISCA keys. over the same TLS connection to improve network per- For domains served by a single machine, this is only a formance. In order for SISCA to be compatible with matter of implementing the corresponding functionality the general SPDY functionality, the browser must ensure in the web server software (e.g., Apache). For multiple that before the SISCA protocol is completed successfully domains controlled by the same entity and served by mul- (i.e., the first request/response pair is exchanged), no fur- tiple machines, located in the same data center or even in ther requests are sent through the SPDY connection. different data centers across the world, arguably more ef- Furthermore, SPDY IP Pooling allows, under certain fort is required in order to distribute the ever-changing circumstances, HTTP sessions from the same browser to keys and keep the machines in sync. Nevertheless, a sim- different domains (web origins) to be multiplexed over ilar mechanism is needed for enabling TLS forward se- the same connection. Version 3 of SPDY is compatible crecy while supporting TLS session tickets [34]. Accord- with Channel IDs (recall that different Channel IDs may ing to Twitter’s official blog [30], Twitter engineers have need to be used for different origins, but now there is implemented such a key distribution mechanism. only one TLS connection). SISCA is compatible with IP Pooling, as long as the browser manages the multiplexed 3.2.9 SISCA Benefits and Drawbacks HTTP sessions independently, with respect to the execu- SISCA offers the following advantages regarding tion of the SISCA protocol. MITM+certificate attack prevention. Compared to multi- WebSocket. SISCA is compatible with the WebSocket path probing solutions, SISCA does not rely on any third protocol [21], when the latter is executed over TLS. This, party infrastructure, trusted or not. Since SISCA is built of course assumes that (i) Channel IDs are used for the on top of Channel ID-based authentication, it has to as- WebSocket TLS connections, (ii) the SISCA protocol is sume that no MITM attack takes place during user en- executed during the WebSocket handshake (i.e., first re- rollment. Nevertheless, after this step, no “blind” trust quest/response pair), and (iii) JavaScript is not be able to is required when the user uses a new or clean browser, manipulate the X-Server-Inv header. contrary to pinning solutions (except preloaded pins), as Web Storage. Web Storage [27] is an HTML5 feature discussed in Section 3.2.4. Moreover, in SISCA no user that allows a web application to store data locally in the decision is necessary whenever server invariance viola- browser. SISCA can protect code.sessionStorage tion is detected. This can occur either due to an attack, (temporary storage), but does not prevent a MITM or due to an internal server fault, thus the browser can attacker from accessing information stored in abort (possibly after retrying) the session. SISCA is window.localStorage (permanent storage), so scalable since it can be deployed incrementally by web no sensitive information should be stored there. providers (assuming browser support). Finally, SISCA Offline Web Applications. HTML5 offers Offline Web resists MITM+key attacks, assuming that the attacker Applications [26] which allow a website to create an of- does not persistently compromise the server. fline version, stored locally in the browser. As with reg- The main disadvantage of SISCA is that it only pro- ular file caching (see Section 3.2.7), this feature can be tects against MITM attackers whose goal is to imperson- leveraged by the attacker to bypass SISCA. Making this ate the user to the server. This is arguably the most com- feature secure requires the introduction of design con- mon and impactful attacker goal. SISCA does not pro- cepts similar to what we proposed for regular caching. tect against attackers whose objective is to provide fake Other Client-Side Technologies. The attacker might at- content to the user. In such cases the attacker can sim- tempt to leverage various active client-side technologies ply intercept all connections and interact with the user besides JavaScript, such as Flash, Java and Silverlight. by serving her own, fake content. In contrast, the tech- Such technologies allow the attacker to create direct TLS niques that focus on ensuring the correctness of server connections to the legitimate server. Some of the APIs authentication (Section 3.1) can protect against such at- offered by those technologies also allow the attacker to tacks (MITM+certificate attackers). As a result, a recom- forge and arbitrarily manipulate HTTP headers, includ- mended strategy would be to use SISCA in conjunction ing cookie-related headers or the X-Server-Inv header.
USENIX Association 23rd USENIX Security Symposium 683 However, provided that Channel IDs and SISCA are not longing to the same entity. Although we do not elaborate integrated with these technologies5, the attacker will not on this idea here, this could be heuristically determined be able to impersonate the user and compromise his ac- by the browser, based on which domains are involved in count on the legitimate server. the execution of the same SISCA instance. Finally, recall that a SISCA instance is executed only 3.3 Prototype SISCA Implementation once per TLS connection and not on every HTTP re- We created a proof of concept implementation of the quest/response. basic SISCA protocol, with additional support for cross- origin communication, provided that the same Channel 4 Related Work ID is used. On the server side we use Apache 2.4.7 A significant amount of research in the past years sur- with OpenSSL 1.0.1f, patched for Channel ID support. rounds the security of the TLS protocol, in the context SISCA is implemented as an Apache module and con- of web applications (i.e., HTTPS), as well as web server sists of 313 lines of C code. On the client side we imple- and client authentication. A comprehensive overview is ment SISCA by modifying the source code of Chromium provided in [10], which, among others, surveys existing 35.0.1849.0 (252194) and the WebKit (Blink) engine. primitives that try to enhance the CA trust model in order We make a total of 319 line modifications (insertion- to more effectively address MITM attacks. s/deletions) in existing files and we add 6 new files con- The use of server impersonation for the compromise sisting of 418 lines of C++ code. of the user’s account by serving the attacker’s script to We use Base64 encoding for binary data transmis- the victim’s browser was first introduced in [32]. In this sion. When using 128-bit random values (rb and rs) attack, called dynamic pharming, the attacker exploits and HMAC-SHA256 (i.e., 256-bit tags, t1 and t2), the DNS rebinding vulnerabilities in browsers, by dynami- client’s lengthiest message is 114 bytes long, plus the ori- cally manipulating DNS records for the target server, in gin of the SISCA instance that has to be sent as well. The order to force the user’s browser to connect either to the server’s lengthiest message is 132 bytes long. attacker (to inject her script) or to the legitimate server. We finally verified that our implementation success- MITM-SITB is therefore very similar to dynamic fully blocks our proof of concept MITM-SITB attack. pharming in that it leverages server impersonation to Performance Evaluation. To assess the performance serve the script to the victim’s browser. Dynamic pharm- overhead imposed by SISCA (the server invariance part, ing focuses on the attacker’s ability to control the client’s not the overhead due to Channel IDs), we measured network traffic via DNS attacks, while in this paper we the latency of HTTP request/response roundtrips, with do not make such assumptions. Instead, MITM-SITB SISCA enabled and disabled. For the measurements we can leverage any form of MITM where the attacker con- used a 4KB HTML page, as well as an 84KB jQuery trols the communication to the client (e.g., an attacker sit- compressed file, retrieved over a domain that we set up ting on a backbone) and relies only on the behavior of the as being “cookieless”. Chromium ran on a Macbook Pro browser to re-establish a connection (with the legitimate laptop (2.3GHz CPU, 8GB RAM) and Apache ran on server) once the attacker closes the connection within a typical server machine (six core Intel Xeon 2.53GHz, which she injected her script to the browser. Dynamic 12GB RAM), connected through the campus network. pharming can equally be used to successfully attack We found that the overhead of the basic SISCA proto- Channel ID-based solutions. Recently, the act of leverag- col is negligible, as no increase in latency was measured ing script injection via server impersonation against TLS (averaged over 300 repetitions). Moreover, the HTTP re- client authentication was also discussed in [47]. quest to the cookieless domain was able to fit in a single We note that MITM-SITB (as well as dynamic pharm- outgoing packet (a typically desired objective). ing) differs from Man-In-the-Browser (MITB) [45]. The Regarding cross-origin communication over different latter implies that the attacker is able to take full control Channel IDs (see Section 3.2.6), approximately 180 of the browser by exploiting some vulnerability, or in- bytes are further added to the request (one ECDSA pub- stalling a malicious browser plugin. In MITM-SITB, the lic key and signature in Base64 encoding), which can still attacker runs normal JavaScript code within the target fit in a single packet (for cookieless domain requests). web origin and only within the boundaries established Furthermore, the server has to perform one ECDSA sig- by the JavaScript execution environment. Therefore, no nature verification. This overhead could be minimized, browser exploitation is required. Similarly, MITM-SITB if the browser used the same Channel ID, not only for is different from XSS [44]. In XSS the attacker is able subdomains of the same domain, but also for domains be- to influence only parts of the served document (by ex- ploiting a script injection vulnerability), while in MITM- 5This, for example, means that a TLS connection created by such an API will have to create and use its own Channel IDs, and that the SITB she is able to impersonate the server and thus in- browser will not execute SISCA over those connections. fluence the entire HTTP response sent to the browser.
684 23rd USENIX Security Symposium USENIX Association SISCA does not prevent MITB or XSS and addressing ing such attacks in order to perform mass surveillance these attacks is orthogonal to our work. against users of major internet services [18, 48]. To prevent dynamic pharming, the locked same-origin We showed that strong client authentication alone, policy (SOP) was proposed [32]. Weak locked SOP such as the recently proposed Channel ID-based authenti- considers attackers with invalid certificates, while strong cation, cannot prevent such attacks. Instead, strong client locked SOP also defends against attackers with valid, authentication needs to be complemented with the con- mis-issued certificates. Strong locked SOP refines the cept of server invariance, which is a weaker and easier concept of origin by including the public key of the to enforce property than server authentication. Our so- server and can also accommodate for multiple server lution, SISCA, shows that server invariance can be im- keys. Strong locked SOP isolates web objects coming plemented with minimal additional cost on top of the from connections with not endorsed server public keys in proposed Channel ID-based approaches, and can be de- a separate security context (i.e., different origin). Strong ployed incrementally, thus making it a scalable solution. locked SOP per se does not prevent a MITM attacker Given its security benefits, we believe that SISCA can from mounting a conventional MITM attack in order to act as an additional, strong protection layer in conjunc- impersonate the user. A strong client authentication solu- tion with existing proposals that focus on amending to- tion should be used in conjunction, as with SISCA. day’s server authentication issues, towards the effective Locked SOP does not resist MITM+key attacks, as prevention of TLS MITM attacks. SISCA does. Moreover, locked SOP is not able to se- cure cross-origin active content inclusion. The risks in- Acknowledgements volved when a web page imports active content, such as We thank our shepherd Dan Wallach, the anonymous JavaScript, that can be intercepted and modified by an reviewers, as well as Kari Kostiainen, Arnis Parsovs, attacker are discussed in [31]. SISCA can secure cross- Hubert Ritzdorf, Mario Strasser and Der-Yeuan Yu for origin inclusions as long as the involved domains belong their valuable feedback and insights. Some of the icons to the same entity and thus share the same SISCA keys. that are used in this work were taken and adapted from The current Channel ID specification [4] was recently opensecurityarchitecture.org. found to be vulnerable to triple handshake attacks [7], References which affect TLS client authentication in general. The mitigation proposed in [7] has already been implemented [1] The Heartbleed Bug. http://heartbleed.com/. in the version of Chromium that we used in this work. [2] ADKINS, H. An update on attempted man-in-the-middle SISCA assumes that Channel IDs work as expected, so attacks. http://googleonlinesecurity.blogspot.ch/ 2011/08/update-on-attempted-man-in-middle.html. eliminating triple handshake attacks is essential for its security. However, we note that addressing triple hand- [3] AUBOURG, J., SONG, J., STEEN, H. R. M., AND VAN KESTEREN, A. XMLHttpRequest (W3C Working Draft). http: shake attacks does not prevent MITM-SITB attacks. //www.w3.org/TR/2012/WD-XMLHttpRequest-20121206/. Recent work has proposed leveraging Channel ID- [4] BALFANZ, D., AND HAMILTON, R. Transport Layer based authentication to strengthen federated login [16] Security (TLS) Channel IDs, v01 (IETF Internet-Draf). and Cloud authorization credentials [8], against MITM http://tools.ietf.org/html/draft-balfanz-tls- attacks and credential theft in general. However, such channelid-01, 2013. proposals fail to address MITM attacks, as they are sus- [5] BARTH, A. The web origin concept (RFC 6454). http: ceptible to MITM-SITB, unless augmented with server //tools.ietf.org/html/rfc6454, 2011. invariance, as we propose in this paper with SISCA. [6] BELSHE, M., AND PEON, R. SPDY protocol (IETF Internet- Server invariance is based on sender invariance which Draf). http://tools.ietf.org/html/draft-mbelshe- httpbis-spdy-00, 2012. was formally defined in [17]. SISCA is inspired by this notion, assuming that the server’s authenticity cannot be [7] BHARGAVAN, K., DELIGNAT-LAVAU D , A., FOURNET, C., PIRONTI, A., AND STRUB, P.-Y. Triple handshakes and cookie established via server certificate verification and instead cutters: Breaking and fixing authentication over TLS. In IEEE trying to enforce the weaker property of invariance. SP (Oakland), 2014. [8] BIRGISSON, A., POLITZ, J. G., ERLINGSSON, U., TALY, A., 5 Conclusion VRABLE, M., AND LENTCZNER, M. Macaroons: Cookies with In this paper we discussed the requirements to effec- contextual caveats for decentralized authorization in the Cloud. In NDSS, 2014. tively preventing TLS MITM attacks in the context of web applications, when the attacker’s goal is to imper- [9] BRIGHT, P. Independent Iranian Hacker Claims Responsibil- ity for Comodo Hack. http://www.wired.com/2011/03/ sonate the user to the legitimate server and gain access to comodo_hack/. the user’s account and data. Striving to defeat this type [10] CLARK, J., AND VAN OORSCHOT, P. C. SoK: SSL and HTTPS: of attack is essential, especially given the recent revela- Revisiting past challenges and evaluating certificate trust model tions about government agencies (e.g., the NSA) mount- enhancements. In IEEE SP (Oakland), 2013.
USENIX Association 23rd USENIX Security Symposium 685 [11] COATES, M. Revoking trust in two TurkTrust certifi- [31] JACKSON, C., AND BARTH, A. Beware of finer-grained origins. cates. https://blog.mozilla.org/security/2013/01/ In Web 2.0 Security and Privacy, 2008. 03/revoking-trust-in-two-turktrust-certficates/. [32] KARLOF, C., SHANKAR, U., TYGAR, J. D., AND WAGNER, D. [12] CZESKIS, A., AND BALFANZ, D. Protected login. In USEC, Dynamic pharming attacks and locked same-origin policies for 2012. web browsers. In CCS, 2007. [33] KIM, T. H.-J., HUANG, L.-S., PERRIG, A., JACKSON, C., AND [13] CZESKIS, A., DIETZ, M., KOHNO, T., WALLACH, D., AND GLIGOR, V. Accountable Key Infrastructure: A proposal for a BALFANZ, D. Strengthening user authentication through oppor- public-key validation infrastructure. In WWW, 2013. tunistic cryptographic identity assertions. In CCS, 2012. [34] LANGLEY, A. How to botch TLS forward secrecy. [14] DIERKS, T., AND RESCORLA, E. The Transport Layer Security https://www.imperialviolet.org/2013/06/27/ (TLS) protocol, version 1.2 (RFC 5246). http://tools.ietf. botchingpfs.html. org/html/rfc5246, 2008. [35] LANGLEY, A. Protecting data for the long term with forward [15] DIETZ, M., CZESKIS, A., BALFANZ, D., AND WALLACH, secrecy. http://googleonlinesecurity.blogspot.ch/ D. S. Origin-bound certificates: A fresh approach to strong client 2011/11/protecting-data-for-long-term-with.html. authentication for the web. In USENIX Security, 2012. [36] LAURIE, B., LANGLEY, A., AND KASPER, E. Certificate [16] DIETZ, M., AND WALLACH, D. S. Hardening Persona – Im- transparency (RFC 6992). http://tools.ietf.org/html/ proving federated web login. In NDSS, 2014. rfc6962, 2013. [17] DRIELSMA, P. H., MODERSHEIM¨ , S., VIGANO` , L., AND [37] MARLINSPIKE, M. Convergence. http://convergence.io/. BASIN, D. Formalizing and analyzing sender invariance. In FAST, [38] MARLINSPIKE, M., AND PERRIN, T. Trust Assertions for Cer- 2006. tificate Keys (TACK) (IETF Internet-Draft). http://tack.io/ [18] ECKERSLEY, P. A Syrian MITM attack against Facebook. draft.html, 2013. https://www.eff.org/deeplinks/2011/05/syrian- [39] MOZILLA DEVELOPER NETWORK. Mixed content. man-middle-against-facebook. https://developer.mozilla.org/en-US/docs/ [19] ECKERSLEY, P. The Sovereign Keys project. https://www. Security/MixedContent. eff.org/sovereign-keys. [40] MOZILLA DEVELOPER NETWORK. Same-origin policy. [20] EVA N S , C., PALMER, C., AND SLEEVI, R. Public https://developer.mozilla.org/en-US/docs/Web/ key pinning extension for HTTP (IETF Internet-Draf). JavaScript/Same_origin_policy_for_JavaScript. http://tools.ietf.org/html/draft-ietf-websec- [41] NIKIFORAKIS, N., INVERNIZZI, L., KAPRAVELOS, A., key-pinning-09, 2013. VAN ACKER, S., JOOSEN,W.,KRUEGEL, C., PIESSENS, F., AND VIGNA, G. You are what you include: Large-scale evalua- [21] FETTE, I., AND MELNIKOV, A. The WebSocket protocol (RFC tion of remote Javascript inclusions. In CCS, 2012. 6455). http://tools.ietf.org/html/rfc6455, 2011. [42] OPPLIGER, R., HAUSER, R., AND BASIN, D. SSL/TLS session- [22] FIDO ALLIANCE. Universal 2nd Factor (U2F) overview, Ver- aware user authentication - Or how to effectively thwart the man- sion 1.0 (review draft). http://fidoalliance.org/specs/ in-the-middle. Computer Communications 29, 12 (2006), 2238– fido-u2f-overview-v1.0-rd-20140209.pdf. 2246. [23] FIELDING, R., GETTYS, J., MOGUL,J.,FRYSTYK, H., MAS- [43] OPPLIGER, R., HAUSER, R., AND BASIN, D. SSL/TLS session- INTER, L., LEACH, P., AND BERNERS-LEE, T. Hypertext Trans- aware user authentication revisited. Computers & Security 27, fer Protocol – HTTP/1.1 (RFC 2616). http://tools.ietf. 3-4 (2008), 64–70. org/html/rfc2616, 1999. [44] OWASP. Cross-site Scripting (XSS). https://www.owasp. [24] GOOGLE DEVELOPERS. Minimize request overhead. org/index.php/Cross-site_Scripting_(XSS). https://developers.google.com/speed/docs/best- https://www.owasp. practices/request. [45] OWASP. Man-in-the-browser attack. org/index.php/Man-in-the-browser_attack. [25] GOOGLE DEVELOPERS. Optimize caching. https: [46] PAOLA, S. D., AND FEDON, G. Subverting Ajax. 23rd Chaos //developers.google.com/speed/docs/best- Communication Congress, 2006. practices/caching. [47] PARSOVS, A. Practical issues with TLS client certificate authen- [26] HICKSON, I. Offline web applications (HTML 5 work- tication. In NDSS, 2014. ing draft). http://www.whatwg.org/specs/web-apps/ current-work/multipage/offline.html. [48] SCHNEIER, B. New NSA leak shows MITM attacks against major Internet services. https://www.schneier.com/blog/ [27] HICKSON, I. Web storage (W3C Recommendation). http:// archives/2013/09/new_nsa_leak_sh.html. www.w3.org/TR/webstorage/. [49] SOGHOIAN, C., AND STAMM, S. Certified lies: Detecting and [28] HIGGINS, P. Pushing for perfect forward secrecy, an defeating government interception attacks against SSL. In FC, important web privacy protection. https://www.eff. 2011. org/deeplinks/2013/08/pushing-perfect-forward- [50] STERNE, B., AND BARTH, A. Content Security Policy 1.0 (W3C secrecy-important-web-privacy-protection. Candidate Recommendation). http://www.w3.org/TR/CSP/. [29] HOFFMAN, P., AND SCHLYTER, J. The DNS-Based Authen- [51] SUNSHINE, J., EGELMAN, S., ALMUHIMEDI, H., ATRI, N., tication of Named Entities (DANE) Transport Layer Security AND CRANOR, L. F. Crying wolf: An empirical study of SSL http://tools.ietf. (TLS) protocol: TLSA (RFC 6698). warning effectiveness. In USENIX Security, 2009. org/html/rfc6698, 2012. [52] WENDLANDT, D., ANDERSEN, D. G., AND PERRIG, A. Per- [30] HOFFMAN-ANDREWS, J. Forward secrecy at Twitter. spectives: Improving SSH-style host authentication with multi- https://blog.twitter.com/2013/forward-secrecy- path probing. In USENIX ATC, 2008. at-twitter-0.
686 23rd USENIX Security Symposium USENIX Association