Efficient, Effective, and Realistic Website Fingerprinting Mitigation

Website fingerprinting attacks have been shown to be able to predict the website visited even if the network connection is encrypted and anonymized. These attacks have achieved accuracies as high as 92%. Mitigations to these attacks are using cover/decoy network traffic to add noise, padding to ensure all the network packets are the same size, and introducing network delays to confuse an adversary. Although these mitigations have been shown to be effective, reducing the accuracy to 10%, the overhead is high. The latency overhead is above 100% and the bandwidth overhead is at least 30%. We introduce a new realistic cover traffic algorithm, based on a user’s previous network traffic, to mitigate website fingerprinting attacks. In simulations, our algorithm reduces the accuracy of attacks to 14% with zero latency overhead and about 20% bandwidth overhead. In real-world experiments, our algorithms reduces the accuracy of attacks to 16% with only 20% bandwidth overhead. Received on 30 February 2019; accepted on 20 April 2019; published on 29 April 2019


Introduction
Website fingerprinting violates the privacy expected from a user when she is using an anonymizing service such as a proxy or Tor [1]. The goal of website fingerprinting attacks [2] is to determine the website visited by a victim. The adversary, in this case, is usually local, for example on the same network or the Internet Service Provider, and can observe all the network traffic sent by the victim. These attacks are effective and are accurate in successfully identifying the websites. The accuracy is over 90% even when the network traffic is encrypted or anonymized through a proxy. Since the adversary knows who the user is and can accurately guess what websites she is visiting, the user has no privacy.
Various defenses against website fingerprinting attacks [3][4][5][6][7] have been proposed. The defenses include padding so that every packet has the same size, cover traffic to generate enough noise to fool the adversary, or * Corresponding author. Email: Chantin@cs.luc.edu introducing network delays between network packets. Although they have been shown to be effective, the overhead introduced by these defenses is high. The latency overhead is above 100% and the bandwidth overhead is from 30% to over 100%.
Our contribution is a new cover traffic algorithm that generates just enough noise to mitigate website fingerprinting attacks. Our algorithm also has zero latency overhead and lower bandwidth overhead than current schemes. Our algorithm generates "realistic" cover traffic 1 ; it collects the network traffic from a user, then uses that historical network traffic data as training set to feed the cover traffic generation algorithm. The generated noise thus will look exactly like a website that a user has previously visited. This prevents website fingerprinting attacks and introduces little bandwidth overhead. In a workshop paper [8], we showed through simulations that our proposed algorithm reduces accuracy of attacks to 14% while introducing no latency overhead and 20% bandwidth overhead. We expand this work by undertaking real world experiments and show that our simulation results hold in these experiments. Table 4 shows a comparison of our proposed algorithm with existing mitigation techniques. Our algorithm has comparable accuracy over the other schemes, zero latency overhead, and lower bandwidth overhead. The table shows the lowest accuracy (bestcase for the mitigation) regardless of the classification algorithm used. Our algorithm has zero latency overhead since we are only introducing cover traffic. No delays are introduced.
The remainder of this paper is organized as follows. Section 2 gives a survey of related work. Section 3 describes website fingerprinting attacks and our threat model. The design of our proposed cover traffic algorithm is provided in Section 4. The simulated experiments and results are outlined in Section 5. Section 6 shows the effectiveness of our proposed algorithm in the real-world. Future work is discussed in Section 7.

