%% Copyright 2015 by Linus Nordberg <linus@nordu.net>
%%
%% This presentation is based on the conference-ornate-20min template
%% by Till Tantau <tantau@users.sourceforge.net>. You may redistribute
%% and/or modify it under the terms of the GNU Public License, version
%% 2.
%%
%% Presentation for FRISC winter school, Finse, 2015.
%%
\documentclass{beamer}
\mode<presentation>
{
  \usetheme{Szeged}
  \setbeamercovered{transparent}
}
\usepackage[english]{babel}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{mathptmx}
\usepackage[scaled=.92]{helvet}
\usepackage{courier}
\usepackage{url}
\usepackage[force,almostfull]{textcomp}
\usepackage{ellipsis}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\title{The state of academic research in Tor}
\subtitle{}
\author{Linus Nordberg, NORDUnet \\ linus@nordu.net 0x23291265}
\date[2015-05-05]{FRISC winter school, Finse, Norway}
\pgfdeclareimage[height=0.3cm]
                {ndn-logo}{../images/NORDUnet-New-Logo-Final-Small}
\logo{\pgfuseimage{ndn-logo}}
\AtBeginSection[]
{
  \begin{frame}<beamer>{}
    \tableofcontents[currentsection,currentsubsection]
  \end{frame}
}
\renewcommand{\UrlFont}{\footnotesize}

% Enable this to make items appear one at a time:
%\beamerdefaultoverlayspecification{<+->}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}
\begin{frame}
  \titlepage
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{What is Tor?}
\subsection{}

\begin{frame}{Three functions}
  \begin{itemize}
    \item Anonymous and protected access to the internet
    \item Censorship circumvention
    \item Anonymous and protected publishing
  \end{itemize}
\end{frame}

\begin{frame}{Can mean many things}
  \begin{itemize}
    \item A network
    \item A protocol and software
    \item A community
    \item An organisation
  \end{itemize}
\end{frame}

\begin{frame}{The network}
  \begin{itemize}
    \item About 6500 relays -- ordinary computers running the Tor
      software
    \item \dots at peoples homes, schools, workplaces
    \item Used for bouncing your traffic
  \end{itemize}
\end{frame}

\begin{frame}{The protocol and software}
  \begin{itemize}
    \item A network protocol
    \item A program -- free software, BSD licensed
    \item More software -- a browser and 25 more sw projects
    \item Open mailing lists, source code repositories with
      specifications, proposals and code, a bug tracker, chat rooms
    \item Technique from NRL (U.S. Naval Research Laboratory) ==>
      ``onion routing'' 1996 ==> Tor 2002
  \end{itemize}
\end{frame}

\begin{frame}{The community}
  \begin{itemize}
    \item Researchers
    \item Software developers
    \item Relay operators -- 6.5k relays
    \item Users -- 1-2M daily
    \item Support
  \end{itemize}
\end{frame}

\begin{frame}{The organisation}
  \begin{itemize}
    \item A 501(c)(3) non-profit
    \item Employees -- 10-15
    \item Contractors -- 25
    \item Financing -- EFF, Ford foundation, Google, HRW, NSF, private
      donors, RFA, Sida, US state department
    \item Turn-over -- \$\,3M 2013
    \item Infrastructure -- metrics, atlas, compass, globe, ooni,
      support, torperf; bridges, check; exonerator, gettor, weather;
      deb, git, jenkins, track, people; lists, media, www, archive;
      backup, mail, nagios
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{How does Tor work?}

\subsection{Overview}

