Proceedings on Privacy Enhancing Technologies ; 2019 (3):255–266 Erik Sy*, Christian Burkert, Hannes Federrath, and Mathias Fischer A QUIC Look at Web Tracking Abstract: QUIC has been developed by Google to im- exception of a few early handshake messages. Further- prove the transport performance of HTTPS traffic. It more, QUIC switches potential client identifiers such as currently accounts for approx. 7% of the global Inter- the source-address token frequently to limit the possi- net traffic. In this work, we investigate the feasibil- bility for network-based attackers, e.g., internet service ity of user tracking via QUIC from the perspective of providers or intelligence services, to track users across an online service. Our analysis reveals that the proto- several connections. col design contains violations of privacy best practices In the light of mass surveillance, network-based at- through which a tracker can passively and uniquely tackers represent a legitimate concern. However, online identify clients across several connections. This track- tracking for advertising or web analytics poses a sim- ing mechanisms can achieve reduced delays and band- ilar threat to users’ privacy. Therefore, browsers are width requirements compared to conventional browser required to protect their users’ privacy against track- fingerprinting or HTTP cookies. This allows them to ing through web servers that is not conducted in mu- be applied in resource- or time-constrained scenarios tual agreement. Nonetheless, there is a trade-off between such as real-time biddings in online advertising. To vali- performance and privacy for browsers, in which reduced date this finding, we investigated browsers which enable user privacy can yield a higher browser performance. For QUIC by default, e.g., Google Chrome. Our results sug- example, the usage of TLS session resumption mecha- gest that the analyzed browsers do not provide protec- nisms accelerates connection establishment, but can be tive measures against tracking via QUIC. However, the used for user tracking at the same time [34]. Browsers introduced mechanisms reset during a browser restart, such as Google Chrome or Opera balance this privacy which clears the cached connection data and thus limits versus performance trade-off by limiting the time frame achievable tracking periods. To mitigate the identified of TLS session resumption [34]. QUIC allows to estab- privacy issues, we propose changes to QUIC’s protocol lish secure connections with a zero round-trip time (0- design, the operation of QUIC-enabled web servers, and RTT) handshake. The widespread TCP/TLS 1.2 alter- browser implementations. native requires at least three round-trips [18]. In this work we investigate the impact of QUIC’s Keywords: QUIC Transport Protocol, Network Security, performance enhancements on user privacy. We find Protocol Design, Privacy Protections, Browser Measure- that QUIC’s source-address token and QUIC’s server ments config can be used by a server to identify a user across DOI 10.2478/popets-2019-0046 several connections. These tracking approaches exploit Received 2018-11-30; revised 2019-03-15; accepted 2019-03-16. that a client stores data from the server for reuse in a subsequent connection. Both mechanisms allow a user identification based on the first message that a client 1 Introduction sends to establish a connection with 0-RTT. Compared to common online tracking practices such The QUIC protocol is designed with the aim to provide as HTTP cookies [10] or browser fingerprinting [1], privacy assurances comparable to TLS [35]. To achieve the presented tracking mechanisms can provide per- this goal, QUIC traffic is mostly encrypted with the formance advantages. They do not require an tracker to actively request information from a user’s browser. This saves additional delays and bandwidth consump- *Corresponding Author: Erik Sy: University of Hamburg, tion, which otherwise restricts the practical applicabil- E-mail: [email protected] ity of such tracking methods [2]. For example, a third- Christian Burkert: University of Hamburg, E-mail: party tracker hosting popular web fonts would directly [email protected] affect the page load time of a website by performing Hannes Federrath: University of Hamburg, E-mail: browser fingerprinting and consequently impair the user [email protected] Mathias Fischer: University of Hamburg, E-mail: experience [15]. Furthermore, the additional delay is a mfi[email protected] disadvantage for the highly time-constrained practice of A QUIC Look at Web Tracking 256 real-time bidding in online advertising [22]. QUIC-based describe the cryptographic handshake of the QUIC pro- tracking does not come with these drawbacks. tocol. To the best of our knowledge, we are the first to re- QUIC provides two modes for the connection setup: port on user tracking via the QUIC protocol. The main The zero round-trip time (0-RTT) and the one round- contributions of our paper are: trip time (1-RTT) full handshake, as shown in Figure 1. – We describe tracking via QUIC’s source-address to- The full handshake is required for the initial connection ken, which allows online services to link several web- between the client and the server. Subsequent hand- site visits to the same user. Furthermore, we present shakes can use the abbreviated 0-RTT mode utilizing tracking via QUIC’s server config, which enables cached information from previous connections between online services and also network-based attackers to the respective client-server pair. This behavior is in- track users across multiple sessions. dicated by reusing the server config identifier SCID_1 – We investigate the configuration of browsers that and source-address token Token_2 from the connection support QUIC connections by default. Our results shown in Figure 1 a) in the subsequent handshake (see indicate that the investigated browser configura- Figure 1 b). The SCID describes a 16-byte identifier that tions do not restrict the presented tracking mech- allows the peers to reference a specific server config, anism. Furthermore, the tested browsers do not whereas the token describes an encrypted and authen- prevent third-parties from exploiting the presented ticated block which is opaque to the client. The token mechanisms to track users across different visited contains the client’s publicly visible IP address and a websites. timestamp as seen by the server. – We propose countermeasures that mitigate the pre- The initial handshake starts with the client sending sented tracking mechanisms. We address tracking an inchoate client hello (CHLO) message, as shown in via the server config by ensuring that users at- Figure 1 a). This message contains a randomly gener- tempt 0-RTT handshakes only if they observe the ated connection identifier (ConnID), which is used by same server config during a website visit. To miti- both parties to refer to this connection. The ConnID is gate tracking via the source-address token we pro- an optional part of the public header of a QUIC packet. vide an action list for browser vendors to improve Furthermore, the ConnID allows migrating a connec- user privacy. Subsequently, we review an alternative tion to an endpoint’s new IP address and/or port. This design for QUIC’s connection establishment aiming becomes necessary after NAT rebinding [31] or when a for better privacy protections. new IP address gets assigned to an endpoint. Next, the server responds with a reject (REJ) mes- The remainder of this paper is structured as follows: Sec- sage. This message contains among others: (i) the server tion 2 describes the background on the QUIC protocol config including the server’s long-term Diffie-Hellmann handshake. Section 3 reviews QUIC’s tracking mecha- public value (PUBS), (ii) a certificate chain authenticat- nisms and their resulting privacy problems. Section 4 ing the server (CRT), (iii) a signature from the server’s summarizes our major results on tracking via the QUIC private key, (iv) a server config identifier (SCID) and protocol, before we discuss the practical impact of our (v) a source-address token (token). While (i)-(iii) are re- results and possible countermeasures in Section 5. Re- quired to authenticate the server’s identity and to estab- lated work is reviewed in Section 6, and Section 7 con- lish the secure channel, the token is used to authenticate cludes the paper. the client’s publicly visible IP address. Subsequently, the client responds with a complete CHLO. Now, the client can compute the initial keys as a shared value of 2 Background on QUIC’s the server’s PUBS and its own ephemeral Diffie-Hellman private key. The initial keys can be used to send en- handshake crypted requests to the server before the server responds to the complete CHLO. Note, that data encrypted with To set up a secure transport connection, the QUIC pro- the initial keys do not provide forward-secrecy [17]. tocol incorporates some functionality of TCP, TLS, and The server can compute the final and forward- HTTP/2. QUIC’s design allows to concurrently conduct secure key based on the client’s ephemeral Diffie- the cryptographic and the transport handshake, which Hellman public value (KeyShare) contained in the com- provides performance improvements. In this section, we plete CHLO. Therefore, the server hello (SHLO) and all consecutive messages are forward-securely encrypted. A QUIC Look at Web Tracking 257 a) 1-RTT full handshake b) 0-RTT handshake c) Rejected 0-RTT handshake Fig. 1. Handshakes in QUIC transport protocol. The SHLO message contains amongst others a new to- 3.1 QUIC’s identifiers suitable for user ken, the server’s KeyShare, and the ConnID. tracking For a 0-RTT handshake as shown in Figure 1 b), the client follows the same protocol starting from the The QUIC protocol includes identifiers which are bound complete CHLO. Thus, the client needs to cache the to a single user session such as the ConnID.