Related Work
It has been shown that analyzing encrypted network traffic can reveal the websites and webpages visited [2][3][4][5][6][9][10][11][12][13][14][15][16][17][18][19][20][21]. Since the payload is encrypted, only the metadata is available such as packet sizes, number of packets, direction of packets, and time interval between packets. A training dataset is built. Then, given a network traffic trace, machine learning techniques are used to predict the website visited. Previous results have shown that websites can be recognized with a high accuracy. More recent research results have looked at anonymized network traces such as using Tor instead of a simple HTTPS proxy. Although initial results showed that Tor provided adequate protection against website fingerprinting, more advanced data parsing techniques show that websites can be recognized with a fairly high accuracy even when the website trace is over Tor. The consequences of website fingerprinting is censorship or prosecution by the government if the user visits a forbidden website. It has been argued [22] that website fingerprinting is not a practical attack due to the large number of webpages and the false positive would be high. Website fingerprinting attacks have also been extended to identify the webbrowser used [23], which could lead to user identification as most users utilize a unique webbrowser [24].
Website fingerprinting is one type of network traffic analysis. There has been other work on network traffic analysis [25] and traffic analysis resistant protocols [26][27][28]. Network traffic analysis is usually performed for censorship [29]. Various techniques to avoid censorship have been proposed, using traffic morphing [30] to disguise the network traffic as VoIP [31,32] or using other covert channels [33][34][35]. It has, however, been shown that it is still possible to see through this obfuscation [36][37][38].
Using cover/dummy/fake traffic to mask a user's activities has been proposed before [39]. It has been shown that this mechanism can be countered or the cover traffic removed [40,41] to reveal the user's activities. Cover traffic is useful to mask real web search queries by performing many other unrelated and random search queries. Cover traffic can also be used to make network traffic analysis harder by adding unrelated network-level packets. Our algorithm generates realistic cover traffic making it harder for website fingerprinting attacks to accurately guess the website from the observed packet trace. Another scheme, Track Me Not [42], focused on web search queries and generating fake web searches, but [43] has shown that web search queries obfuscation can still be analyzed.
Various website fingerprinting defenses have been proposed [3-7, 14, 44, 45]. They all make use of some sort of padding, delaying sending of packets, or adding cover traffic. Many of these defenses have high latency and/or bandwidth overhead and have been shown to be effective in mitigating website fingerprinting attacks. Our proposed defense has zero latency overhead and lower bandwidth overhead while maintaining a high level of effectiveness.
Traffic morphing [46] is another possible defense against website fingerprinting attacks. It attempts to modify the shape and patterns of network traffic such that it looks different. For example, Stegotorus [47] attemps to make Tor network traffic look like HTTPS. Similarly, [31,32] attempt to morph Tor traffic to look like VoIP traffic so that network traffic analysis or deep packet inspection will not allow Tor traffic to be blocked or identified; VoIP traffic is usually allowed. However, [37,38] have shown that these traffic morphing schemes can be circumvented. We are not proposing to modify network traffic patterns. Our algorithm generates realistic cover traffic to mask the original packet trace.

Website Fingerprinting
Website fingerprinting aims to determine the website visited by examining the network trace sent by a victim's webbrowser. That trace is usually encrypted and sent over a proxy or an anonymous network like Tor [1,48] so that the network contents cannot be analyzed. The only information that can be observed are the packet sizes, the direction of the packets, the time interval between packets, and the number of packets sent and received.
A packet trace P T consists of n network packets. P T also consists of the tuple < Σ n i=0 N i , N s , N c >, where N i is each individual network packet, N s is the total number of packets from server to client, N c is the total number of packets sent from the client to the server. Each network packet N i forms the tuple < S i , T i , D, M s , M c >, where S i is the size of the packet, T i is the time interval until the next packet, D is the direction of the network packet (from client to server or from server to client), M s is the number of packets from the server to the client, and M c is the number of packets from the client to the server. M s and M c denotes each "train" of packets, that is, there are usually a few packets from client to the server, followed by several packets from server to client. On the other hand, N c and N s denotes the total number of packets for the whole packet trace.

Classification
Previous work [2-4, 9-16, 18-21] have achieved a classification accuracy of around 90% in both the open and closed world settings. A closed world is where the set of training packet traces are the same as the testing set. An open world setting is where there is a small set of monitored/sensitive packet traces among a larger set; the goal is to detect if a packet trace belongs to one of these monitored websites.
To perform classification, various features have been used such as number of outgoing and incoming packets, total size of incoming and outgoing packets, and cumulative size of packets. If the Tor network is used, some features that have also been considered include the Tor cells before and after. Various algorithms have also been used such as k-nearest neighbors (K-NN), support vector machine (SVM), random decision forests, edit distances, Jacard index, and Naive Bayes.
In this work, we used the same features as those mentioned in [18]: cumulative size of packets sampled at regular intervals over the whole packet trace, number of incoming packets, total size of incoming packets, number of outgoing packets, and total size of outgoing packets. We also used the random decision forests as it was used by the most recent paper [21].