\begin{frame}{Encrypting payload doesn't protect against traffic analysis}
  \begin{figure}[ht]
    \includegraphics[width=0.8\linewidth]{../images/cryptography-trafficanalysis}
  \end{figure}
\end{frame}

\begin{frame}{One hop isn't enough}
  \begin{figure}[ht]
    \includegraphics[width=0.8\linewidth]
                    {../images/onehop}
  \end{figure}
\end{frame}

\begin{frame}{Three hops is good}
  \includegraphics[width=0.8\linewidth]
                  {../images/threehops}
\end{frame}

\begin{frame}{Three layers of encryption}
  \includegraphics[width=0.8\linewidth]{../images/onionrouting}
\end{frame}

\begin{frame}{Relays in the network}
  \begin{figure}[ht]
    \includegraphics[width=0.8\linewidth]
                    {../images/networksize-2012-01-01-2015-05-01}
  \end{figure}
\end{frame}

\begin{frame}{Network capacity}
  \begin{figure}[ht]
    \includegraphics[width=0.8\linewidth]
                    {../images/bandwidth-2012-01-01-2015-05-01}
  \end{figure}
\end{frame}

\begin{frame}{End-user performance}
  \begin{figure}[ht]
    \includegraphics[width=0.8\linewidth]
                    {../images/torperf-50kb-all-2012-01-01-2015-05-01}
  \end{figure}
\end{frame}
%%%%%%%%%%%%%%%%%%%%
\subsection{Circuits and cell encryption}
\begin{frame}{Link protocol}
  \begin{itemize}[<+->]
  \item Pairwise communication between nodes
  \item \dots client to first-hop
  \item \dots and relay to relay
  \item Authenticating one or both
  \item Uses TLS
  \end{itemize}
\end{frame}

\begin{frame}{Circuit protocol}
  \begin{itemize}[<+->]
  \item Setting up a tunnel between a client and an exit relay
  \item Client sharing a key with each relay
  \item Uses public-key crypto (DH with RSA or Curve25519)
  \item This tunnel is called a circuit
  \end{itemize}
\end{frame}

\begin{frame}{Relay protocol}
  \begin{itemize}[<+->]
  \item Allowing a client to communicate with the nodes on a circuit
  \item Done by exchanging 512 byte cells
  \item One layer of symmetric crypto (AES128-CTR) for each relay
    processing the cell
  \item Cells contain a four byte digest (SHA1)
  \end{itemize}
\end{frame}

\begin{frame}{Stream protocol}
  \begin{itemize}[<+->]
  \item Tunneled over the relay protocol
  \item Between clients and exit relays for 
  \item \dots opening TCP connections to internet services
  \item \dots resolving DNS names
  \item \dots sending and receiving data
  \item \dots closing connections
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%
\subsection{The trust root}
\begin{frame}{Directory authorities}
  \begin{itemize}[<+->]
  \item A few semi-trusted relays with an authority identity key
  \item \dots known by clients (compiled into the program)
  \item Receive router descriptors from potential relays
  \item Vote every hour to form a signed consensus document
  \item \dots describing the current Tor network
  \item \dots giving various flags to relays, like Exit, Fast, Guard,
    Stable
  \end{itemize}
\end{frame}

\begin{frame}{The consensus}
  \begin{itemize}[<+->]
  \item Clients download the consensus and builds circuits through
    relays matching their needs
  \item \dots using relay identity keys from the consensus for the
    handshake
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%
\subsection{Onion services}
\begin{frame}{Bob offers an onion service}
  \begin{itemize}[<+->]
  \item Creates a key pair from which an .onion address is made
  \item \dots by base32-encoding (parts of) a hash of the public key
  \item Picks a couple of ``introduction points'', relays used as a
    meeting place
  \item Advertises the key and the list of introduction points in a
    distributed hash table (DHT) kept by Tor relays
  \item Creates circuits to the introduction points and tells them
    about the service
  \end{itemize}
\end{frame}

\begin{frame}{Alice connects to Bob's service}
  \begin{itemize}[<+->]
  \item Gets the list of Bob's introduction points through the DHT
  \item Builds a circuit to a ``rendezvous point'', a Tor relay
  \item Connects to one of Bob's introduction points and asks it to
    tell Bob about her rendezvous point
  \item If Bob likes the idea, he builds a circuit to Alices
    rendezvous point which joins their circuits together
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Academic research on Tor}
\begin{frame}{Tor research}
  \begin{itemize}[<+->]
  \item This section leans heavily on the ``Performance and Security
    Improvements for Tor: A Survey'' report by Mashael AlSabah and Ian
    Goldberg
  \item Will miss out on ``community research'' like the current HS
    work and all the censorship circumvention research
  \item \dots and various crypto work
  \item Except we'll visit these briefly at the end
  \end{itemize}
\end{frame}

\begin{frame}{Academic Tor research mindmap}
  \includegraphics[width=0.6\linewidth]{../images/alsabah-goldberg-map}
\end{frame}
%%%%%%%%%%%%%%%%%%%%
\subsection{Circuit setup}      % sect 9
\begin{frame}{Circuit setup}
  Constructing circuits is costly both computationally and
  communication-wise.
  \begin{itemize}[<+->]
  \item Several improved DH-based key agreement protocols have been
    presented (Øverlier and Syverson 2007)
  \item \dots of which one later became ``ntor'' (Goldberg et
    al. 2011), implemented and deployed in 2013 (tor-0.2.4)
  \item \dots which was then improved in ``Ace'' (Backes et al. 2012)
  \end{itemize}
\end{frame}
\begin{frame}{Circuit setup (cont.)}
  \begin{itemize}[<+->]
  \item Pairing-based onion routing (PB-OR, Kate et al. 2007) uses a
    trusted third party (TTP) to form a non-interactive key agreement
    protocol, with drawbacks like TTP knowledge of keys, SPOF and
    higher computational costs for relays
  \item Certificateless onion routing (Catalano et al. 2009) improves
    PB-OR by using partial secret keys from the TTP
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%
\subsection{Routing}            % sect 7
\begin{frame}{Routing}
  How to build a circuit through the network.
  \begin{itemize}[<+->]
  \item Tunable selection (Snader and Borisov 2008) is the idea of
    letting the user indicate her willingness to trade anonymity for
    performance
  \item Link-based selection (Sherr et al. 2009) replaces the
    self-reporting bandwidth plus opportunistic bandwidth measurement
    with link-based metrics such as latency, jitter and number of
    traversed AS
  \end{itemize}
\end{frame}
\begin{frame}{Routing (cont.)}
  \begin{itemize}[<+->]
  \item LASTor (Akhoondi et al. 2012) uses geographic location data of
    relays to minimise latency, as perceived by clients
  \item In Congestion-aware Path Selection (Wang et al. 2012), clients
    use observed latency to infer congestion and build paths based on
    this knowledge
  \item An evaluation of many path selection proposals can be found in
    Wacek et al. 2013.
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%
\subsection{Congestion}

\begin{frame}{Congestion control vs. flow control}
  \begin{itemize}[<+->]
  \item Flow control is about regulating the flow in a network between
    two endpoints so that the sender doesn't overrun the receiver
    (e.g. TCP window size)
  \item The goal of congestion control is to avoid that nodes in the
    network are overloaded by receiving more than they can get rid of
    (TCP slow start, fast retransmit and recovery)
  \item Tor has flow control but no congestion control
  \end{itemize}
\end{frame}

\begin{frame}{Types of congestion}
  We differentiate between overlay congestion (``application layer'')
  and transport congestion.
\end{frame}

\begin{frame}{Application layer congestion} % sect 5
  \begin{itemize}[<+->]
  \item N23 (AlSabah et al. 2011) provides congestion control by
    giving each circuit a credit balance which is influenced
    negatively by using downstream bandwidth and positively by
    recieving credits from downstream routers
  \item Multipath routing has shown to improve throughput (Snader
    2010) where multiple circuits are used in parallell, f.ex. Conflux
    (AlSabah et al. 2013) which builds two circuits with the same exit
    and then the exit computes the latency on each path
  \item Incentive-based schemes is about turning clients into routers:
    Gold Star, PAR, BRAIDS, LIRA, TEARS and TorCoin (see Jansen 2014)
  \end{itemize}
\end{frame}

\begin{frame}{Application layer congestion (cont.)} % sect 5
  \begin{itemize}[<+->]
  \item Scheduling and prioritisation
    \begin{itemize}[<+->]
    \item Scheduling based on number of cells sent per circuit based
      on a moving average (EWMA) (Tang and Goldberg 2010)
    \item Fair queuing between connections on a given router + N23
      (Tschorsch and Scheuermann 2011)
    \item Hybrid technique with throttled clients as an incentive
      mechanism for running routers -- Tortoise (Moore et al. 2011)
    \item Classification of traffic into browsing, streaming and bulk
      with DiffTor (AlSabah et al. 2012)
    \item Throttling client to entry relay connections based on EWMA
      using the ``threshold'' algorithm (Jansen et al. 2012)
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Transport congestion} % sect 6
  The problem is the multiple circuits over a single TCP connection --
  TCP congestion control mechanisms will hit all circuits that share
  the relay-to-relay connection.
  \begin{itemize}[<+->]
    \item UDP-OR (Viecco 2008) keeps using TCP from client to entry
      and from exit to destination but switches to UDP between relays
    \item TCP-over-DTLS (Reardon and Goldberg 2009) would need a
      performant userland TCP stack
    \item Torchestra (Gopal and Heninger 2012) splits traffic between
      routers onto two separate TCP connections -- light and bulk
      using classification at exits based on EWMA of cells sent
    \item PCTCP (AlSabah and Goldberg 2013) uses one TCP connection
      per circuit and IPsec ESP instead of TLS, for bundling them
      together
  \end{itemize}
\end{frame}
\begin{frame}{Transport congestion (cont.)} % sect 6
  \begin{itemize}[<+->]
    \item uTor (Nowlan et al. 2013) uses Unordered TCP and Unordered
      TLS allowing the TCP connection to keep sending data even if a
      packet is missing for head-of-line
    \item KIST (Jansen et al. 2014) is a kernel space socket change
      making it possible for Tor to prioritise when handing data over
      to the kernel
    \item IMUX (Geddes et al. 2014) protects against socket exhaustion
      attacks against routers through a connection manager and
      scheduler
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%
\subsection{Scalability}        % sect 8
\begin{frame}{Scalability}
  \begin{itemize}[<+->]
  \item Peer-to-peer approaches
    \begin{itemize}[<+->]
    \item Try to find ways around the problems of using a DHT for
      finding peers to build a circuit through, problems including
      revealing too much during lookup and also sybil attacks
    \item ShadowWalker (Mittal and Borisov 2009) uses ``shadow nodes''
      to prevent route capture attacks
    \item \dots which later showed to be susceptible to weaknesses
      (Schuchard et al. 2010)      
    \item Torsk (McLachlan et al. 2009) uses a ``buddy selection
      protocol'' for peer discovery where a Neighbourhood Authority
      issues certificates to joining routers
    \item \dots which was shown (Want et al. 2010) to be vulnerable to
      attacks where the attacker can learn what routers a client is
      searching for
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Scalability (cont.)}
  \begin{itemize}[<+->]
  \item Using private information retrieval (PIR) techniques, PIR-Tor
    (Mittal et al. 2011) have clients download a small portion of the
    network map without revealing which portion
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%
\subsection{Security}           % sect 10

