Add text for cache timing

abbrev/acronym.tex

@@ -22,3 +22,4 @@
 \newacronym {VPN}       {VPN}       	{Virtual Private Network}
 \newacronym {ISP}       {ISP}       	{Internet Service Provider}
 \newacronym {SQL}	{SQL}		{Structured Query Language}
+\newacronym {CDN}	{CDN}		{Content Delivery Network}

bibliography/references.bib

@@ -1091,6 +1091,19 @@
   langid = {english}
 }
 
+@inproceedings{sanchez-rolaBakingTimerPrivacyAnalysis2019,
+  title = {{{BakingTimer}}: Privacy Analysis of Server-Side Request Processing Time},
+  shorttitle = {{{BakingTimer}}},
+  booktitle = {Proceedings of the 35th {{Annual Computer Security Applications Conference}}},
+  author = {Sanchez-Rola, Iskander and Balzarotti, Davide and Santos, Igor},
+  date = {2019-12-09},
+  pages = {478--488},
+  publisher = {{Association for Computing Machinery}},
+  doi = {10.1145/3359789.3359803},
+  abstract = {Cookies were originally introduced as a way to provide state awareness to websites, and are now one of the backbones of the current web. However, their use is not limited to store the login information or to save the current state of user browsing. In several cases, third-party cookies are deliberately used for web tracking, user analytics, and for online advertisement, with the subsequent privacy loss for the end users. However, cookies are not the only technique capable of retrieving the users' browsing history. In fact, history sniffing techniques are capable of tracking the users' browsing history without relying on any specific code in a third-party website, but only on code executed within the visited site. Many sniffing techniques have been proposed to date, but they usually have several limitations and they are not able to differentiate between multiple possible states within the target application. In this paper we propose BakingTimer, a new history sniffing technique based on timing the execution of server-side request processing code. This method is capable of retrieving partial or complete user browsing history, it does not require any permission, and it can be performed through both first and third-party scripts. We studied the impact of our timing side-channel attack to detect prior visits to websites, and discovered that it was capable of detecting the users state in more than half of the 10K websites analyzed, which is the largest test performed to date to test this type of techniques. We additionally performed a manual analysis to check the capabilities of the attack to differentiate between three states: never accessed, accessed and logged in. Moreover, we performed a set of stability tests, to verify that our time measurements are robust with respect to changes both in the network RTT and in the servers workload.},
+  series = {{{ACSAC}} '19}
+}
+
 @article{sanchez-rolaWebWatchingYou2017,
   title = {The Web Is Watching You: {{A}} Comprehensive Review of Web-Tracking Techniques and Countermeasures},
   shorttitle = {The Web Is Watching You},

chapters/methods.tex

@@ -692,7 +692,69 @@ party websites.
 \subsection{Cache Timing}
 \label{subsec:cache timing}
 
+Cache timing attacks are another form of history stealing which enables an
+attacker to probe for already visited \glspl{URL} by timing how long it takes a
+client to fetch a resource. Timing attacks are most commonly used in
+cryptography to indirectly observe the generation or usage of a cipher key by
+measuring cpu noises, frequencies, power usage or other properties that allow
+conclusions to be drawn about the key. This type of attack is referred to as a
+side-channel attack. Cache timing exploits the fact that it takes time to load
+assets for a website. It works by measuring the time a client takes to access a
+specified resource. If the time is short, the resource has most likely been
+served from the cache and has thus been downloaded before, implying a visit to a
+website which uses that resource. If it takes longer than a cache hit would, on
+the other hand, the resource did not exist before and has to be downloaded now,
+suggesting that no other website using that resource has been visited before. In
+practice an attack might look like this (taken from
+\cite[p.~2]{feltenTimingAttacksWeb2000}):
 
+\begin{enumerate}
+	\item Alice visits a website from Bob called \texttt{bob.com}.
+	\item Bob wants to find out whether Alice visited Charlie's website
+		\texttt{charlie.com} in the past.
+	\item Bob chooses a file from \texttt{charlie.com} which is regularly
+		downloaded by visitors to that site.
+	\item Bob implements a script or program that checks the time it takes
+		to load the file from \texttt{charlie.com} and embeds it in his
+		own site.
+	\item The program is loaded by Alice upon visiting and measures the time
+		needed to load the file from \texttt{charlie.com}.
+	\item If the measured time is below a certain threshold, the file has
+		probably been downloaded into the cache and Alice has therefore
+		visited \texttt{charlie.com} before.
+\end{enumerate}
+
+Bob can do this process for multiple resources and for every user that visits
+his website, collecting browser history information on all of them. Since
+caches exist to boost performance and avoid unnecessary loading of content from
+servers which has already been downloaded before, timing attacks are very hard
+to circumvent because caches exist solely for that purpose. Countermeasures
+either cause a massive slowdown when browsing the web due to the ubiquity of
+caches, or imply a substantial change in user agent design.
+
+\citeauthor{feltenTimingAttacksWeb2000} \cite{feltenTimingAttacksWeb2000} were
+the first to conduct a study on the feasibility of cache timing attacks and
+concluded that accuracy in determining whether a file has been loaded from cache
+or downloaded from a server is generally very high ($>95\%$). Furthermore, they
+evaluated a host of countermeasures such as turning off caching, altering hit or
+miss performance and turning off Java and JavaScript but concluded that they
+were unattractive or at worst ineffective. They propose a partial remedy for
+cache timing by introducing \emph{Domain Tagging} which requires that resources
+are tagged with the domain they have initially been loaded from. Once another
+website wants to determine whether a user has visited a site before by
+cross-loading a resource, the domain does not match the tagged domain on the
+resource. If that is the case, the initial cache hit gets transformed into a
+cache miss and the resource has to be downloaded again, fooling the attacker
+into believing that the origin website has not been visited before. It is
+necessary to mention that at the time (2000) \glspl{CDN} were not as widely
+used as today. Since websites rely on \glspl{CDN} to cache resources that are
+used on multiple sites and can thus be served much faster from cache, domain
+tagging would effectively nullify the performance boost a \gls{CDN} provides by
+converting every cache hit into a cache miss. The authors themselves question
+the effectiveness of such an approach.
+
+While the attack presented by \citeauthor{feltenTimingAttacksWeb2000} relies on
+being able to accurately time resource loading, a reliable network is needed. 
 
 \subsection{Cache Control Directives}
 \label{subsec:cache control directives}