Mitigations
Various defenses against website fingerprinting attacks have been proposed such as padding of packets to a fixed size and cover traffic (noise) to mask the real packet trace. They have all been shown to be somewhat effective reducing the accuracy of website fingerprinting to about 10% to 30%. However, all of these defenses incur high latency overhead or high bandwidth overhead or both.
Our proposed algorithm achieves a similar reduction in accuracy while keeping the overhead manageable. Our cover traffic generated is realistic instead of random as it depends on what the user has done previously. A threshold value for the amount of cover traffic generated can also be chosen by the user. Our algorithm experiences zero latency overhead.

Threat Model
The threat model is a local adversary that can see all the network traffic from a user. The adversary cannot decrypt the contents of the network packets but can observe the metadata such as packet sizes, direction of the packets, and the timings of packets. The adversary can also look at the IP headers to determine the source and destination IP addresses and port numbers. The victim is using an anonymous service such as a VPN or Tor [1]. Figure 1 illustrates the model and shows where the adversary is located. The goal for the adversary is to guess the website or webpage from only the encrypted network packet trace.

Overview
Our proposed algorithm to generate cover traffic is novel since it generates realistic noise rather than random noise or random padding. The intuition of this algorithm is from the results of previous work [19] which shows that it's hard to split two mixed traces of websites. The noise generated is learned from the network traffic generated by the user's webbrowser. The information recorded is the network traffic trace without the payload contents: each incoming and outgoing packet's size, and the time interval between packets and "train" of packets. A train is a set of incoming packets with size of MTU (Maximum Transmission Unit) with the last packet size less than MTU. Usually an outgoing web request is followed by one or more trains of incoming packets. Replaying this recorded network traffic will simulate that user's browsing habit. Our hypothesis is that if the cover traffic generated is similar to what the user usually does, this will provide a better noise in preventing website fingerprinting and also reduce the bandwidth overhead since this would be traffic that the user usually generates anyway. It has already been shown that if a client visits several webpages at the same time [19], then it is hard for an adversary to identify the webpage visited.
Instead of replaying the web requests to the actual servers which would use up resources on these servers, we set up our own simple webserver. Our algorithm can be implemented as a plugin for Firefox (Tor Browser Bundle). It will send a web request padded to a certain packet size to our webserver through the Tor network. The request will contain the total size of data that the server has to send back and the time that the data 3 EAI Endorsed Transactions on Security and Safety 01 2019 -04 2019 | Volume 6 | Issue 20 | e2 should be sent. Both the client plugin and webserver do not have to send any content; only pad the packets to the specified packet size. The generated network traffic will be transferred over the Tor network; a local adversary will not be able to determine which packet is noise.
The algorithm will first record traffic of a web page, then parses the recorded traffic trace. Packets are put into two sets based on whether they are incoming packets or outgoing packets. For each set, packets are organized by trains of packets. For each train, the size and timestamp of each packet is recorded. Trains of packets are listed in order by the timestamp of the first packet in the train. Figure 2 shows an example sample of a recorded network traffic. The only information recorded is the relative time between packets and the packet sizes. Both incoming and outgoing packets are recorded. The format of the sample shown in the figure is as follows: < timestamp >:< packetsize >. The actual time is not relevant; only the time difference between two packets is used. This is the time difference between the current packet's timestamp and the next packet's timestamp. The packet size is the TCP-level packet size. A red packet size indicates an outgoing packet.

Pseudocode for Algorithm
Ideally, the generated cover traffic will be exactly the same as the real recorded sample. For example, they have the same number of packets and the same timing gap between packets. In practice, we cannot control the time distribution of every packet due to network latency. Instead, we break the sample traffic into several segments based on the timing gap of packets. Then our goal is to make the cover traffic have similar timing gaps with the sample in terms of traffic segments.
For each request RS ij from the client, respond with number and size of response packets based on