\begin{frame}{Passive attacks}  %10.1
  \begin{itemize}[<+->]
  \item AS-level adversaries are breaking an assumption about
    probability of an attacker seeing both entry and exit relays
    (Edman and Syverson 2009)
  \item Website fingerprinting is comparing traffic patterns of
    encrypted client-to-entry with known patterns of browsers visiting
    certain websites (numerous papers, but see also Perry 2013)
  \end{itemize}
\end{frame}

\begin{frame}{Path selection}   %10.2
  \begin{itemize}[<+->]
  \item Selective denial of service (SDoS, Borisov et al. 2007) is
    where an attacker denies a client a service in order to decrease
    client security, f.ex. a malicious middle relay refusing to extend
    to honest exits
  \item Low-resource routing attacks (Bauer et al. 2007) fool clients
    to use a set of relays under the control of the attacker by posing
    as faster than other relays
  \item The sniper attack (Jansen et al. 2014) makes clients DoS
    relays and can be used for things like deanonymisation of onion
    services
  \end{itemize}
\end{frame}

\begin{frame}{Side channel}
  \begin{itemize}[<+->]
  \item Throughput fingerprinting attacks %10.3.1
    \begin{itemize}[<+->]
    \item use the distinctive characteristics of the throughput in
      circuits over a given relay to determine if two circuits share
      the same path, or sometimes even just the bottleneck relay of a
      path (Mittal et al. 2011)
    \item can also be used for confirming wether a certain traffic
      flow goes over a given router
    \item also also useful for malicious routers to confirm if two
      streams belong to the same circuit and thus user
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Side channel (cont.)}
  \begin{itemize}[<+->]
  \item Congestion attacks      %10.3.2
    \begin{itemize}[<+->]
    \item could back in the day be mounted by a malicious internet
      service feeding its client a specialised pattern and then probe
      Tor relays and distinguish them by the latency caused by the
      pattern (Murdoch and Danezis 2005)
    \item more recently (Evans et al. 2009), a malicious exit could
      identify the entry guard of a given client by injecting
      javascript generating a measurable latency which would change if
      the guard was hit by a ``long path circuit'' congestion attack
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Side channel (cont.)}
  \begin{itemize}[<+->]
  \item Network latency attacks include %10.3.3
    \begin{itemize}[<+->]
    \item the circuit linkability attack (Hopper et al. 2010) in which
      two malicious internet services each measure the latency of one
      connection from a Tor exit relay and determine weather they're
      from the same client
    \item estimating a clients location by using a congestion attack
      to find the relays used by the client and constructing an
      identical circuit to infer the latency of the link between the
      victims client and its first hop (Hopper et al. 2010)
    \end{itemize}
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%
\section{Research tools and community research}
\subsection{}

