idnits 2.17.1 draft-wood-pearg-website-fingerprinting-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 04, 2019) is 1634 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-23 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-04 -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 pearg I. Goldberg 3 Internet-Draft University of Waterloo 4 Intended status: Informational T. Wang 5 Expires: May 7, 2020 HK University of Science and Technology 6 C. Wood 7 Apple, Inc. 8 November 04, 2019 10 Network-Based Website Fingerprinting 11 draft-wood-pearg-website-fingerprinting-00 13 Abstract 15 The IETF is well on its way to protecting connection metadata with 16 protocols such as DNS-over-TLS and DNS-over-HTTPS, and work-in- 17 progress towards encrypting the TLS SNI. However, more work is 18 needed to protect traffic metadata, especially in the context of web 19 traffic. In this document, we survey Website Fingerprinting attacks, 20 which are a class of attacks that use machine learning techniques to 21 attack web privacy, and highlight metadata leaks used by said 22 attacks. We also survey proposed mitigations for such leakage and 23 discuss their applicability to IETF protocols such as TLS, QUIC, and 24 HTTP. We endeavor to show that Website Fingerprinting attacks are a 25 serious problem that affect all Internet users, and we pose open 26 problems and directions for future research in this area. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 7, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Website Fingerprinting . . . . . . . . . . . . . . . . . . . 4 65 4. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Base Rate Fallacy . . . . . . . . . . . . . . . . . . . . . . 8 67 6. Defenses . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 7. Open Problems and Directions . . . . . . . . . . . . . . . . 12 69 8. Protocol Design Considerations . . . . . . . . . . . . . . . 14 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 11. Informative References . . . . . . . . . . . . . . . . . . . 14 73 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 76 1. Introduction 78 Internet protocols such as TLS 1.3 [RFC8446] and QUIC 79 [I-D.ietf-quic-transport] bring substantial improvements to end- 80 users. The IETF engineered these with security and privacy in mind 81 by encrypting more protocol messages using modern cryptographic 82 primitives and algorithms, and engineering against flaws found in 83 previous protocols, yielding several desirable security properties, 84 including: forward-secure session key secrecy, downgrade protection, 85 key compromise impersonation resistance, and protection of endpoint 86 identities. Combined, these two protocols are set to protect a 87 significant amount of Internet data. However, significant metadata 88 leaks still exist for users of these protocols. Examples include 89 plaintext TLS SNI and application-specific extensions (ALPN), as well 90 as DNS queries. This information can be used by a passive attacker 91 to learn information about the contents of an otherwise encrypted 92 network connection. Recently, such information has also been studied 93 as a means of building unique user profiles [li2018can]. It has also 94 been used to build flow classifiers that aid network management 95 [foremski2014dns]. 97 In the context of Tor, a popular low-latency anonymity network, a 98 common class of attacks that use metadata for such inference is 99 called Website Fingerprinting (WF). These attacks use machine 100 learning techniques built with features extracted from metadata such 101 as traffic patterns to attack web (browsing) privacy. Miller et al. 102 [miller2014know] show how these attacks can be applied to web 103 browsing traffic protected with HTTPS to reveal private information 104 about users. Pironti et al. [pironti2012identifying] use similar 105 attacks based on data sizes to identify individual social media 106 clients using encrypted connections. Fingerprinting attacks using 107 encrypted traffic analysis are also applicable to encrypted media 108 streams, such as Netflix videos. (See work from Reed et al. 109 [reed2017identifying] and Schuster et al. [schuster2017beauty] for 110 examples of these attacks.) WF attacks have also been applied to 111 other IETF protocols such as encrypted DNS, including dnscrypt, DNS- 112 over-TLS, and DNS-over-HTTPS [siby2018dns][shulman2014pretty]. In 113 the past, they have also been conducted remotely 114 [gong2010fingerprinting], using buffer-based side channels in a 115 victim's home router. 117 Protocols such as DNS-over-TLS and DNS-over-HTTPS [RFC8484], and 118 work-in-progress towards encrypting the TLS SNI extension 119 [I-D.ietf-tls-esni], help minimize metadata sent in cleartext on the 120 wire. However, regardless of protocol and even network-layer 121 fingerprinting mitigations, application layer specifics, e.g., web 122 page sizes and client request patterns, reveal a noticeable amount of 123 information to attackers. We argue that much more work is needed to 124 protect encrypted connection metadata, especially in the context of 125 web traffic. 127 In this document, we describe WF attacks in the context of IETF 128 protocols such as TLS and QUIC. We survey WF attacks and highlight 129 metadata features and classification techniques used to conduct said 130 attacks. We also describe proposed mitigations for these attacks and 131 discuss their applicability to IETF protocols. We conclude with a 132 discussion of open problems and directions for future research and 133 advocate for more work in this area. 135 2. Background 137 In this section we review how most secure Internet connections are 138 made today. We omit custom configurations such as those using VPNs 139 and proxies since they do not represent the common case for most 140 Internet users. The following steps briefly describe the sequence of 141 events that normally occur when a web client, e.g., browser, curl, 142 etc., connects to a website and obtains some resource. First an 143 unencrypted DNS query is sent to an untrusted DNS recursive resolver 144 to resolve a name to an IP address. Upon receipt, clients then open 145 a TCP and TLS connection to the destination address. During this 146 stage, metadata such as the TLS SNI and ALPN values are sent in 147 cleartext. The SNI is used to denote the destination application or 148 endpoint to which clients want to connect. Servers use this for 149 several purposes, including selecting an appropriate certificate (one 150 with the SNI name in the SubjectAlternativeName list) or routing to a 151 different backend terminator. ALPN values are used to negotiate 152 which application-layer protocol will be used on top of the TLS 153 connection. Common values include "http/1.1", "h2", and (soon) "h3". 154 Upon connection, clients then send HTTP messages to obtain the 155 desired resource. 157 Connections look different (on the wire) with TLS 1.3, encrypted DNS 158 via DNS-over-TLS or DNS-over-HTTPS, and encrypted SNI. DNS queries 159 are encrypted to a (trusted) recursive resolver and TLS metadata such 160 as SNI are encrypted in transit to the terminator. Despite the 161 reduction in cleartext metadata sent over the wire, there still 162 remains several sources of information that an adversary may use for 163 malicious purposes, including: size and timing of DNS queries and 164 responses, size and timing or application traffic, and connection 165 attempts induced while loading a web resource, e.g., Javascript 166 files. So while technologies such as Encrypted SNI, DoT, and DoH 167 help protect some metadata, they are not complete solutions to the 168 larger problem. In the following section, we discuss this 169 overarching problem in detail. 171 3. Website Fingerprinting 173 Website Fingerprinting (WF) is a class of attacks that exploit 174 metadata leakage to attack end-user privacy on the Internet. In the 175 WF threat model, Adv is assumed to be a passive and local attacker. 176 Local means that Adv can associate traffic with a given client. 177 Examples include proxies to which clients directly connect. Passive 178 means that Adv can only view traffic in transit. It cannot add, 179 drop, or otherwise modify packets between the victim client and 180 server(s). Use of reliable and encrypted transport protocols such as 181 TLS limit on-path attackers to eavesdropping on encrypted packets. 182 (In QUIC, however, reordering packets is possible.) 184 Traffic features used for classification include properties such as 185 packet size, timing, direction, interarrival times, and burstiness, 186 among many others [wang2016website]. Normally, features are 187 restricted to those which are extractable as a passive eavesdropper, 188 and not those which are viewable by modifying client or server 189 behavior. Specifically, this means that attacks such as CRIME 190 [CRIME] and TIME [TIME], which rely on an attacker abusing TLS-layer 191 compression to leak contents of an encrypted connection, are out of 192 scope. 194 Website Fingerprinting attacks have evolved over the years through 195 three phases: (1) Closed-world WF on SSL/TLS, (2) Closed-world WF on 196 Tor, and (3) Open-world WF on Tor. 198 1. In the closed-world model, clients are assumed to only visit a 199 small set of pages monitored by Adv. This is less realistic but 200 easier to analyze than the open-world model discussed below, and 201 so the earliest results achieved success on SSL/TLS in this 202 model. (For a realistic attack, Adv would need to monitor every 203 possible page of interest to each client, which is impractical.) 204 Attacks against proxy-based privacy technologies such as VPNs and 205 SSH tunneling, which has almost no effect on the network, falls 206 under this category as well. 208 2. Tor, an anonymity network built on onion routing, is harder to 209 attack than SSL for several reasons; successful results on Tor 210 thus came later. First, Tor pads all cells (Tor's application- 211 layer datagrams) to the same constant size, removing unique 212 packet lengths as a powerful feature for the attacker. Second, 213 Tor imposes random network conditions upon the client due to 214 random selection of proxies, so packet sequences are less likely 215 to be consistent. 217 3. In the open-world model, Adv wishes to learn whenever a victim 218 client visits one of a select number of monitored pages 219 [wang2016website]. Adversaries train classifiers in this model 220 using monitored and non-monitored websites of their choosing. By 221 definition, Adv cannot train using client-chosen pages. Clients 222 then visit pages at will and Adv attempts to learn whenever a 223 monitored page is visited, if any are at all. This is a 224 realistic model capturing the fact that the set of pages any 225 attacker would be interested in must necessarily be a small 226 subset of the set of all pages. As this is a harder model to 227 attack, successful results on this model came later. 229 4. Attacks 231 1. Closed-world WF on TLS: WF attacks date back to applications on 232 SSL first inspired by Wagner and Schneier [wagner1996analysis], 233 in which the authors observed that packet lengths reveal 234 information about the underlying data. Subsequent attacks 235 carried out by Cheng et al. [cheng1998traffic], Sun et al. 236 [sun2002statistical], and Hintz [hintz2002fingerprinting] 237 continued to show access. These attacks assume Adv has knowledge 238 of the target resource length(s), which is not always possible 239 with techniques such as padding. 241 Bissias et al. [bissias2005privacy] use cross correlation of inter- 242 packet times in one second time windows as an WF attack. Danezis 243 [danezis2009traffic] model websites using a Hidden Markov Model (HMM) 244 and use it, along with TLS traffic traces revealing only approximate 245 lengths, to identify requested resources on a page. Their results 246 vary the amount of information available to an adversary when 247 building the HMM. Even in cases where resource popularity is 248 omitted, which reflects the case where an adversary scrapes static 249 websites, resource recall was high (86\%). Liberatore and Levine 250 [liberatore2006inferring] proposed two WF attacks using the Jaccard 251 coefficient and the Naive Bayes classifier. Herrmann et al. 252 [herrmann2009website] extended the work of Liberatore and Levine with 253 a multinomial Naive Bayes classifier computed using three input 254 frequency transformations. Results yielded higher accuracy than that 255 of Liberatore and Levine. Herrmann's attack is the best in this 256 category, but the authors assume packets which do not fill a MTU 257 represent packet trailers. Therefore, uniqueness is only accurate 258 modulo the MTU. Efficacy is limited if endpoints pad packets to the 259 MTU or another fixed length. Modern protocols such as HTTP/2, QUIC, 260 and TLS 1.3 all provide some form of application-controlled padding. 261 (Note: These attacks are not successful on Tor.) 263 1. Closed-world WF on Tor: Shmatikov and Wang [shmatikov2006timing] 264 presented a WF attack that exploits cross correlation of arrival 265 packet counts in one second time windows. Lu et al. 266 [lu2010website] developed a classifier based on the Levenshtein 267 distance between ingress and egress packet lengths extracted from 268 packet sequences. Distance is computed between strings of 269 ingress and egress packet lengths. The training packet sequence 270 with the closest distance to the testing packet sequence is 271 deemed the match. Dyer et al. [dyer2012peek] used a Naive Bayes 272 classifier trained with a reduced set of features, including 273 total response transmission time, length of packets (in each 274 direction), and burst lengths. (Wang [wang2016website] notes 275 that measuring burst lengths in Tor is difficult given the 276 presence of SENDME cells for flow control.) This approach did 277 not yield any measurable improvements over the SVM classifier 278 from Panchenko et al. Cai et al. [cai2012touching] extend the 279 work of Lu et al. by adding transpositions to the Levenshtein 280 distance computation and normalizing the result, yielding what 281 the authors refer to as the Optimal String Alignment Distance 282 (OSAD). Before feature extraction, the authors round TCP packet 283 lengths to the nearest multiple of 600B as an estimate of the 284 number of Tor cells. 286 Wang et al. [wang2013improved] tuned the OSAD-based attack to improve 287 its accuracy. Specific changes include use of Tor cells instead of 288 TCP packets for packet and burst lengths, as well as heuristics to 289 remove SENDME cells (those not carrying application data) from flows 290 to recover true burst lengths. The authors also modified the 291 distance computation by removing substitutions, increasing the weight 292 for egress packets, and varying the transposition cost across the 293 packet sequence (large weights at the beginning of a trace, and 294 smaller weights near the end, where variations are expected across 295 repeated page loads.) Wang et al. also developed an alternate 296 classifier with lower accuracy yet superior performance (quadratic to 297 linear time complexity). It works by minimizing the sum of two 298 costs: sequence transpositions and sequence deletions or insertions. 299 These two costs are computed separately, in contrast to the first 300 approach which computes them simultaneously. 302 Hayes et al. [hayes2016k] developed an attack called 303 k-fingerprinting, which uses a k-NN classifier with features ranked 304 by random decision forests. Their feature set includes timing 305 information, e.g., statistics on packets per second, among the higher 306 ranked features. (Higher ranked features have more weight in the 307 classification phase.) Yan et al. [yan2018feature] used similar 308 (manually curated) features with a CNN-based classifier. Time-based 309 features were among the more effective features identified. Rahman 310 et al. [rahman2019tik] improved time-based features by focusing on 311 bursts, e.g., burst length, variance, inter-burst delay, etc., rather 312 than more granular per-packet statistics. (The latter tend to vary 313 for inconsistencies across packet traces for websites.) This 314 improved accuracy of existing Deep Learning attacks from Sirinam et 315 al. [sirinam2018deep], especially when coupled with packet direction 316 information. 318 1. Open-world WF on Tor and TLS: Panchenko et al. 319 [panchenko2011website] were the first to use a support vector 320 machine (SVM) classifier trained with web domain-specific 321 features, such as HTML document sizes, as well as packet lengths. 322 Wang et al. [wang2014effective] also developed an attack using a 323 k-Nearest Neighbors (k-NN) classifier, which is a supervised 324 machine learning algorithm, targeting the open world setting. 325 The classifier extracts a large number of features from packet 326 sequences, including raw (ingress and egress) packet counts, 327 unique packet lengths, direction, burst lengths, and inter-packet 328 times, among others. (There are 4226 features in total.) The 329 k-NN distance metric is computed as the sum of weighted feature 330 differences. 332 Kota et al. [abe2016fingerprinting] were the first to use Deep 333 Learning (DL) methods based on Stacked Denoising Autoencoders for WF 334 attacks. (Autoencoders reduce feature input dimensions when 335 stacked.) Kota et al. form input vectors from Tor cell directions 336 (+1 or -1). They use no other features. Using a (small) data set 337 from Wang [wang2016website], the classifier achieves a 86% true 338 positive rate and 2% false positive rate in the open world model. 339 Rimmer et al. [rimmer2018automated] applied DL for automated feature 340 generation and classifier construction. Trained with 2,500 traces 341 per website, their system achieves 96.3% accuracy in the open world 342 model. Recently, Bhat et al. [bhat2018var], Oh et al. [oh2017pfp], 343 and Sirinam et al. [sirinam2018deep] used Convolutional Neural 344 Networks (CNNs) and Deep Neural Networks (DNNs) for WF attacks. 345 Results from Sirinam et al. show the best results - 98% on Tor 346 without recent defenses (in Section {{defenses}) - while performing 347 favorably when select defenses are used for both open and closed 348 world models. 350 Yan et al. [yan2018feature] studied manual high-information feature 351 extraction from packet traces. They "exhaustively" examined 352 different levels of features, including packet, burst, TCP, port, and 353 IP address, summing to 35,683 in total, and distilled them into a 354 diverse set of uncorrelated features for eight different 355 communication scenarios. Rahman [rahman2018using] studied the 356 utility of features derived from packet interarrival times, 357 including: median interarrival time (per burst), burst packet arrival 358 time variance, cross-burst interarrival median differences, and 359 others. Using a CNN, results show that these features yield a non- 360 negligible increase in WF attack accuracy. 362 5. Base Rate Fallacy 364 For all WF attacks, one limitation worth highlighting is the base 365 rate fallacy. This can be summarized as follows: highly accurate 366 classifiers with a reliable false positive rate (FPR) decrease in 367 efficacy as the world size increases. Juarez et al. 368 [juarez2014critical] studied its impact by measuring the Bayesian 369 detection rate (BDR) in comparison to the FPR as a function of world 370 size. As the world size increases, the BDR approaches 0 while the 371 FPR remains stable, meaning that the probability of incorrect 372 classifier results increase as well. Juarez et al. partially address 373 the base rate fallacy problem by adding a confirmation step to their 374 classifier. Another problem is that web content is (increasingly) 375 dynamic. Most WF attacks, especially those in closed world models, 376 assume that traces are static. However, Juarez et al. 377 [juarez2014critical] show this is not the case even for "simple" 378 pages such as google.com. Thus, due to the base fallacy rate and 379 dynamic nature of content, classifiers require continual retraining 380 in order to ensure accuracy. 382 6. Defenses 384 WF defenses are deterministic or randomized algorithms that take as 385 input application data or packet sequences and return modified 386 application data or packet sequences. Viable defenses seek to 387 minimize the transformation cost and maximum (theoretical and 388 perfect) attacker accuracy. Naive defenses such as sending a 389 constant stream of (possibly random) bytes between client and server 390 may be effective though clearly not viable from a cost perspective. 391 Relevant cost metrics include bandwidth overhead, added time or 392 latency (and its impact on related metrics such as page load time), 393 and even CPU cost, though the latter is often ignored in favor of the 394 former two. Wang [wang2016website] describe defenses as either 395 limited or general. A limited defense is one which only helps 396 mitigate specific WF attacks by transforming packets in a way to 397 obviate a particular (set of) feature(s) used by said attacks. In 398 contrast, general defenses help mitigate a variety of attacks. 400 Several general defenses have been proposed, including BuFLO 401 [dyer2012peek], which pads packets to a fixed length of 1500B (the 402 normal MTU) and schedules packets for transmission at fixed period 403 intervals (and sends fake data if nothing is yet available). Tamaraw 404 [wang2014comparing] is an improvement over BuFLO that uses two 405 different fixed lengths for packet transmission, rather than one, to 406 save on bandwidth overhead. Tamaraw also uses two different 407 scheduling rates for ingress and egress packets. The authors chose 408 to make the ingress packet period smaller than the egress packet 409 period since HTTP responses are often larger in size and count - if 410 HTTP Push is used - than requests. While provably correct, both 411 BuFLO and Tamaraw limit the rate at which clients send traffic, and 412 requires all clients to send at a uniform rate. Both requirements 413 therefore make it difficult to apply as a generic defense in IETF 414 protocols. 416 Wang et al. also developed Supersequence [wang2016website], which 417 attempts to approximate a bandwidth-optimal deterministic defense. 418 This is done by casting the padding and flow control problem as the 419 shortest common subsequence (SCS) of the transformed packet trace. 420 Supersequence approximates the solution by learning the optimal 421 packet scheduling rate; it uses the same padding scheme as Tamaraw. 423 Walkie-Talkie [wang2015walkie] is a collection of mechanisms for WF 424 defense. It includes running the client (browser) in half-duplex 425 mode to batch requests and responses together, as well as randomly 426 padding traffic so as to mimic traffic of benign websites. It 427 assumes knowledge of traffic patterns for benign websites, which can 428 be information learned over time or provided by a cooperating peer. 429 Goldberg and Wang also propose a "randomized" variant that pads real 430 bursts of requests and generates random request bursts according to a 431 uniform distribution. The half-duplex mode could be implemented as 432 an extension to a protocol such as HTTP/2, QUIC, or TLS. 434 Many limited defenses have also been proposed. We list prominent 435 works below. 437 o Shmatikov and Wang [shmatikov2006timing] developed adaptive 438 padding which adds packets to mask inter-packet times. (This 439 mechanism does not ever delay application data being sent, in 440 contrast to other padding mechanisms such as BuFLO; see below.) 441 Juarez et al. [juarez2015wtf]}[juarez2016toward] also created a WF 442 defense based on adaptive padding called WTF-PAD. This variant 443 uses application data and "gap" distribution to generate padding 444 for delays. Specifically, when not sending application data, 445 senders use the gap distribution to drive fake packet 446 transmission. WTF-PAD can be run by a single endpoint, though it 447 is assumed that both client and server participate. As mentioned 448 above, protocols such as HTTP/2, QUIC, and TLS 1.3 offer a 449 mechanism by which applications can send padding. WTF-PAD could 450 therefore be implemented as an extension to any of these 451 protocols, either by applications supplying padding distributions 452 or the system learning them over time. 454 o In the context of HTTP, Danezis [danezis2009traffic] proposed 455 padding: URLs, content, and even HTML document structures to mask 456 application data lengths. 458 o Wright et al. [wright2009traffic] developed traffic morphing, 459 which pads packets in such a way so as to make the sequence from 460 one page have characteristics of another (non-monitored or benign) 461 page. This technique requires application-specific knowledge 462 about benign pages and is therefore best implemented outside of 463 the transport layer. 465 o Nithyanand et al. [nithyanand2014glove] developed a mechanism 466 called Glove, wherein traces were first clustered and then morphed 467 (via dummy insertion, packet merging, splitting, and delaying) to 468 look indistinguishable within clusters. When used to protect the 469 Alexa top 500 domains, Glove performs well with respect to 470 bandwidth overhead when compared to BuFLO and CS-BuFLO. Varying 471 the cluster size can tune Glove's bandwidth overhead. 473 o Pironti et al. [pironti2012identifying] developed a TLS-based 474 fragmentation and padding scheme designed to hide the length of 475 application data within a certain range with record padding. The 476 mechanism works by iteratively splitting application data into 477 variable sized segments. Applications can guide the range of 478 viable lengths provided such information is available. 480 o Luo et al. [luo2011httpos] created HTTPS with Obfuscation 481 (HTTPOS), which is a client-side mechanism for obfuscating HTTP 482 traffic. It uses the HTTP Range method to receive resources in 483 chunks, TCP MSS to limit the size of individual chunks, and 484 advertised window size to control the flow of chunks in 485 transmission. 487 o Panchenko et al. [panchenko2011website] developed Decoy, which is 488 a simple mechanism that loads a benign page alongside a real page. 489 This seeks to mask the real page load by properties of the "decoy" 490 page. As with morphing, this defense requires application- 491 specific knowledge about benign pages and is best implemented 492 outside of the transport layer. 494 o The Tor project implemented HTTP pipelining 495 [perry2011experimental], which bundles egress HTTP/1.1 requests 496 into batches of varying sizes with random orders. Batching 497 requests to mask request and response sizes could be made easier 498 with HTTP/2 [RFC7540], HTTP/3, and QUIC, since these protocol 499 naturally support multiplexing. However, pipelining and batching 500 may necessarily introduce latency delays that negatively impact 501 the user experience. 503 o Cherubin et al. [cherubin2017website] design two application-layer 504 defenses called Application Layer Padding Concerns Adversaries 505 (ALPaCA) and Lightweight application-Layer Masquerading Add-on 506 (LLaMA). ALPaCA is a server-side defense that pads first-party 507 content (deterministically or probabilistically) according to a 508 known distribution. (Deterministic padding similar to Tamaraw 509 performs worse than probabilistic padding.) LLaMA is similar to 510 randomized pipelining, yet differs in that requests are also 511 delayed (if necessary) and spurious requests are generated 512 according to some probability distribution. Comparatively, ALPaCA 513 yields a greater reduction in WF attack accuracy than LLaMA. 515 o Lu et al. [lu2018dynaflow] designed DynaFlow, which is a defense 516 that dynamically adjusts traffic flows using a combination of 517 burst pattern morphing, constant traffic flow with flexible 518 intervals, and burst padding. DynaFlow overhead is 40% less than 519 that of Tamaraw and was shown to have similar benefits. 521 o Rahman [rahman18gan] uses generative adversarial networks (GANs) 522 to modify candidate burst properties of packet traces, i.e., by 523 inserting dummy packets, such that they appear indistinguishable 524 from other traces. Normally, the generator component in a GAN 525 uses random noise to produce information that matches a target 526 data distribution as classified by the discriminator component. 527 Rahman uses a modified GAN architecture wherein the generator 528 produces padding (dummy packets) for input data such that the 529 discriminator cannot distinguish it from noise, or a desired burst 530 packet sequence. Preliminary results with the GAN trained and 531 tested on defended traffic, i.e., traffic already subject to some 532 form of WF defense, show a 9% increase in bandwidth and 15% 533 decrease in attack accuracy (from 98% to 85% in a closed world 534 setting). 536 o Imani et al. [imanimockingbird] developed Mockingbird, a defense 537 built on using generated adversarial examples, i.e., dummy traffic 538 designed to disrupt classifier behavior, aimed towards model 539 misclassification. When run on classifiers trained without 540 adversarial examples, Mockingbird reduced state-of-the-art DF 541 attacks and CUMUL attacks from [panchenko2016website] from 98% to 542 3% and 92% to 31%, respectively. Conversely, classifiers trained 543 and hardened with adversarial examples only reduce attack accuracy 544 from 95% to between 25-57%, respectively. Classification results 545 for half-duplex traces, i.e., those in which traffic flows in 546 half-duplex mode, are lower. Mockingbird's bandwidth overhead is 547 tunable based on parameters that control the internal traffic 548 shaping algorithm. 550 7. Open Problems and Directions 552 To date, WF attacks target clients running over Tor or some other 553 anonymizing service, meaning that WF attacks are likely more accurate 554 on normal TLS-protected connections. Moreover, attacks normally 555 assume clients use HTTP/1.1 with parallel connections for parallel 556 resource fetches. In recent years, however, protocols such as SPDY, 557 HTTP/2, and QUIC with built-in padding support and multiplexed 558 stream-based connections should make existing attacks more difficult 559 to carry out. That said, it is unclear how exactly these protocol 560 design trends will impact WF attacks. A non-exhaustive list of 561 questions that warrant further research are below: 563 1. How does connection coalescing and consolidation affect WF 564 attacks? Technologies such as DNS-over-HTTPS and ESNI favor 565 architectures wherein a single network or connection can serve 566 multiple origins or resources. With connection coalescing, 567 traffic for multiple resources is sent on the same connection, 568 thereby adding effects similar to that of the Decoy defense 569 mechanism described in Section 6 571 2. To what extent does protocol multiplexing increase WF attack 572 difficulty? Using a single connection with multiple streams to 573 avoid HoL blocking saves on connection startup and bandwidth 574 costs while simultaneously mixing information from multiple 575 requests and resources on the same connection. 577 3. How can protocol features such as HTTP Push be used to improve WF 578 defense efficacy? Defenses without cooperative peer support 579 often induce suboptimal bandwidth or latency costs. If both 580 endpoints of a connection participate in the defense, even 581 proactively with Push, perhaps this could be improved. 583 4. Can connection bootstrapping techniques such as those used by 584 ESNI be used to distribute WF defense information? One possible 585 approach is to distribute client padding profiles derived from 586 CDN knowledge of serviced resources. 588 5. How can clients build, use, and possibly share WF defense 589 information to benefit others? 591 6. How can applications package websites and subresources in such a 592 way that limits unique information? For example, websites link 593 to third party resources in an ad-hoc fashion, causing the 594 subsequent trace of browser fetches to possibly uniquely identify 595 the website. 597 Research into the above questions will help the IETF community better 598 understand the extent to which WF attacks are a problem for Internet 599 users in general. 601 It is worth mentioning that traffic-based WF attacks may not be 602 required to achieve the desired goal of learning a connection's 603 destination. Network connections by nature reveal information about 604 endpoint behavior. The relationship between network address and 605 domains, especially when stable and unique, are a strong signal for 606 website fingerprinting. Trevisan et al. [trevisan2016towards] 607 explored use of this signal as a reliable mechanism for website 608 fingerprinting. They find that most major services (domains) have 609 clearly associated IP address(es), though these addresses may change 610 over time. Jiang et al. [jiang2007lightweight] and Tammaro et al. 611 [tammaro2012exploiting] also previously came to the same conclusion. 612 Address-based website fingerprinting was also explored by Patil and 613 Borisov [patil2019can], wherein they showed that addresses, 614 especially when grouped together as part of a single web page load, 615 leak a substantial amount of information about the corresponding 616 domain. Thus, in general, classifiers that rely solely on network 617 addresses may be used to aid website fingerprinting attacks. 619 8. Protocol Design Considerations 621 New protocols such as TLS 1.3 and QUIC are designed with privacy- 622 protections in mind. TLS 1.3, for example, has support for record- 623 layer padding [RFC8446], albeit it is not used widely in practice. 624 Despite this, TLS connections still leak metadata, including 625 negotiatied ciphersuites. (See [fordTLSMetadata] for a discussion of 626 this issue.) QUIC is more aggressive in its use of encryption as 627 both a mitigation for middlebox ossificatiion and privacy 628 enhancement. Future protocols should follow these trends when 629 possible to remove unnecessary metadata from the network. 631 9. Security Considerations 633 This document surveys security and privacy attacks and defenses on 634 encrypted TLS connections. It does not introduce, specify, or 635 recommend any particular mitigation to the aforementioned attacks. 637 10. IANA Considerations 639 This document makes no IANA requests. 641 11. Informative References 643 [abe2016fingerprinting] 644 "Fingerprinting attack on tor anonymity using deep 645 learning", Asia-Pacific Advanced Network, 2016 , n.d.. 647 [backes2013preventing] 648 "Preventing Side-Channel Leaks in Web Traffic -- A Formal 649 Approach", NDSS, 2013 , n.d.. 651 [bhat2018var] 652 "Var-CNN and DynaFlow -- Improved Attacks and Defenses for 653 Website Fingerprinting", arXiv preprint arXiv:1802.10215 , 654 n.d.. 656 [bissias2005privacy] 657 "Privacy vulnerabilities in encrypted HTTP streams", 658 International Workshop on Privacy Enhancing Technologies, 659 2005 , n.d.. 661 [cai2012touching] 662 "Touching from a distance -- Website fingerprinting 663 attacks and defenses", ACM conference on Computer and 664 communications security, 2012 , n.d.. 666 [cheng1998traffic] 667 "Traffic analysis of SSL encrypted web browsing", n.d.. 669 [cherubin2017website] 670 "Website fingerprinting defenses at the application 671 layer", Privacy Enhancing Technologies, 2017 , n.d.. 673 [coull2007web] 674 "On Web Browsing Privacy in Anonymized NetFlows", USENIX 675 Security Symposium , n.d.. 677 [CRIME] "The CRIME Attack", n.d., 678 . 681 [danezis2009traffic] 682 "Traffic Analysis of the HTTP Protocol over TLS", 2009 , 683 n.d.. 685 [dyer2012peek] 686 "Peek-a-boo, i still see you -- Why efficient traffic 687 analysis countermeasures fail", IEEE Symposium on Security 688 and Privacy, 2012 , n.d.. 690 [fordTLSMetadata] 691 "Metadata Protection Considerations for TLS Present and 692 Future", n.d., . 694 [foremski2014dns] 695 "DNS-Class -- immediate classification of IP flows using 696 DNS", International Journal of Network Management , n.d.. 698 [gong2010fingerprinting] 699 "Fingerprinting websites using remote traffic analysis", 700 Proceedings of the 17th ACM conference on Computer and 701 communications security , n.d.. 703 [hayes2016k] 704 "k-fingerprinting -- A Robust Scalable Website 705 Fingerprinting Technique", USENIX Security Symposium, 706 2016 , n.d.. 708 [herrmann2009website] 709 "Website fingerprinting -- attacking popular privacy 710 enhancing technologies with the multinomial naive-bayes 711 classifier", ACM workshop on Cloud computing security, 712 2009 , n.d.. 714 [hintz2002fingerprinting] 715 "Fingerprinting websites using traffic analysis", 716 International Workshop on Privacy Enhancing Technologies, 717 2002 , n.d.. 719 [I-D.ietf-quic-transport] 720 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 721 and Secure Transport", draft-ietf-quic-transport-23 (work 722 in progress), September 2019. 724 [I-D.ietf-tls-esni] 725 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 726 "Encrypted Server Name Indication for TLS 1.3", draft- 727 ietf-tls-esni-04 (work in progress), July 2019. 729 [imanimockingbird] 730 "Mockingbird -- Defending Against Deep-Learning-Based 731 Website Fingerprinting Attacks with Adversarial Traces", 732 n.d., . 734 [jiang2007lightweight] 735 "Lightweight application classification for network 736 management", SIGCOMM workshop on Internet network 737 management, 2007 , n.d.. 739 [juarez2014critical] 740 "A critical evaluation of website fingerprinting attacks", 741 ACM SIGSAC Conference on Computer and Communications 742 Security, 2014 , n.d.. 744 [juarez2015wtf] 745 "WTF-PAD -- toward an efficient website fingerprinting 746 defense for tor", CoRR, abs/1512.00524 , n.d., . 750 [juarez2016toward] 751 "Toward an efficient website fingerprinting defense", 752 European Symposium on Research in Computer Security, 753 2016 , n.d.. 755 [li2018can] 756 "Can We Learn What People Are Doing from Raw DNS 757 Queries?", IEEE INFOCOM 2018-IEEE Conference on Computer 758 Communications , n.d.. 760 [liberatore2006inferring] 761 "Inferring the source of encrypted HTTP connections", ACM 762 Conference on Computer and Communications Security, 2006 , 763 n.d.. 765 [lu2010website] 766 "Website fingerprinting and identification using ordered 767 feature sequences", European Symposium on Research in 768 Computer Security, 2010 , n.d.. 770 [lu2018dynaflow] 771 "DynaFlow -- An Efficient Website Fingerprinting Defense 772 Based on Dynamically-Adjusting Flows", Workshop on Privacy 773 in the Electronic Society, 2018 , n.d.. 775 [luo2011httpos] 776 "HTTPOS -- Sealing Information Leaks with Browser-side 777 Obfuscation of Encrypted Flows", NDSS, 2011 , n.d.. 779 [miller2014know] 780 "I know why you went to the clinic -- Risks and 781 realization of https traffic analysis", International 782 Symposium on Privacy Enhancing Technologies Symposium, 783 2014 , n.d.. 785 [nithyanand2014glove] 786 "Glove -- A bespoke website fingerprinting defense", 787 Proceedings of the 13th Workshop on Privacy in the 788 Electronic Society , n.d.. 790 [oh2017pfp] 791 "p-FP -- Extraction, Classification, and Prediction of 792 Website Fingerprints with Deep Learning", n.d.. 794 [panchenko2011website] 795 "Website fingerprinting in onion routing based 796 anonymization networks", ACM workshop on Privacy in the 797 electronic society, 2011 , n.d.. 799 [panchenko2016website] 800 "Website Fingerprinting at Internet Scale", n.d., 801 . 804 [patil2019can] 805 "What can you learn from an IP?", n.d., 806 . 809 [perry2011experimental] 810 "Experimental defense for website traffic fingerprinting", 811 n.d., . 814 [pironti2012identifying] 815 "Identifying website users by TLS traffic analysis -- New 816 attacks and effective countermeasures", n.d.. 818 [rahman18gan] 819 "Generating Adversarial Packets for Website Fingerprinting 820 Defense", n.d., . 823 [rahman2018using] 824 "Using Packet Timing Information in Website 825 Fingerprinting", n.d.. 827 [rahman2019tik] 828 "Tik-Tok -- The Utility of Packet Timing in Website 829 Fingerprinting Attacks", n.d., 830 . 832 [reed2017identifying] 833 "Identifying https-protected netflix videos in real-time", 834 ACM on Conference on Data and Application Security and 835 Privacy, 2017 , n.d.. 837 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 838 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 839 DOI 10.17487/RFC7540, May 2015, 840 . 842 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 843 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 844 . 846 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 847 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 848 . 850 [rimmer2018automated] 851 "Automated website fingerprinting through deep learning", 852 Network & Distributed System Security Symposium (NDSS), 853 2018 , n.d.. 855 [schuster2017beauty] 856 "Beauty and the burst -- Remote identification of 857 encrypted video streams", USENIX Security, 2017 , n.d.. 859 [shmatikov2006timing] 860 "Timing analysis in low-latency mix networks -- Attacks 861 and defenses", European Symposium on Research in Computer 862 Security, 2006 , n.d.. 864 [shulman2014pretty] 865 "Pretty bad privacy -- Pitfalls of DNS encryption", 866 Workshop on Privacy in the Electronic Society, 2014 , 867 n.d.. 869 [siby2018dns] 870 "DNS Privacy not so private -- the traffic analysis 871 perspective", n.d.. 873 [sirinam2018deep] 874 "Deep fingerprinting -- Undermining website fingerprinting 875 defenses with deep learning", arXiv preprint 876 arXiv:1801.02265 , n.d.. 878 [sun2002statistical] 879 "Statistical identification of encrypted web browsing 880 traffic", IEEE, 2002 , n.d.. 882 [tammaro2012exploiting] 883 "Exploiting packet-sampling measurements for traffic 884 characterization and classification", International 885 Journal of Network Management, 2012 , n.d.. 887 [TIME] "A Perfect CRIME? Only TIME Will Tell", Black Hat Europe 888 2013 , n.d.. 890 [trevisan2016towards] 891 "Towards web service classification using addresses and 892 DNS", Wireless Communications and Mobile Computing 893 Conference (IWCMC), 2016 International. IEEE, 2016 , n.d.. 895 [wagner1996analysis] 896 "Analysis of the SSL 3.0 protocol", USENIX Workshop on 897 Electronic Commerce Proceedings, 1996 , n.d.. 899 [wang2013improved] 900 "Improved website fingerprinting on tor", Workshop on 901 privacy in the electronic society, 2013 , n.d.. 903 [wang2014comparing] 904 "Comparing website fingerprinting attacks and defenses", 905 Technical Report 2013-30, CACR, 2013. , n.d.. 907 [wang2014effective] 908 "Effective Attacks and Provable Defenses for Website 909 Fingerprinting", USENIX Security Symposium, 2014 , n.d.. 911 [wang2015walkie] 912 "Walkie-talkie -- An effective and efficient defense 913 against website fingerprinting", n.d.. 915 [wang2016website] 916 "Website fingerprinting -- Attacks and defenses", 917 University of Waterloo , n.d.. 919 [wright2009traffic] 920 "Traffic Morphing -- An Efficient Defense Against 921 Statistical Traffic Analysis", NDSS, 2009 , n.d.. 923 [yan2018feature] 924 "Feature selection for website fingerprinting", 925 Proceedings on Privacy Enhancing Technologies, 2018 , 926 n.d.. 928 Appendix A. Acknowledgements 930 The authors would like to thank Frederic Jacobs and Tim Taubert for 931 feedback on earlier versions of this document. 933 Authors' Addresses 935 Ian Goldberg 936 University of Waterloo 938 Email: iang@uwaterloo.ca 940 Tao Wang 941 HK University of Science and Technology 943 Email: taow@cse.ust.hk 945 Christopher A. Wood 946 Apple, Inc. 948 Email: cawood@apple.com