Implementation Details
The cover traffic needs to have two features: 1) it should customize total packet size so that the cover traffic can be controlled, 2) it should have similar packet distribution with the real web traffic so that it cannot be filtered out easily. Modern web pages usually contain multiple resources, such as html text, CSS files, javascript files, and images. Modern web browsers support multiple parallel connections to a website. From a typical web page network traffic, we can see that a web browser sends multiple requests to download multiple resources in parallel. Considering these web page features, we separate web page traffic into segments based on requests. We define two parameters: 1) MaxNumberOfRequest and 2) MinTimediffBtwRequests. MaxNumberOfRequest denotes the maximum number of web requests and MinTimediffBtwRequests denotes the minimum time interval between two web requests. Combining these two parameters, we can separate a network traffic trace into request segments. We scan the recorded traffic trace, find two consecutive outgoing packets which have a time interval greater than MinTimediffBtwRequests, then use these two packets as the delimiter of two request segments. If we get a higher number of request segments than MaxNumberOfRequest, the algorithm will adjust the requested segment time interval threshold accordingly to get exactly MaxNumberOfRequest number of request segments. To further control the distribution of incoming packets, we separate incoming packets into segments inside the request segment. We define two other parameters: 1) MaxNumberOfResponse and MinTimediffBtwResponses. These two parameters work the same as for outgoing packets.
To control the overall cover traffic size, we define another parameter CoverTrafficLoadRatio. The total cover traffic size will be the total packet size of network traffic multiplied by CoverTrafficLoadRatio. Since we separate the network traffic trace into segments, the size of cover traffic segments will be the size of corresponding traffic segments multiplied by CoverTrafficLoadRatio.
So far, we have parsed the recorded real web traffic, our next step is to generate the cover traffic. To do that, we have a cover traffic client agent running on the user side. This client agent connects to a cover traffic server, sends requests to the server and receives responses from the server. Figure 3 shows how our cover traffic is generated. The first step we need to do is to parse the recorded real traffic trace. As we can see from the sample traffic trace, the only information recorded is the time of packets and the packet sizes. Both incoming and outgoing packets are recorded. The format of the sample shown in the figure is as follows: < timestamp >:< packetsize >. We use negative packet sizes for outgoing packets and positive packet sizes for incoming packets.
The content of a request contains the following information: relative time to send back segments of responses and total packet size of each segment. Table 1 shows a list of requests sent to the cover traffic server. These requests are generated by parsing one recorded web traffic network trace. Each cover traffic request will be sent at a certain time ("Time to Send") and will be of certain size ("Total Size"). The request content shows the number of responses to be sent back by the server, 5 EAI Endorsed Transactions on Security and Safety 01 2019 -04 2019 | Volume 6 | Issue 20 | e2 Since all requests and responses are encrypted, no actual content is sent; the content of both the request and response can be filled with random data.
From Table 1, the client agent sends a total of nine requests to the cover traffic server. The first request is sent at time 0 (relative time), the size of the request is 703 bytes and the request content is "Response=0:676,354:18,756:91". We add padding to the request content if its size is less then the expected request size. When the cover traffic server receives this request, it will send back 676 bytes of data at time 0. The time is relative to when the server receives the request. At time 0, that means the server just received the request. At time 354 ms, the server sends a response packet of size 18 bytes and at time 756 ms, the server sends a packet response of size 91 bytes. The contents of the response packet the server sends back to the client are filled with random characters. At time 7, 320 ms, the client agent sends the second request to the server.

Example
Taking the packet traces from Figure 2 as an example, the following two tables are built based on this example. Table 2 shows the parsed outgoing packets set, denoted as T S out . Table 3 shows the parsed incoming packets set, denoted as T S in . Most webbrowsing network traces have a higher number of incoming packets than outgoing packets. Moreover, the size of the incoming packets is higher than outgoing packets, which are usually web requests for a URL resource (such as jpg, html, etc...). This is typical of web traffic and is reflected in the tables. Generating noisy cover traffic works as follows.