\begin{frame}{The metrics site}
  \begin{itemize}
  \item Relays and bridges, with flags and by version and platform
  \item Network capacity, relay bandwidth by flags, consumed bandwidth
  \item Advertised bandwidth distribution
  \item Users by country and top-10 countries by direct connect,
    bridge connect and censorship events
  \item Onion service traffic and unique addresses
  \end{itemize}
\end{frame}

\begin{frame}{Simulators and emulators}
  A number network emulators exist, running the real Tor software,
  simulating Tor network topologies. Several of them are capable of
  running large network simulations for measuring performance.
  \begin{itemize}
  \item Shadow
  \item ExperimenTor
  \item SNEAC
  \end{itemize}
  
  Chutney is a tool for running a small Tor network on a single host,
  typically used for testing.  
\end{frame}

\begin{frame}{Crypto}
  Crypto related work include
  \begin{itemize}[<+->]
  \item Proposal 202 presents two possible new relay encryption
    protocols for Tor cells 
  \item \dots see also Fu et al. 2009 and the ``The 23 Raccoons''
    thread from 2012 and for more on tagging attacks
  \item Proposal 220 describes how to migrate server identity keys
    from RSA1024 to Ed25519
  \end{itemize}
\end{frame}
\begin{frame}{Crypto (cont.)}
  \begin{itemize}[<+->]
  \item Proposal 223 replaces the ntor handshake with Ace for improved
    performance
  \item Proposal 224 outlines a revised version of hidden services
    (see Kadianakis 2013)
  \item Proposal 228 shows how routers prove ownership of their onion
    keys
  \end{itemize}