Randomly select one traffic train from T S out and
T S in each, denoted as T out and T in respectively. The total size of T out is S out and the total size of T in is S in .
2. Construct a cover traffic request with size S out .
3. Send this request to the noise server. 4. The server will reply back with data of size S in in W T in milliseconds. W T in is the time difference between the first packet of T in and the first packet of the next traffic train after T in in the incoming traffic train set.
5. Wait for some time W T out , where W T out is the time difference between the first packet of the chosen outgoing traffic train T out and the first packet of the next outgoing traffic train.
6. Repeat steps 1 to 5 until the total incoming traffic from the noise server is equal to the size of all the incoming packets of the recorded traffic trace.
As an example, let's suppose outgoing traffic train 4 is selected from T S out and incoming traffic train 8 is selected from T S in . Our algorithm will create a new cover traffic request to send to the noise server. The request will ask the server to send back data of size 1448 + 1448 + 1448 + 476 = 4820 bytes with a time of 5367 − 5130 = 237 milliseconds. The request contains only total size of data to be sent and the time.   example, the server only needs to send padded data with size 4820. The lower level network interface will determine how to send each packet -if the MTU is 1448, packet size will be 1448 + 1448 + 1448 + 476. The outgoing packet will be of size 565 bytes. Since the actual contents of the packet is small, the rest of the packet is padded. To simplify the example, we ignore packet headers. When the noise server receives this cover traffic request, it will send back data of size 4820 bytes and sleep for 237 milliseconds before responding to next request. At the same time, the client side waits for 55 milliseconds, which is the time difference between the first packets of the outgoing traffic train 4 and outgoing traffic train 5 from Table 2. The procedure of this example is shown in figure 4. This process is repeated until the sum of all the incoming packet sizes from the server is equal to the recorded traffic trace. The reason for waiting on both client and server sides is to ensure that the generated noise traffic is well distributed to look more realistic. This generated cover traffic can achieve better performance in terms of obfuscating the overall traffic collected by a website fingerprinting attacker.
The user can choose as a parameter, the size of the cover traffic, CoverTrafficLoadRatio, s. Since the cover traffic mimics the websites that the user has previously visited, the bandwidth used will be doubled. To minimize the bandwidth overhead, each train size could be reduced by a factor of s. If the factor s is 0.5, the incoming train will thus have a total packet size of 0.5 × S in in time W T in . This reduces the bandwidth overhead and generates fewer packets.
We emphasize that the cover traffic is only between the client's webbrowser and the cover traffic webserver through Tor. The only data sent are padded data so that the packets are of a pre-determined size. The cover traffic generated will look realistic as it is traffic that was generated by the user. This recorded network traffic is only stored locally on the browser.
We expect our algorithm to effectively mitigate website fingerprinting attack since it has already been shown that cover traffic is effective. We expect that our algorithm will have lower bandwidth overhead since the amount of noise generated can be modified. Moreover, there is no extra latency added as no network delay is introduced. Our algorithm only generates cover traffic to another website. 7 EAI  Table 3. The parsed incoming traffic train set.

Setup
We utilized the dataset from [18], which consists of 1, 125 webpages and 40 instances of each webpage. Each instance contains the timestamp of each packet with the packet sizes (negative packet sizes indicate outgoing packet). We implemented the noise generation algorithm described in Section 4. We use the standard Weka [49] tool and experimented with the Random Forest classification algorithm. The classification features used in our experiments are the same as those used in [18]. The first four features are: total size of outgoing packets, total size of incoming packets, total number of outgoing packets, and total number of incoming packets. The remaining features are the sampled cumulative representation of packet size. There are two ways to calculate the cumulative packet size: c is the cumulative size of packets size where an outgoing packet has a negative packet size and a is the cumulative size of packets size where both outgoing and incoming packet sizes are denoted as positive numbers. The number of samples used n can be varied and will be taken at equidistant points in the packet trace. For example, if there are 75 packets and n = 100, a sample is taken every 0.75 packet. To determine the packet size of the 0.75th packet, the linear interpolation is calculated. If the 0th packet size was 10 and the 1st packet size was 20, the cumulative packet size for 0 is 10 and the cumulative packet size for 1 is 20 + 10 = 30. The 0.75th packet size is thus (0.75 * (30 − 10)) + 10 = 25.
We compared our proposed cover traffic algorithm with the basic cover traffic scheme. The latter works as follows. When a user visits a website, the basic scheme will randomly pick another website to also visit. As shown by [19], having two simultaneous website visits significantly lowers website fingerprinting accuracy.
The original dataset contained 1, 125 webpages, many from the same website. We filtered out webpages of the same website and used 91 websites as our base training dataset 2 . The dataset [18] contained timestamps and packet sizes. Merging the original website packet trace with the noise packet trace is relatively straightforward. Since there are 40 instances of each website, we randomly picked one instance as the noise data to merge with the original packet trace.
We considered two different basic cover traffic algorithms as a comparison. The first one always picks the same webpage (but possibly different instances). The second one randomly picks from a set of 10 webpages, different from the 91 previously selected. The second case provides a more diverse set of webpages and noise to be added.
Our noise generation algorithm "learning" dataset consists of a further 10 webpages where the packet traces are recorded. As the noise is learned from the users' network traffic, in the simulation, we ran our algorithm to generate one packet trace of noise for each of the original 91 webpages and merge that trace with the original webpage packet trace.

Results
The accuracy of the Random Forest classification algorithm including either features c or features a and c is 81.77% and 81.88% respectively. The first four features are always included. Adding features a, the cumulative total of the absolute value of all packet sizes, 8 EAI Endorsed Transactions on Security and Safety 01 2019 -04 2019 | Volume 6 | Issue 20 | e2 does not improve the accuracy of website fingerprinting attacks by much. The sample size n was set to the recommended 100 from [18]. We only considered set of features c from now.   Figure 7 shows the bandwidth overhead in % of the extra network traffic generated. The two basic cover traffic algorithms are indicated by k = 1 for adding the same one website as noise each time and by k = 10 for randomly adding one of ten websites as noise. The x-axis indicates the amount of noise s added. When s = 1.0, this means the whole packet trace is added as noise. When s = 0.5, only half of the packet trace is added as noise, that is, every other packet is added as noise to preserve the time intervals. For the basic cover traffic cases (k = 1 and k = 10), we are "simulating" the noise generated; in a real-world setting, this would be hard to achieve without controlling the server -in this case, the browser could send random packets. We show different values of s to compare with our algorithm. As more noise is added (s increases), the accuracy decreases, as expected. Similarly, the bandwidth overhead also increases as more noise is added. Our proposed noise generation algorithm achieves the same accuracy regardless of the amount of noise; this is because we are generating realistic noise that can more effectively hide a user's real traffic rather than generating random noise. Our algorithm's bandwidth overhead is the same as the basic cases. However, even with s = 0.25, the overhead is 20% and the accuracy is 14%. Since our proposed algorithm generates random packet traces based on real recorded network traffic, we ran our experiments five times; the graphs show the average of the five experiments. For these experiments, the training dataset used in the Random Forest classification algorithm is the original 91 webpages and the testing dataset is the new webpages with noise added.  Intuitively, accuracy should decrease as more noise is added. However, in Figure 6, we found that in our algorithm, s = 0.25 has a lower accuracy than s = 0.5. We hypothesized that this could be due to the features being considered. Recall that two of the five features are the total number of incoming packets and the total size of incoming packets. When s is lower, the number of incoming packets is lower. To verify our hypothesis, we re-ran our algorithms without considering these two features of incoming packets. Figure 8 shows the result. It can be seen that without these two features, accuracy decreases as noise generated increases, which is expected. This shows that the attributes for total size of incoming packets and total number of incoming packets help the website fingerprinting adversary in successfully identifying the correct website (increase in 9 EAI Endorsed Transactions on Security and Safety 01 2019 -04 2019 | Volume 6 | Issue 20 | e2 accuracy). Without these two features, our proposed algorithm performs even better as the accuracy is reduced to under 10% when s = 1.0. Previous work [19] has shown that the number of incoming packets is one of the most useful attributes in classification for website fingerprinting. We also considered not including the incoming packet features; the results are shown in Figure 9. The results are expected as well but the change in accuracy is not as obvious as Figure 8 since the number of outgoing packets is about the same regardless of the value of s.