\end{frame}

\begin{frame}{Circumvention research}
  \begin{itemize}[<+->]
  \item Ordinary ``bridge relays'' can be used to bypass blocking by
    destination address
  \item In order to avoid being blocked by DPI devices, ``pluggable
    transports'' were introduced in 2011 (tor-0.2.3)
  \item Pluggable transports transform the Tor traffic flow between a
    client and its first hop, the bridge
  \end{itemize}
\end{frame}

\begin{frame}{Deployed pluggable transports}
  \begin{itemize}[<+->]
  \item obfs3 -- random looking
  \item flashproxy -- browser-based short-lived proxies using
    WebSockets
  \item Format-Transforming Encryption -- arbitrary format
  \item ScrambleSuit -- random looking and adapting
  \item meek -- ``domain fronting'' using third-party services (Google
    App Engine, Amazon CloudFront, MS Azure)
  \item obfs4 -- adapting, server authentication and public key
    obfuscation
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}[allowframebreaks]{Sources and credit}
  \begin{itemize}
  \item Mindmap of research from Performance and Security Improvements
    for Tor: A Survey by Mashael AlSabah, Ian Goldberg, ePrint Tech
    Report 2015/235, March 2015
    \url{https://eprint.iacr.org/2015/235.pdf}
  \item ``anonbib'' -- Selected Papers in Anonymity
    \url{http://freehaven.net/anonbib/}
  \item Graphs from Tor metrics \url{https://metrics.torproject.org/}
  \item A Critique of Website Traffic Fingerprinting Attacks by Mike
    Perry, 2013
    \url{https://blog.torproject.org/blog/critique-website-traffic-fingerprinting-attacks}
  \item Tor incentives research roundup: GoldStar, PAR, BRAIDS, LIRA,
    TEARS, and TorCoin by Rob G. Jansen, 2014
    \url{https://blog.torproject.org/blog/tor-incentives-research-roundup-goldstar-par-braids-lira-tears-and-torcoin}
  \item Analysis of the Relative Severity of Tagging Attacks by The 23
    Raccoons, 2012
    \url{https://lists.torproject.org/pipermail/tor-dev/2012-March/003347.html}
  \item Hidden Services need some love by George Kadianakis, 2013
    \url{https://blog.torproject.org/blog/hidden-services-need-some-love}
  \item Charming figures by Ilja Hallberg
  \end{itemize}
\end{frame}

\begin{frame}{}
  \begin{center}
    Questions and discussion
  \end{center}
\end{frame}

\end{document}