Setup
We collected network traffic data for the top 100 web sites listed from Wikipedia. After we removed duplicates (e.g. google.com and google.co.uk) and adult websites, we were left with 75 websites. For each website, we recorded 20 instances of network traffic through Tor without noise and 20 instances of network traffic through Tor including traffic from the noise server. Each network traffic trace's duration was two minutes. We used Wireshark version 1.6.7 to capture packets at the TCP level and TorBrowser version 6.5.2 as the web browser. The computers used were Dell Optiplex with Intel i5 and 4GB of RAM. We note that Wireshark cannot differentiate whether a packet is from the noise server or from the webserver. All the traffic looks like it originates from the Tor network. The following steps outline how we record the network traffic of a website. The cover traffic server is deployed on a different machine from the client. The cover traffic client agent runs Tor version 0.2.2.35; all the cover traffic are forwarded to the noise server through the Tor client. The noise traffic consists of the network traffic trace of the top 10 web pages; in reality, this would be the traffic trace of websites visited by the user. Each time the cover traffic client needs to generate noise, it will randomly pick on these ten traces and sends requests and receives responses from the noise server as described in Section 4.3. In our experiments, we set MinTimediffBtwRequests to 500 milliseconds, MaxNumberOfRequest to 10, MaxNumberOfResponse to 10 and MinTimediffBtwResponses to 200 milliseconds. Figure 1 illustrates how our experiments are set up.

Evaluation
We deployed our real-world experiments from May 13 to August 10. We visited 75 websites and collected data for 20 instances of each of the 75 websites. This was our training dataset. We then repeated the experiments for the same websites and number of instances for each website with cover traffic generated by the noise server. This made up our testing dataset. Similar to the simulations, we used the Random Forest classification algorithm to perform the website prediction. Figure 10 shows the accuracy of website fingerprinting. When no cover traffic is generated, the accuracy is 81.59%, which is close to the 90% obtained in previous 10 EAI Endorsed Transactions on Security and Safety 01 2019 -04 2019 | Volume 6 | Issue 20 | e2
research. However, when generating 10% cover traffic, the accuracy decreases to 17.81% which shows that our cover traffic algorithm is significantly impacting the adversary's ability to perform a website fingerprinting attack. When generating 20% and 30% cover traffic, the accuracy obtained is 16.37% and 10.72% respectively. We also ran the k-nearest neighbors classifier as this was used in previous research. The accuracy obtained is similar to that obtained when using the Random Forest algorithm.

Discussion and Future Work
We showed that our proposed cover traffic (noise generation) algorithm mitigates website fingerprinting attacks as effectively as current existing schemes. However, the bandwidth overhead is only 20%, much lower than existing schemes. The latency overhead is also 0%. Our algorithm can also be configured to utilize different amounts of bandwidth, which affects the adversary's accuracy.
Recording user's browsing session: We emphasize that the user's webbrowsing session only need to be recorded locally. This information is not shared. Moreover, only the packet sizes and number of packets are recorded. The server and actual contents are not recorded. The information sent to the noise server is only the number of packets to send back and their size. The contents of the packets are random, not actual contents. Since the packets are encrypted, an adversary cannot determine that these packets are cover traffic. Since no actual contents are sent, our scheme does not leak any information to an eavesdropper. Using a dedicated noise server: The cover traffic could be sent to real webservers; however, this would put extra strain on these servers. We, thus, decided to use a dedicated noise server. Removing the noise server will mean only outgoing cover traffic can be sent which could be filtered out by an adversary. Multiple noise servers, such as using Amazon cloud, could be used if this scheme is deployed. Since Tor is used, it cannot be determined whether the user is contacting a noise server. We plan to expand this work in considering more webpages for both the training dataset and our learning algorithm. A more detailed study on the different classification algorithms and parameters used will also be performed. Further improvements to our algorithm can be made, such as, if a user has multiple tabs open at the same time, no noise is needed. This would reduce the bandwidth overhead.