Anonymity in the Web based on Routing Protocols

Web Security and Privacy
Master Degree in Engineering in Computer Science
Anonymity in the Web based
on Routing Protocols
Author:
Biagio Botticelli 1212666
June 7, 2017
A.Y. 2016/2017

Contents
1 Anonymity based on the Onion Routing 2
1.1 Internet without Tor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 The Tor Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 How Tor works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Tor: Strengths and Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Attacks against Tor network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.1 RAPTOR: Routing Attacks on Privacy in Tor . . . . . . . . . . . . . . . . . 11
1.5.2 Browser-Based Attacks on Tor . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.3 The Sniper Attack: Anonymously De-Anonymizing/Disabling the Tor Network 16
1.5.4 Circuit Fingerprinting Attacks: Passive De-Anonymization of Hidden Services 19
1.5.5 Spoiled Onions: Exposing Malicious Tor Exit Relays . . . . . . . . . . . . . . 22
2 Garlic Routing 27
2.1 Invisible Internet Project (I2P) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2 I2P vs. Tor: Main Diﬀerences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3 Hidden Services 34
3.1 Internet as “Set of Subsets”: Surface, Deep and Dark Web. . . . . . . . . . . . . . . 34
3.2 Tor Hidden Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.1 Hidden Service Setup - First Step . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.2 Hidden Service Setup - Second Step . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.3 Hidden Service Setup - Third Step . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.4 Hidden Service Setup - Fourth Step . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.5 Hidden Service Setup - Fifth Step . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.6 Hidden Service Setup - Sixth Step . . . . . . . . . . . . . . . . . . . . . . . . 38
4 Practical Task 39
4.1 Hidden Service Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

1 Anonymity based on the Onion Routing
Describe the approach to anonymity based on the onion routing and discuss its
strength as well its limits. Present recent achievements in attacking the Tor network.
1.1 Internet without Tor
The Internet is generally defined as a global network connecting billions of devices worldwide.
At the very first beginning, computers were isolated and unable to communicate with each other.
As years go by, the technology has became more advanced and physical links between computers
were introduced, creating early networks. However, these networks still required the computers
to be relatively near each other. Eventually, advances in fiber optics enabled networks to connect
across continents, allowing for the Internet to become the entity which we know nowadays.
The computers that store the data on the Internet are known as servers. The devices used to
access this information (such as a smartphone, or a PC) is known as a client. The transmission
lines that connect clients to servers could be of different forms (fiber optic cables, wireless signals)
but they are all connections: when a client establishes a connection to get information from a
server, the flow goes in both directions and the data is exchanged in the form of packets.
Internet is designed to be public: packets contain information about the sender and the desti-
nation, since the routing information is public; so the headers of IP packets identify both sender
and recipient. Furthermore, the routers that exchange the traffic can see and analyze the informa-
tion is actually passing through them and this data could be used to monitor who is doing what
or who is accessing certain information on the Web.
So, it is not just the server that can see this data: Traffic Analysis is a big business, and many
organizations can monitor the messages flowing between clients and servers.
Encryption is used to secure the data transmitted over the Internet: but encryption hides just
the payload of packets and it does not hide routing information. So, even the tunnel mode en-
cryption at IP level (IPsec/ESP) reveals IP addresses of IPsec gateways.
In this situation, it’s easy to understand that Internet users may suffer violations of their right to
Privacy, since they can be tracked and their actions can be analyzed in every moment.
Definition - Anonymity: The property which makes a user:
Non-Identifiable: user activities are hidden among similar activities of other users;
Unobservable: system/protocol used by the user cannot be established;
Untraceable: user and the action performed cannot be linked.
The Internet is not designed for anonymity: IP addresses act as virtual mailing addresses, which
means that when a resource on the Internet is requested, it’s accessed from its IP address.
This IP address can be mapped to a particular Internet Service Provider (ISP), and this ISP can
provide information about the user to whom the IP has been assigned. This provides regional
information and gives powerful circumstantial evidence.
To solve the issue of IP tracking, preserving user’s privacy, anonymizing services were introduced.
2

1.2 The Tor Network
Tor (The Onion Router) is a free, distributed and anonymous communication service that uses
an overlay network allowing people to improve their privacy and security by concealing the user’s
location and usage from anyone conducting network surveillance or traffic analysis over the Internet.
Tor was initially a research project of the United
States Naval Research Laboratory (NRL, 1995).
In 2003 the Tor network was deployed and the code
is released under the free and open MIT license.
At this initial stage, the network was formed by about
a dozen volunteer nodes (mostly in the US).
From this point onwards, further development and net-
work management has been handled by the Tor Project
Inc., a registered US non-profit organization composed
of the original developers and newcomers alike.
Nowadays, there are more than 7000 relays operational worldwide (with strong concentrations in
United States and Germany) [11] and more than 2.5 millions of relay users [12].
Practically speaking, Tor enables the user to route web traffic through several other computers in
the Tor network so that the other endpoint of the connection cannot trace the traffic back. So:
The more Tor users there are, the more protected your info.
3

As the name implies, it creates a number of layers (similar to the ones of an onion) that conceal
the user identity from the rest of the network.
The computers that handle the intermediary traffic are known as Tor Relays. There are three
different kinds of Tor relays:
1. Middle Relays: relays that handle traffic along the way;
2. Exit Relays: the final relays in the chain of connections;
3. Bridges: relays that aren’t listed publicly.
Anybody can sign up to be a middle router without the fear of being implicated in any illicit
activity. People who host exit relays need to be more worried about this problem since they’re
the relays who are targeted by police if any illicit activity is detected.
However, using Tor as average user is probably safe: it’s used by everyone (from journalists to
political dissidents) to safeguard privacy and security. It’s even used by a branch of the Navy for
intelligence operations. In fact, it was originally built as part of a Navy project whose purpose
was developing ways to protect U.S. government communications. As we now know, Tor is also
certainly something that the NSA is paying attention to. But if it’s good enough for the military,
it should be good enough for the normal user.
Tor Idea: if the channels are protected against both eavesdropping (secretly listening to the private
conversation of others without their consent) and traffic analysis and if the identifying information
from the data stream is removed, then there will be an anonymous and private communication.
This is achieved by applying the Onion Routing technique.
Onion Routing provides socket connections that are strongly resistant to both eavesdropping
and traffic analysis. The privacy of these socket connections is moved beneath the application layer.
Onion Routing is implemented by using encryption at application layer of OSI protocol stack
in a multi-layered manner (onion metaphor) to ensure perfect forward secrecy between relays.
Definition - Perfect Forward Secrecy: property of secure communication protocols in which
compromise of long-term keys does not compromise past session keys.
Perfect Forward Secrecy protects past sessions against future compromises of secret keys: if PFS
is used, encrypted communications and sessions recorded in the past cannot be retrieved and
decrypted also if long-term secret keys (or passwords) would be compromised in the future.
4

1.3 How Tor works
The Tor network is an overlay network on the user level; each Onion Router (OR) runs as an
user-level process (without any special privileges) and maintains a Transport Layer Security (TLS)
connection to every other Onion Router in the network.
Each user runs a local software called an Onion Proxy (OP) to fetch directories, establish circuits
across the network, and handle connections from user applications. They also accept TCP streams
and multiplex them across the circuits. The Onion Router on the other side of the circuit
connects to the requested destinations and relays data. Each Onion Routerr maintains a long-
term Identity Key and a short-term Onion Key.
Identity Key: used to sign TLS certificates, to sign the Onion Router’s descriptor (that
is a summary of its keys, address, exit policy, . . .) and to sign directories (by directory
servers).
Onion Key: used to decrypt user requests to set up a circuit and negotiate ephemeral keys.
There is also another kind of key: the short-term Link Key which is established by TLS when the
communication between Onion Routers is instantiated. Short-term keys are rotated periodically
and independently, to limit the impact of key compromise.
The unit of communication in Tor network are the so called cells. An onion router communicate
with one another and with onion proxies, via a TLS connection with ephemeral keys. Using TLS
hides the data with perfect forward secrecy and prevents an attacker from tempering data on
the wire, or impersonating an Onion Router.
The traffic passes along these connections in fixed-size cells: each cell is 512 bytes and consists of
a header and a payload.
The header includes a circuit identifier (circID) that specifies which circuit the cell refers to (since
many circuits can be multiplexed over the single TLS connection), and a command to describe the
action to perform with the cell’s payload.
Based on their command, cells are either control cells, which are always interpreted by the node
that receives them, or relay cells, which carry end-to-end stream data.
The control cell commands are: padding (keep alive an existing circuit), create (set up a
new circuit) and destroy (tear down an existing circuit). Relay cells have an additional header
(the relay header) at the front of the payload which contain a streamID (many streams can be
multiplexed over a circuit), an end-to-end checksum for integrity checking, the length of the re-
lay payload and a relay command. The relay commands are: data (data flowing through the
stream), begin (open a new stream), end (close a working stream), teardown (close a broken
stream), connected (notify the Onion Proxy of a relay begin success), extend/extended
(extend the circuit by a hop/to acknowledge), truncate/truncated (tear down a part of the
circuit/to acknowledge), sendme (congestion control) and drop (long-range dummies). The con-
tents of the relay header and the relay cell payload are encrypted (or decrypted) together using
the 128-bit AES cipher in counter mode to generate a cipher stream.
The initial design of Onion Routing provided one circuit for each TCP stream. Since building
a circuit can take many seconds (due to public-key cryptography and network latency), this design
imposed very high costs on applications like web browsing that open many TCP streams.
In Tor instead, each circuit can be shared between different TCP streams. To avoid delays, users
construct circuits preventively and to limit linkability among their streams, onion proxies build a
new circuit periodically if the previous ones have been used and expire the old circuits that do not
have any open streams working. Moreover, OPs rotate to a new circuit about once a minute.
5

An Onion Proxy builds circuits incrementally (one hop at a time) negotiating a symmetric
key with each Onion Router on the circuit.
When a new circuit is created, the Onion Proxy A sends a create cell to the first node B in
the chosen path. In other words, A chooses a new circID CA→B which is not currently used on
its connection to the Onion Router B.
The create cell’s payload contains the first half of Diffie-Hellman handshake (gx1 ), encrypted
with the onion key of the OR B. Then, B responds to A with a created cell containing gy1
along with a hash of the negotiated key K1 = gx1y1 .
Once the circuit is built, A and B can exchange relay cells encrypted with the negotiated key.
To extend the circuit to a second node C, A sends an extend relay cell to B, specifying the
address of the next Onion Router C and an encrypted gx2 . The Onion Router B copies the
half-handshake gx2 into a create cell and passes it to C to extend the circuit. As before, the OR
B chooses a new circID CB→C which is not currently used on its connection with C.
N.B! A never needs to know the circID CB→C: only the OR B associates the circID
CA→B with the other circID CB→C to the connection that goes from A to C.
When C responds with a created cell, B envelops the payload into a extended relay cell and
sends it back to A. Now the circuit is extended to the second Onion Router C: A and C share
a negotiated key K2 = gx2y2 .
The procedure to extend the circuit to following nodes is the same: A proceeds as before, always
telling the last node in the circuit to extend one hop further.
The circuit-level handshake protocol achieves unilateral authentication: A knows that it’s com-
municating with another Onion Router X, but X does not know that A has opened the circuit,
since A does not use any public key and A stay anonymous.
It also achieves unilateral key authentication: A and X agree on a key KAX; moreover, A
knows that only the Onion Router X can know the key KAX.
Formally, in the first step we have:
A −→ B : EPKB
(gx)
B −→ A : gy, H(K|“handshake”)
where:
EPKB
(·) is the encryption by B’s public key, H is a secure hash function and | is concatenation.
Once that the Onion Proxy A has established the circuit so that it shares the keys with each
onion relay on the chosen path, it can send relay cells.
The cells could could be received by both Onion Proxies and Onion Routers:
Onion Routers: when an OR X receives a relay cell, it looks up the corresponding circuit
and decrypts the relay header and payload with the session key for that specific circuit,
checking for a valid digest: if the digest is valid, X accepts the relay cell and processes it
for the next hop; otherwise, X searches for the circID and OR Y of the next hop, replaces
6

the circID with Y ’s correct one, and sends the decrypted relay cell to Y (next OR of circuit).
At the end of the circuit, if the last OR has received an unrecognized relay cell, then an error
has occurred during the communication and the circuit is torn down.
Onion Proxies: when an Onion Proxy A receives a relay cell, it iteratively discards the
relay header and payload with the session keys shared with each Onion Router X on the
circuit from the closest to farthest.
For each layer of encryption, if the digest is valid, then the cell must have been originated
at the Onion Router whose encryption has just been removed.
Hence, at the moment of the relay cell construction, the Onion Proxy A assigns to the cell the
digest and then iteratively encrypts the cell (header and payload) with the symmetric key of
each OR X on the circuit. Because the digest is encrypted to a diﬀerent value at each step,
only at the targeted OR X it has a meaningful value.
When a Onion Router X replies to a Onion Proxy A with a relay cell, it encrypts relay header
and payload with the shared key KA−X of A, and it sends the cell back along the circuit.
Each subsequent OR Y on the path from X to A, which processes the return of the cell up to A,
it adds further layers of encryption, by encrypting the cell with the shared key KA−Y .
When the relay cell is received from the OP A, A can decrypt each single layer since it owns the
shared keys used for the encryption made in each hop of the circuit.
Figure 1: Onion Proxy A builds a two-hop circuit to reach a web page.
How does an Onion Proxy can choose Onion Routers to include in the random path?
Tor uses a set of redundant, synchronized and well-known Onion Routers, known as Directory
Servers, to track changes in network topology and node state.
Directory Servers act as HTTP servers: clients can collect current network state and router lists,
since ORs periodically upload signed state informations to each Directory Server.
The Directory Servers combine this obtained information with their views of network liveness
and generate a signed description (a directory) of the entire network state.
New nodes must be approved by the Directory Server Administrator before they are in-
cluded in the network. Furthermore, existing ones are checked by Directory Servers: when a
DS receives a signed statement for an OR, it checks whether the ORs identity key is recognized.
7

Summarizing, when an user (Onion Proxy A) want to send a message m to a web server S, the
Tor communication provides several steps:
OP A asks to the Directory Server D (a particular Onion Router) for the current state
of the network and for Onion Routers which are online;
OP A picks an arbitrary random number n of ORs which form a random path from A to S;
Using AES, OP A decides a symmetric shared key with each OR Xi of the random path;
Tor encrypts the whole message (including the IP Address of A) as many times as they
are the ORs in random path. Each layer of encryption is made using the AES symmetric
shared key KA−Xi established between A and Xi ;
The encrypted message is sent through the virtual circuit formed by the randomly chosen
Tor relays;
At each hop of the circuit, the OR Xi decrypts only its layer of encryption revealing the
following relay Xi+1 in the path.
OR Xi sends the remaining encrypted data to OR Xi+1;
The final relay Xn decrypts the last layer of encryption and it sends the original message
m to the destination S, without knowing where the message is from.
The sending of the response r from S to A must follow the same random path (in reverse direction):
S knows that the message m was delivered by the exit-point relay Xn: S sends the unencrypted
response r to Xn;
Xn knows that the previous OR in the random path was Xn−1: Xn encrypts the response r
with the AES key KA−Nn (shared with A) and it sends {r}n to Xn−1;
Xn−1 knows that the previous OR was Xn−2: Xn−1 creates another layer of encryption with
AES key KA−Nn−1 (shared with A) and it sends {{r}n}n−1 to Xn−2; and so on . . .
The first relay X1 knows who was the sender A: X1 makes the last encryption on r and it
send the final encrypted response {. . . {{r}n}n−1 . . .}1 to A;
A can decrypt the cipher-text, obtaining the original response r since it owns the AES keys
used for the layered encryption of the data;
The stream between A and S is closed and the circuit is changed every few minutes.
8

1.4 Tor: Strengths and Limits
It’s possible to notice that Tor usage presents both advantages and disadvantages.
Pros
+ Anonymity: Tor technology provides anonymity to both Client and Server sides:
Client: a Tor user can hide its location while browsing the Web or using online
services.
Server: in Tor network there is a particular type of services which are configured to
receive inbound connections and could be accessed only by using Tor, since their exact
server location is unknown. These are the so-called hidden services (.onion sites).
+ Hide IP: the IP address of the Tor user which is accessing the deep or dark web is hidden
and it is (almost) impossible to track it.
+ Security: if Tor is used together with HTTPS, security is guaranteed since HTTPS encrypts
the payload so that only the recipient can see the content of packets at the end of the routing.
+ Doubled Security: if a VPN service is coupled with Tor, the security protection is doubled.
+ Hard to Attack: common attacks like Eavesdropping, Man in the Middle and Traffic
Analysis are hard to exploit against an attentive Tor user. Furthermore, for the latter
attack, the more are the Tor users, the harder is to analyze the traffic.
+ Open Source: the Tor code is available and it can be inspected by any security expert,
reducing the risk of malicious backdoors.
+ Easy and Free: to use the Tor network, a common user does not need to make hard
configurations; the user have only to download and install the Tor browser bundle.
+ Well Supported: Tor is supported by all major operating systems.
Cons
− Performances: Tor messages travel through a virtual circuit, crossing Tor relays, before
being delivered to the final destination. This process obviously slows down the communication
between sender and receiver. Moreover, bandwidth speeds are often reduced when using Tor.
− End Node Decryption: the last node of the circuit has to decrypt the communication
message before delivering it to its final destination. There is the possibility that someone
which is operating on that node can see/tamper the data passing through this server.
To face this problem, a secure protocol (such as SSL or SSH) should be used on top of Tor.
− Traffic Encryption: an attacker which is monitoring the connection could still obtain sen-
sible data (like usernames and passwords) that are transmitted in plain text. To avoid the
problem of monitoring, a VPN should be used on top of Tor.
− Possibility to be targeted: Tor network is a high-priority target for authorities which can
monitor and track the user connection even if they can’t find the real IP address.
9

− Third-Part Apps: to stay anonymous, a Tor user should avoid to use third-party apps
(like plug-ins or add-ons) which are not protected by Tor and which could share sensitive
user informations.
− Tor Connection Refused: some sites make harder (or impossible) the user verification tests
(e.g. captcha) when a user visits them by using Tor. Other sites just refuse the connection.
Figure 2: Different captchas in Google Services using Tor and Incognito Mode
− User’s Purposes: Tor is designed to guarantee the anonymity to the user; but not all users
have good purposes... There are terrorists, pedophiles, drug dealers, killers, etc... which are
interested to stay anonymous because they want offer their illegal “services” in the Web.
Figure 3: Crypto Market hidden service
10

1.5 Attacks against Tor network
In recent years, researchers have introduced different approaches to attack the Tor network stating
that it is possible to break its security and/or anonymity. In this section some of these attacks will
be presented.
1.5.1 RAPTOR: Routing Attacks on Privacy in Tor
Researchers from Princeton University and the Swiss Federal Institutes of Technology Zurich
have demonstrated the effectiveness of a suite of traffic analysis attacks, called RAPTOR, which
deanonymize Tor users.
The RAPTOR approach is based on a known vulnerability of the Tor network: an adversary who
can observe the traffic on both endpoints of the Tor communication channel (i.e., the first link
Client →Tor and the last link Tor → Server), can correlate packet sizes and packet timings to
deanonymize Tor users.
An adversary could gain visibility into Tor traffic essentially by using two ways: by manipulating
Tor, owning enough Tor relays; or by manipulating the routing, creating malicious network
communications and gaining a position on the forwarding path for Tor traffic.
N.B.: regarding routing threats, large Autonomous Systems (ASes), such as Internet Ser-
vice Providers (ISPs), can easily eavesdrop on a portion of all links, and observe any unencrypted
information, packet headers, packet timing, and packet size.
RAPTOR exploits the latter way by using three individual attacks, whose effects are compounded,
based on the fact that user anonymity decreases over time due to Border Gateway Protocol
(BGP) dynamic aspects.
Attack 1: Asymmetric Routing
Raptor exploits the asymmetric nature of Internet routing, as the BGP path from a sender
to a receiver can be different than the BGP path from the receiver to the sender.
Figure 4: Asymmetric routing increases the power of AS-level adversaries.
When considering forward traffic, i.e. Client → Tor entry and Tor exit → Server, only
AS5 can compromise anonymity.
When considering both forward and backward traffic though, AS3, AS4 and AS5 can com-
promise anonymity.
11

Attack 2: Natural BGP Convergence
Raptor exploits natural breaking in Internet routing, in which BGP paths change over time
due to failures of links/routers, to the setup of new links, or to changes in autonomous
system routing policies. BGP churn increases the number of ASes that can deanonymize
Tor traffic.
Initially, only AS5 can deanonymize the client, seeing both direction of the traffic.
After the failure of link < AS4, AS5 >, both AS5 and AS3 can deanonymize Tor traffic.
Attack 3: Active BGP Manipulation
Raptor exploits the inherent insecurity of Internet routing, in which adversaries can manip-
ulate Internet routing via BGP hijack and interception attacks (MITM) against Tor.
BGP interception attack enables ASes to selectively put themselves on some path.
AS3 only sees traffic between the Client and the Tor entry relay.
12

By intercepting the prefix containing the Tor entry relay, AS3 also sees traffic towards the
Tor exit relay, enabling it to deanonymize the Tor communication.
The RAPTOR suite has been tested on the live Tor network and asymmetric traffic
analysis attacks deanonymized users with 95% of Accuracy, whilest BGP interception
attack deanonymized Tor users with 90% of Accuracy.
Figure 5: Asymmetric Traffic Analysis Accuracy Rate.
Figure 6: Asymmetric Traffic Analysis Error Rate confidence interval.
Figure 7: BGP Interception Accuracy Rate.
13

1.5.2 Browser-Based Attacks on Tor
A MIT team of researchers has proposed a browser-based attack which breaks the anonymity of
web browsing with Tor.
The attack is delivered by a malicious exit node using a Man-In-The-Middle attack on HTTP
and it tricks the user’s web browser into sending a distinctive signal over the Tor network that
can be detected using traffic analysis.
Both the attack and the traffic analysis can be performed by an adversary with limited resources.
The attack uses a malicious Tor exit node that modifies HTTP traffic passing through it, inserting
an invisible iframe containing JavaScript into requested webpages. The JavaScript repeatedly
contacts a malicious web server, posting a unique ID. This JavaScript continues to run as long as
the client leaves the bugged browser tab open.
The attack is formed by several steps:
1. The attacker first sets up the necessary resources.
• The attacker inserts two malicious nodes into the Tor network: one which acts as an
entry node and the other which acts as an exit node;
• The attacker sets up a web server that receives and logs JavaScript connections.
2. The malicious exit node modifies all HTTP traffic to include an invisible JavaScript signal
generator that sends a unique signal for each Tor client.
3. The Tor client’s web browser executes the JavaScript code, sending a distinctive signal to
the web server. This traffic passes through the Tor circuit, and the client is still anonymous.
4. Approximately every 10 minutes, the Tor client chooses a new circuit. Eventually, a Tor
client selects and uses the malicious entry node.
5. The attacker performs traffic analysis to compare the signals on each circuit passing through
his entry node with the signals received by the malicious web server.
A match reveals the Tor client’s identity and its corresponding traffic history during the
time it used the malicious exit node.
Figure 8: JavaScript Browser Attack.
14

There is a main difference between this attack and other attacks related to Traffic Analysis:
for most traffic analysis attacks, the attacker must control both the exit node and entry node
at the same time. This attack instead uses a different approach: if a client has an open window in
the browser running the JavaScript signal generator and it chooses a malicious entry node, then
the timing attack can reveal his identity.
This only requires the “right” choice of a entry node: the probability that the client is compromised
each time he chooses a new circuit is roughly 1
ne
, where ne is the number of available entry nodes.
If the attacker had to get control of both the entry and exit nodes at the same time, then the
probability would then be 1
ne·nx
, where nx is the number of available exit nodes.
Thus, the signal generator allows the attacker to decouple the need to control both an exit and
an entry node at the same time, decreasing the expected time to compromise the client.
Torbutton Attack
The described browser attack requires that JavaScript is enabled on the victim’s machine.
This requirement is unnecessary: the same attack can be implemented by using the HTML meta
refresh tag. The webpage is modified such that it will automatically be refreshed by the web
browser after a period of time. The attacker generates the desired traffic signal by dynamically
varying the refresh delays or the page size each time the webpage is refreshed.
The HTML Meta Refresh version of the attack is more evident than the JavaScript version:
browsers generally indicate when they are reloading a webpage, while they typically do not indicate
when JavaScript requests are executed.
So, it is easier for the user to detect the Meta Refresh version of the attack than the JS one.
This can be mitigated by only performing the attack on sites that already have a meta refresh tag.
Example: Torbutton Add-on
Torbutton is a simple Firefox extension that allows a user to choose to use the browser under a
Tor proxy or not, by a single click.
This could be an useful interface especially when the user is weary of Tor’s slow performances and
he decides to turn Tor off while browsing sites which do not require to stay anonymous. But
Torbutton’s distracted use could have bad consequences: if a user deactivates the Tor proxy using
Torbutton, but leaves an open tab with one of the described JavaScript signal generators, then
it will be discovered the next time the signal generator contacts the attacker’s server.
In practice, this relatively simple attack is effective to discover Tor clients who stop using the
Tor proxy while the browser is still open.
Figure 9: Torbutton Attack.
15

1.5.3 The Sniper Attack: Anonymously De-Anonymizing/Disabling the Tor Network
A research team of U.S. Naval Research Laboratory and Humboldt University of Berlin introduced
an attack which exploits a vulnerability in the design of Tor’s flow control algorithm.
Tor Flow Control Scheme
The flow control scheme is a window-based control scheme used to limit the amount of data that
may be sent between the exit and the entry relays to a value of 1000 cells (∼ 500 Kb) per circuit.
This is necessary because the client may request the exit relay to fetch large amounts of data; so,
Tor needs to limit the amount of data each relay needs to buffer in memory at once.
When a new circuit is created, the exit relay will initialize its circuit package counter to 1000 cells.
The exit relay decrements the package counter by one for every data cell sent into the circuit (i.e.,
to the middle relay), and it stops sending data when the package counter reaches 0.
The client relay at the other end of the circuit keeps a delivery counter and initializes it to 0.
The client increments the delivery counter by one for every data cell it receives on that circuit.
When the client’s delivery counter reaches 100, it sends a special control cell, called SENDME, to the
exit relay to report that it received 100 cells. Upon receiving the SENDME, the exit relay adds 100
to its package counter and continues sending data into the circuit.
The same mechanism is used when data is flowing in the opposite direction (Client → Entry →
Middle → Exit).
The Sniper Attack is a Denial of Service (DoS) attack which exploits the Tor’s flow control
algorithm to remotely crash a victim Tor relay by exhausting its memory resources.
The attack is formed by 3 different attacks, which rely onto the following techniques:
the attacker stops reading from the TCP connection containing the attack circuit, which
causes the victim’s TCP window to close and the victim to buffer up to 1000 cells;
the attacker causes cells to be continuously sent to the victim (exceeding the 1000 cell limit
and overloading the victim’s memory resources) either by ignoring the package window, or by
continuously sending SENDME cells from the delivery end to the packaging end, even though
no cells have been read.
Basic Version 1: Attacking an Entry Relay
Figure 10: Sniper Attack - Basic Version1
The adversary owns the client and the exit relay and chooses a victim for the entry relay position.
(a) The client creates a circuit using the target as the entry relay.
16

(b) The exit relay continuously generates packages and sends arbitrary data through the circuit
toward the client while ignoring the package window limit.
(c) The client stops reading from the TCP connection to the target entry.
(d) The target entry buffers all the data being sent by the exit relay until the Tor process is
terminated by the OS out-of-memory killer.
Basic Version 2: Attacking an Exit Relay
Figure 11: Sniper Attack - Basic Version2
The adversary controls the client and the Internet destination server (e.g. website) and chooses a
victim for the exit relay position.
(a) The client creates a circuit using the target as the exit relay and connects to the server.
(b) The exit relay continuously generates packages and sends arbitrary data through the circuit
toward the exit relay while ignoring the package window limit.
(c) The destination server stops reading from the TCP connection to the target exit.
(d) The target exit buffers all the data being sent by the exit relay until the Tor process is
terminated by the OS out-of-memory killer.
Efficient Attack
Both of the basic versions of the attack require the adversary to generate and send data, consuming
roughly the same amount of upstream bandwidth as the victim’s available memory.
The efficient version reduces this cost by one to two orders of magnitude.
Figure 12: Sniper Attack - Efficient Version
The adversary controls only a client and repeats the following steps several times in parallel.
(a) The client creates a circuit using the target as the entry relay.
17

(b) The client begins a large file download from an external file server through the circuit.
(c) The client stops reading from the TCP connection to the target entry.
(d) The client sends SENDME cells to the exit, causing it to continue sending data through the
circuit. The rate of SENDME cells is low enough to avoid exceeding the package window size
of the exit relay.
(e) The target entry buffers the data until the Tor process is terminated by the OS killer.
The attack is an extremely low-resource attack and its bandwidth cost after circuit creation
is simply the bandwidth cost of occasionally sending a SENDME to the exit relay.
The memory consumption speed depends on the bandwidth and congestion of non-victim circuit
relays. It has been proven that with roughly 50 KiB/s of upstream bandwidth, an attacker could
consume the victim’s memory at roughly 1 MiB/s (highly dependent on the victim’s bandwidth).
The team has implemented some experiments to test the attack using Shadow, a discrete-event
network simulator that runs the real Tor software in a safe, private testing environment.
The results were impressive: the Sniper attack can disable the fastest (in terms of bandwidth)
exit relay in a range of 1-18 minutes (depending on relay RAM capacity).
The entire group of the top 20 exit relays, representing the 35% of Tor bandwidth capacity (at the
time of the analysis - 2014), could be disabled in a range of 29 minutes to 3 hours and 50 minutes.
They also analyzed how the attack could potentially be used to deanonymize hidden services
and they found that it would take between 4 and 278 hours before the attack would succeed (again
depending on relay RAM capacity, as well as the bandwidth).
The outcomes were devastating and the team cooperated with Tor foundation to fix the problem.
Nowadays, Tor network is no longer vulnerable as before and the issue is partially fixed: the
main defense implemented into the Tor software is to start killing circuits when memory gets
too low.
Currently, Tor has a configuration option (MaxMemInCellQueues) that allows a relay operator to
configure when the circuit-killer should be activated.
Obviously, there is not a single correct value for this field: if MaxMemInCellQueues value is too
high, then relays with lower memory will not be protected; if it is too low, then there may be more
false positives resulting in honest circuits being killed.
It’s still an open problem: can Tor determine this setting in an OS-independent way that allows
relays to automatically find the right value for MaxMemInCellQueues?
The defense adopted against the Sniper attack prevent the adversary from crashing the victim
relay, but the adversary may still consume relay’s bandwidth and memory resources to a critical
level, at relatively low cost.
This means that even though the Sniper attack can no longer kill a relay, it can still consume a
large amount of Tor relay resources.
18

1.5.4 Circuit Fingerprinting Attacks: Passive De-Anonymization of Hidden Services
A research team from MIT and Qatar Computing Research Institute presented an attack in which
the goal was to break the anonymity of Tor Hidden Services as a passive and local adversary,
called Circuit Fingerprinting.
Website Fingerprinting
Website Fingerprinting (WF) is a class of traffic analysis attacks.
WF demonstrates that a local passive adversary observing the encrypted traffic is able (under
certain conditions), to identify the website being visited by the user. The strategy is as follows:
The attacker tries to emulate the network conditions of the monitored clients by deploying
his own client who visits websites that he’s interested in classifying through the live network.
During this process, the attacker collects the network traces of the clients.
The attacker trains a supervised classifier with many identifying features of a network
traffic of a website (e.g., sequences of packets, size of packets, inter-packet timings, etc ...).
Using the model built from the samples, the attacker then attempts to classify the network
traces of users on the live network.
As the name suggests, the Circuit Fingerprinting projects aims to emulate the technique of
Website Fingerprinting by adapting it to discover and classify Tor hidden services circuits.
The goal of the attack is divided in two parts:
Identify Hidden Services and their circuits;
Classify Hidden Services once the circuits are isolated.
To understand how different hidden service circuits behave, they carried out some experiments
using a group of Tor clients, some of their own hidden services and scanning ∼1000 hidden services.
The research is based on the observation of the Cumulative Distribution Function (CDF) of
different key factors: the Duration Of Activity (DOA), Incoming Cells and Outgoing Cells.
Duration of Activity: it’s the period of time during which a circuit sends or receives cells.
The expected lifetime of a circuit is around 10 minutes, but circuits may be alive for more or
less time depending on their activities.
Outgoing/Incoming Cells: number of cells which sent to/from the hidden service.
Figure 13: Cumulative Distribution Function (CDF)
19

The features reported in the graphs and exploited by the Circuit Classification attack are:
Duration Of Activity graph: HS-IP circuits have a long life because they serve as contact
points for HS and they must be reachable in time, while Client-IP ones have a short life
because they are used only one time by the clients that want to contact the Hidden Services
telling them info about the Rendezvous Point.
Incoming and Outgoing Cells graph: HS-IP and Client-IP circuits have low values
because they serve just as request-response protocol, so no other data travels through them.
HS-RP circuits have more outgoing cells than incoming and the reason is that usually servers
receive a small request and they have to send a complete response, which is bigger (for example
a request for an image is a string and the response is the encoding of the image itself).
There are other important observations made by the research team:
• Streams for different .onion domains are not multiplexed in the same circuit.
If the user requests for google.com and amazon.com using Tor, then the requests travel
through the same circuit; while if the user requests for two different .onion Tor Hidden
Services, then Tor assigns to the user different circuits.
• Tor does not use IP or RP circuits for general streams.
Tor assigns different purposes to circuits when they are established.
For streams accessing non-hidden servers, Tor enstablishes general purpose circuits which
can carry multiple logical connections (i.e., Tor multiplexes multiple common service streams
into one circuit).
On the other hand, streams accessing a .onion domain (hidden service) are assigned to
circuits that have a rendezvous-related purpose, which are different from general circuits.
So, IP and RP circuits are disjoint from general circuits.
By analyzing and classifying the Tor network, five types of circuits are been identified:
1. HS-IP: circuit established between the Hidden Service (HS) and its Introduction Point
(IP). The purpose of this circuit is to listen for incoming client connections.
2. Client-RP: circuit that a Client builds to a randomly chosen Rendezvous Point (RP)
to eventually receive a connection from the HS after he has expressed interest in establishing
a communication through the creation of a Client − IP circuit.
3. Client-IP: circuit that a Client interested in connecting to a HS builds to one of the IPs
of the HS to inform the service of its interest in waiting for a connection on its RP circuit.
4. HS-RP: circuit that the HS builds to the RP onion router chosen by the client to establish
the communication with the interested client. Both HS-RP and Client-RP circuits connect
the HS and the Client together over Tor.
5. General: circuit between common Tor endpoints (no HS).
The classifiers used to find these classes are Tree-based and k-NN classification algorithms.
From every type of circuit, it has been created an instance formed by of its sequences (first 10
cell), DoA, total number of incoming and outgoing cells (within the first 50 cells in the circuit) and
a class label corresponding to the circuit type.
20

The datasets returned the following results, with a ∼ 95% accuracy:
IP-Noise dataset: it consists of 76 HS-IP, 200 Client-IP, and 6593 noise circuits.
The circuits labeled with the class noise circuits consist of 954 HS-RP, 4514 Client-RP, and
3862 general browsing circuits.
RP-Noise dataset: it contains 200 Client- RP, 200 HS-RP, and 3862 noise circuits.
Figure 14: Number of instances of different circuit types.
At the end of the attack, we know if there is an hidden service in the network, as well as whether
there is an introduction point circuit or a rendezvous point one for each side (client or server).
After that, the website fingerprinting attack could be used against hidden services in order to
understand which HS they are analyzing.
The team used the WF against 50 sensitive HSs and 950 non-sensitive HSs, for a total of 1000 HS.
In Figure 15 there are the client classification result (left), with an accuracy over 80% and the
server one (right) (server offering the page), with an accuracy in a range from 80% to 96%.
The researchers suggest some potential defenses against the attack:
Figure 15: Client/Server Accuracy (TPR and FPR).
• Circuit Classification Defense: the attacks rely on special properties of the circuits used
for hidden service activities. The used features of the circuits are very identifiable: DoA,
number of outgoing/ingoing cells. So, first of all Tor should address the three features by
forcing all circuits to have similar lifetime, since Client IP and hidden service IP lasts either
a very short or very long time, and this is very identifying.
• Website Fingerprinting Defense: for WF attacks, defenses proposed by Wang et al. -
“Effective Attacks and Provable Defenses for Website Fingerprinting” [18] will be effective.
21

1.5.5 Spoiled Onions: Exposing Malicious Tor Exit Relays
Spoiled Onion is a research project work between the PriSec group at Karlstad University in Sweden
and SBA Research in Austria about Tor exit relays.
Exit relays can see traffic in clear as it was sent by the Tor user; so, their role is particularly
sensitive compared to other Tor nodes (entry guards and middle relays), especially because traffic
does not have end-to-end encryption.
By design, exit relays act as a Man-In-The-Middle (MITM) in between a user and its destination.
This makes it possible for exit relay operators to run various MITM attacks such as Traffic
Sniffing, DNS Poisoning, and SSL-based attacks such as HTTPS MITM and Sslstrip.
An additional benefit for attackers is that exit relays can be set up quickly and anonymously, thus
making it very difficult to trace attacks back to their origin.
The project was focused on finding and counter-attacking people who run malicious exit relays
to tamper connections and or deanonymize users.
In order to do that, the research team developed:
Exit Map: a flexible and fast exit relay scanner which is able to detect several popular
MITM attacks.
HoneyConnector: a framework to detect sniffing Tor exit relays based on FTP and
IMAP fake connections.
Torbutton Patch: a patch for the Torbutton browser extension [1.5.2] which fetches
and compares X.509 Certificates over different Tor circuits, to detect MITM attacks
against HTTPS.
Using exitmap and HoneyConnector, the team monitored the Tor network over a period of mul-
tiple months in two independent studies. In total, they identified 65 exit relays that conducted
MITM attacks or reused sniffed credentials.
exitmap
Exitmap is a lightweight Python-based exit relay scanner. Its purpose is to create custom circuits
to exit relays that will be probed by modules, creating decoy connections to various destinations.
Figure 16: Design od exitmap
The goal is to cause exit relays to tamper
with the connections, revealing their ma-
licious intent and then being classified as
Spoiled Onions.
The tool runs on a single machine and re-
quires the Python library Stem, which imple-
ments the Tor control protocol used to initi-
ate and close circuits, attach streams and to
parse network consensus.
Once exitmap created a circuit with one of
the targeted exit relays, it invoked the de-
sired probing module which then proceeded
by establishing a connection to a decoy des-
tination. A stream of a probing module was
then attached to the respective circuit.
22

In order to be able to detect specific attacks, the team developed several probing modules by
assuring the indistinguishability of these new modules from original Tor clients, since malicious
relays inspect exit traffic from only target connections which appear to be genuine.
HTTPS: HTTPS module which fetches a decoy destination’s X.509 certificate and extracts
its fingerprint. This fingerprint is then compared to the expected fingerprint hard-coded in
the module. If they do not match, the program will trigger an alert.
XMPP and IMAPS: similar to the HTTPS module, these two modules establish a TLS
connection to a decoy destination, extract the server certificate’s fingerprint, and compare it
to the respective hard-coded to expected fingerprint.
sslstrip: instead of interfering with TLS connections, an attacker can try to directly avoid
TLS connections using sslstrip. The tool simply rewrites HTML documents sent from the
server to the client, exchanging HTTPS links with HTTP links.
It is a silent attack: browsers will not show certificate warnings. Vigilant users, however,
might notice the absence of browser-specific TLS indicators such as lock icons or green bar.
SSH: Tor network is also used to transport SSH traffic (e.g., using torsocks tool).
Similar to HTTPS attacks, malicious exit relays could run MITM attacks against SSH.
In practice, this is not easy thanks to trust on first use SSH model: if the very first
connection to an SSH server was secure, the public key is then stored by the client and kept
as reference for subsequent connections.
As a result, a MITM attack has to target a client’s very first SSH connection. Nevertheless,
this might not stop attackers from interfering with SSH connections.
The SSH module makes use of the OpenSSH libraries ssh and torsocks to connect to a decoy
server: as before, the server’s key fingerprint is extracted and compared to the hard-coded
expected fingerprint.
However, it is difficult to achieve indistinguishability over time: a malicious relay operator
could monitor an entire SSH session. If it looks suspicious, the attacker could decide to
whitelist the destination in the future.
To address this problem, it’s possible to establish SSH connections to random hosts on the
Internet, but it’s not considered good Internet citizenship). So, the team published the source
code and encouraged every exitmap user to use its own SSH server as decoy destination.
Figure 17: Scanning Module which probes SSH.
23

DNS: while the Tor protocol only transports TCP streams, clients can ask exit relays to
resolve DNS records by wrapping domain names in a RELAY BEGIN cell. Once a circuit is
established, this cell is then sent to the exit relay for resolution.
The DNS probing module maintains a whitelist of domains together with their corresponding
IP addresses and raises an alert if the DNS A record of a domain name is unexpected.
HoneyConnector
HoneyConnector is a framework for establishing fake connections over Tor using unique credentials
over FTP and IMAP and for detecting their subsequent use to identify sniffing exit relays.
The framework can be divided into several components:
1. HoneyConnector Client: component written in Python, which is responsible for creating
new credentials, establishing the actual bait connection over the respective exit relays, and
communicating them to the deployed services over a secure channel for creating the accounts
and bait data. Furthermore, HTTPS certificates are fetched by the client and compared with
the real certificates to detect MITM attacks against HTTPS.
2. Tor client: a copy of the Tor client.
3. Stem Library: HoneyConnector uses the library Stem to have control over which exit relay
is selected for a circuit and to check if a given exit policy allows connections to bait services.
4. Backend Database: a DB for storing the bait credentials and timestamps, as well as addi-
tional exit relay information.
The HoneyConnector Client uses these components to implement both FTP and IMAP scannings:
in both cases login credentials are generated and sent to the specific server, after their uniqueness
was verified. The concatenation of username and password allowed HoneyConnector to identify
which exit relay sniffed a given pair of credentials.
After the software development phase, the team ran a first full scan over ∼ 950 exit relays (a
part of the Tor network at the time, 2014).
The results are represented in Figure 18: the ECDF’s x-axis shows the amount of seconds it takes
for a module to finish successfully; the y-axis shows the cumulative fraction of all exit relays.
The diagram shows that all modules are able to scan at least 98% of all responsive Tor exit relays
under 50 seconds. The DNS module was slower, because it resolves several domain name at once.
Figure 18: Performances of probing modules.
24

Figure 19 contains the 40 malicious and misconfigured exit relays founded by the scan.
Figure 19: Malicious and misconfigured exit relays discovered.
The results were interesting: apart from all the HTTPS, XMPP and SSH MITM attacks, several relays
running sslstrip were exposed. Besides, relays in Malaysia, Hong Kong, and Turkey were subject
to DNS censorship. A single relay, namely 5A2A51D4, made HTML injection of custom HTML
code into HTTP traffic. Finally, four relays were misconfigured as they used an OpenDNS policy
which censored at least web sites in the category “pornography”.
25

During a four month deployment of HoneyConnector, the researchers registered a total of 255 login
attempts with 128 sniffed plaintext credentials, tracing back to 27 sniffing exit relays.
Among all 255 login attempts, 136 were targeting FTP and 119 were targeting IMAP.
From all 128 sniffed credentials, 97 were for FTP and 31 for IMAP.
Figure 20 represents all the 27 exit relays which were found sniffing login credentials.
Figure 20: Sniffing exit relays discovered.
Figure 21 illustrates the amount of login attempts over time.
Figure 21: Distribution of login attempts.
26

2 Garlic Routing
Present the “garlic routing” and compare it to the onion routing in terms of security
and efficiency.
2.1 Invisible Internet Project (I2P)
Garlic Routing is often used when referring to the Invisible Internet Project (I2P) which
is a message-oriented, peer-to-peer-based and low latency anonymous communication network.
I2P network was first proposed in 2003 and it was mainly designed as an overlay
network to enable fully anonymous communication between two parties inside
the network itself.
Technically, I2P is a multi-application Java framework designed to provide
anonymous Peer-to-Peer (P2P) networking.
Each I2P user runs the I2P router, which is the core part of the I2P software.
All messages are relayed through tunnels built by each I2P router using other
I2P peers.
Tunnels can only be used in one direction: tunnels for outgoing/incoming traffic
need to be built, namely outbound and inbound tunnels.
The selection of peers is done via a tier-based peer selection algorithm run-
ning on each I2P router. After establishing inbound and outbound tunnels,
clients may publish their contact information in a global database, called netDB.
The netDB contains contact information for each I2P peer and each publicly running service
inside the I2P network. Messages sent through the I2P network are end-to-end encrypted using
garlic encryption: it is very similar to Onion Encryption, with the difference that multiple
data messages may be contained in a single garlic message.
A single garlic message may contain multiple messages for different recipients.
I2P Router: the I2P network is formed by peers (also-called clients, nodes or routers)
running the I2P software, allowing applications to communicate through the I2P network.
The core part of this software is the I2P router which is responsible for maintaining peer statistics
(required for peer selection), performing cryptography, building tunnels, providing services and re-
laying messages. The anonymity of applications heavily rely on tunnels built by the I2P router.
NetDB: in I2P network there are a particular kind of peers, called flood-fill peers, which
are used to build and manage a network database, called netDB.
The netDB is based on a distributed hash table and contains all known information about the
I2P network (all I2P peers and services).
Each flood-fill peer is only responsible for information of a specific part of the network: to
determine which part of the network a flood-fill peer is responsible for, the Kademlia XOR
distance metric is used, based on the peers ID.
The netDB stores two types of data: a routerInfo and a leaseSet.
routerInfo: data structure used to identify I2P peers, containing the information about
the peer (IP address, port, peer ID, stable version number, network version, etc...),
its public key and a 256-bit hash-identifier.
Each I2P router directly sends its routerInfo to the netDb.
To retrieve an initial list of available I2P peer, a list of routerInfo can be downloaded
from a non-anonymous, well-known web server; this phase is called reseeding.
27

leaseSet: data structure to store information necessary for contacting a particular I2P
service, called destination. It specifies a set of entry points, called leases: each lease
specifies a tunnel gateway to reach a specific destination.
routerInfos and leaseSets, can be stored/retrieved by contacting the nearest flood-fill peer.
a) Store: the flood-fill peer will distribute the received routerInfo or leaseSet to the
seven nearest flood-fill peers.
b) Retrieve: the two closest flood-fill peers are contacted; if the requested information is
not available, the flood-fill peer replies with a list of other near flood-fill peers.
The peer keeps contacting flood-fill peers until the needed information is retrieved.
Destination : the destinations in the I2P network are identified by a 516-byte crypto key
which consists of a 256-byte public key, a 128-byte signing key and a null certificate.
A destination refers to an internal service provided by an I2P router.
To map destinations to their crypto keys, three local host files are used (similar to traditional DNS).
To merge external and local host files, I2P provides an address book application: this way of
addressing each individual destination further increases the anonymity, since it also decouples
the service from the I2P router it’s provided by.
Tunnel: the I2P messages are transmitted through the so-called Tunnels. A tunnel is a
unidirectional encrypted virtual connection between 2 or 3 peers (typically).
Unlike Tor, the router seeking to establish a tunnel is also part of it.
At startup, each router builds up some tunnels for incoming traffic, called inbound tunnel, and
outgoing traffic, called outbound tunnel. The first I2P peer of a tunnel is the tunnel gateway
and the last one is the tunnel endpoint. For outbound tunnels, the router that established the
tunnel is always the gateway; while for inbound tunnels, it is always the endpoint.
The length of a tunnel is a trade-off between performance and anonymity and it can be specified
by the user in the I2P settings: longer tunnels increase the anonymity, while they decrease the
performances and the other way around.
There are two kinds of tunnels, exploratory and client tunnels:
Exploratory: low bandwidth tunnels which are not used for privacy-sensitive operations.
A router uses this tunnel to contact floodfill peers, to retrieve the netDB and to build,
manage and destroy other tunnels.
Client: high bandwidth tunnels used to relay application messages and retrieve leaseSets.
Tunnels have a maximum lifetime of 10 minutes and after this period of time the tunnel is
destroyed and a new one is used. The technical feature of constantly rebuilding tunnels addresses
the issue to prevent traffic analysis attacks. Before to build a tunnel, a process of of peer
selection is adopted: the peer are selected according to tier profile they are assigned to. The
categorization of peers into tiers is called peer profiling; in this phase, peers sharing specific
performance characteristics are assigned to the same tier.
Peer profiling is done by the I2P router, which keeps track of performance statistics of other
peers and maintains an updated database containing this statistics, called profiles.
Every 30 seconds all profiles are sorted into 3 tiers based on various metrics (as speed and capacity):
Not-Failing: all the known peers of the I2P network;
Well-Integrated: peers that know many other peers in the network;
28

High-Capacity: peers that are known to most likely accept tunnel build requests.
Fast: peers from the high-capacity tier with a high bandwidth.
When constructing a client tunnel, peers from the fast tier are used; if no sufficient amount of fast
tier peers is available, then high-capacity tier peers are selected.
High-capacity tier peers, instead, are typically used when constructing an exploratory tunnel.
Both, the well-integrated and not-failing tier peers are fallback options, if no other peers belong-
ing to high-capacity and fast tiers are available (however, this is unlikely to happen in practice).
Garlic Routing: once that at least an outbound and an inbound tunnels are been constructed,
the I2P router is able to send and receive messages through the I2P network.
To create a communication with a I2P service, the I2P router needs to retrieve the destina-
tion of this service from a flood-fill peer; the destination specifies a set of inbound tunnel
gateways of the corresponding service.
I2P uses the Garlic Routing, a variation of the Onion Routing design, in which garlic mes-
sages can contain multiple data messages with additional routing instructions, called cloves.
The data messages are end-to-end encrypted with the receiver’s public key and the garlic message
itself is encrypted multiple times using the symmetric keys negotiated with the peers included
in the tunnel. When traversing the tunnel, each I2P peer removes one layer of encryption until
the garlic message reaches the outbound endpoint of the tunnel. The outbound endpoint forwards
each message to its the destination of the inbound gateway. The inbound gateway will forward
the garlic message to the actual recipient while each peer included in the tunnel adds one layer
of encryption (using the negotiated symmetric keys).
At the end, only the recipient is able to remove all encryption layers of the garlic message as
well as the end-to-end encryption of the data-messages.
Generally, a garlic message will contain only one clove; however, the router will periodically
include two additional cloves:
Delivery Status Message: acknowledgment message used for determining the success or
failure of end-to-end message delivery.
Database Store Message: it contains Delivery Instructions which specifies the far-end
destination router for the response message.
By default, the Delivery Status and Database Store messages are bundled when the local
leaseSet changes, when additional Session Tags are delivered, or if the messages have not been
bundled in the previous minute.
Figure 22: Garlic Message.
29

Garlic Encryption: The encryption used in I2P is a combination of symmetric and asymmet-
ric encryption algorithms which provide data confidentiality and integrity to garlic messages, called
ElGamal/AES+SessionTags.
When a router has to encrypt a garlic message to another one, it encrypts the keying material
for an AES256 session key with ElGamal and appends the AES256/CBC encrypted payload to it.
The AES encrypted section contains other info such as the SHA256 hash value of the unencrypted
payload, the length of the payload and a number of Session Tags (32-bytes random nonces).
The next time the sender wants to encrypt a garlic message, rather then using ElGamal to en-
crypt a new session key, it can simply choose one of the previously delivered session tags and,
like before, AES to encrypt the payload using the session key used with that session tag. When
a router receives a garlic encrypted message, it checks the first 32 bytes to see if it matches an
available session tag and if it does, it decrypts the message using AES; but if it does not match,
it decrypts the first block by AES.
N.B.: each session tag can be used only one time to prevent attackers from correlating different
messages between the same routers.
Session tags have a short lifetime, after which they are discarded if not used.
The quantity stored for each key is limited, as the number of keys themselves: if too many arrive,
either new or old messages may be dropped.
A Session will continue to exist until all its tags are exhausted or expired.
Sessions are unidirectional and they may be established between Destinations, between Routers,
or between a Router and a Destination.
Each Router and Destination maintains its own Session Key Manager to keep track of
Session Keys and Session Tags.
30

2.2 I2P vs. Tor: Main Differences
Making a comparison between the Garlic and the Onion routing technologies, there are several
differences between the two networks, some more obvious while other are more technical:
Circuits vs Tunnels: Tor is relying on servers to build circuits and these servers are
provided by volunteers and could have low computational power, while I2P uses peers with
sufficient performances participating in the network to build tunnels.
SOCKS vs API: Tor uses the Socket Secure (SOCKS) interface and therefore it can be
used with any application which is configured to use SOCKS. So, Tor acts as a proxy server.
On the other hand, I2P is a middleware providing an API which can be used by applications
to communicate through the I2P network. This means that applications either need to be
costly updated or implemented from scratch and they are typically made to access services
only inside the I2P network (with some exceptions).
Another technical difference relies on the fact that the SOCKS interface is only able to transmit
messages over TCP; while I2P has the choice between both UDP and TCP. This may enable I2P
to deliver better performances when using certain applications.
Entry Guards: in Tor only the first OR of a circuit knows the IP address of the actual
user, all subsequent ORs only know its predecessor and successor; moreover only the last
OR in the circuit knows the actual receiver. This is a potential risk since corrupted ORs
may be able to link communicating parties together. Therefore, the user’s anonymity highly
depends on Tor node selection algorithm, selecting trustworthy entry guards.
In I2P, even the first peer does not know if it’s forwarding the message for another peer
of the tunnel or if it’s the actual sender. Therefore, entry guards are not necessary.
End-to-End Encryption: both Tor and I2P networks offer various layers of encryption
either by the TLS connection maintained by the Tor Onion Relays or by I2P peers.
I2P also features an additional tunnel encryption (end-to-end encryption).
Messages sent through the networks are either Onion or Garlic encrypted: the connection
from the user to the Tor circuit or I2P tunnel is always encrypted.
In the case of Tor, end-to-end encryption is not guaranteed since it depends on the
transport layer protocol that is used.
Therefore, if insecure protocols would be used, then a corrupted exit node may record messages
sent in plaintext and recover usernames and/or passwords of the user.
31

Encryption: in I2P there is a higher level of encryption because of the combination of
ElGamal/AES+SessionTags which is used by every pair of nodes in the tunnel (wrt. Tor
AES encryption only). This causes a big decrease in terms of transmission speed.
Circuits vs Unidirectional Tunnels: in I2P tunnels are unidirectional and every part
(sender and receiver) must build two tunnels, respectively for inbound and outbound traffic.
The response of a request does not come backward on the same tunnel, but it uses another
one created from the endpoint to the original sender.
So, the security is increased: the attacker can obtain only half of the information about
the request/response pattern (wrt. Tor bidirectional circuit).
But, this is also paid by a decrease of performances since each time a new tunnel must
be created for the response message.
Scalability: increasing the number of clients in the anonymous network, it directly influ-
ences both Tor and I2P. Although the anonymity set becomes larger and therefore stronger
anonymity is achieved, the network traffic increases and it may cause congestion.
In case of Tor, depending on the amount of new clients joining the network, sooner or later
there could be congestion problems such as latency increase and/or bandwidth decrease.
Moreover, increasing the amount of Tor Onion Routers also leads to the problem of
managing the growing directory: the effort to keep track of the whole network increases
since every OR should be able maintain a direct connection to each other OR in the network.
In case of I2P, new peers joining the network may also be used to build tunnels, assuming
they provide enough performance capability and bandwidth. Thus, in I2P congestion is not
likely to appear.
However, if a sufficient number of clients attempt to access services outside the I2P network,
further outproxies may have to be provided.
Network Distribution: in Tor, the network is not fully distributed since it’s based on
the concept of central directory servers. The information about relay nodes and hidden
services are provided by authorized directories (currently 9, 0.1% of total nodes)[11].
These Authority Routers keep track of changes in the network and distribute this infor-
mation, therefore if all of them would be compromised, anonymity would be endangered.
I2P instead is fully distributed: it’s based on a distributed architecture (Distributed
Hash Table) which eliminates the risks of single point of failure.
There is a file with some known nodes published on the I2P web page and a bootstrapping
operation is required to find a I2P peer which is able to join the network.
Once this router has been found, it can be queried for more known routers and each partici-
pating relay has to locally maintain a list of all known relays.
Figure 23: Tor Authority Routers.
32

Performances: the latency and the bandwidth when accessing the public Internet with
either I2P or Tor was made in a comparison study of the University of Berlin (2011) [23].
The study revealed that while I2P was able to achieve better results when issuing simple
HTTP-GET-Requests, Tor provides clearly better results in terms of accessing whole web
pages and downloading ﬁles: in 50% of all cases, Tor was able to retrieve a whole web page
in ∼17 seconds, while I2P took ∼103.19 seconds.
In terms of download speed, Tor was able to deliver an average speed of 51.62 kB/s compared
to the 12.91 kB/s of I2P.
Visibility: Tor network has a greater visibility in the landscape of anonymizing networks.
It is largely used by governments, hackers and also common people that in many countries
try to elude censorship. Moreover, the documentation related to Tor is more detailed and
complete with respect to I2P and it is available in diﬀerent languages.
Programming Language: Tor is developed using C, while I2P is based on Java.
33

3 Hidden Services
Detailedly discuss how hidden services work and what steps are needed to setup one
of them.
3.1 Internet as “Set of Subsets”: Surface, Deep and Dark Web.
The web we visit every day represents only a small percentage of the actual content of the entire
network and under the surface there is much more to discover.
Let’s start by explaining which are the different subsets of the web in a precise way:
Internet: it’s the regular web, that is the set of all the contents constituting the Internet.
Surface Web: it’s any content which can be indexed by a typical search engine (like Google,
Bing or Yahoo). In other words, it’s the part of the web where itis easy to find online contents
since whatever the user is searching for, it’s indexed by search engines.
However, it’s just a small portion of the network (less than 5% of online content is indexed).
Deep Web: it’s a subset of the Internet that is not indexed by the major search engines.
This means that the user has to direcly visit its contents, not being able to search for them.
The Deep Web is the largest part of the web simply because the Internet is too large to
be completely covered by search engines.
So, it is not necessarily malicious: it’s too large and/or obscure to be indexed.
Dark Web: it’s a subset of the Deep Web, also called Darknet, which is not indexed and
inaccessible through standard web browsers (it requires something special to be accessed).
It’s mainly used by people who desire strong privacy, either because they simply want to
stay anonymous (e.g. to avoid censorship) or because what they’re doing illegal activities
(e.g. buying/selling drugs, pornography, gambling, etc... ).
Figure 24: Internet: Surface, Deep and Dark Web.
The most famous content that resides on the Dark Web is found in the TOR network...
This is because Tor network offers exclusive mechanisms, called hidden services, which allow
any user to set up a service that could be used by anybody without knowing where the service is
located or who is offering it.
34

3.2 Tor Hidden Services
Hidden Services are a particular type of service (identified by the top level domain .onion)
which allow a Tor user to offer a TCP service without revealing his IP Address (its location).
Furthermore, a Hidden Service offered by Tor user can be accessed by all other users of the
Tor network, without either party being aware of the network identity of the other. Hidden
Services can be reached by using particular building blocks, called Rendezvous Points.
The motivations behind this choice of implementation of Hidden Services are:
Access-Control: the user needs a way to filter incoming requests;
Robustness: the user should be able to maintain a long-term pseudonymous identity;
Smear-Resistance: an attacker should not be able to offer a rendezvous router related to
an illegal hidden service.
Application-Transparency: although a special software is required to access hidden
servers, not required to modify user’s applications.
To set up a Hidden Service the owner generates a public/private key and selects a number of
Onion Routers (called Introduction Points) to which tunnels are set up; then, the service is
announced on a Service Lookup Server (together with the public key) and to the Tor users by
some means (e.g. message board).
When a user wants to access this Hidden Service, he should find one of the Introduction
Points through the Service Lookup Server and choose a router as Rendezvous Point to
which a tunnel is set up.
For the actual connection, the Introduction Point is informed about the Rendezvous Point
and this information is forwarded to the service owner. The service owner then sets up a tunnel to
the Rendezvous Point. Now, the connection between user and service is complete.
All these exchanges are protected with public key encryption.
3.2.1 Hidden Service Setup - First Step
An Hidden Service offered by Bob needs to advertise its existence in the network in order to be
reachable by Tor Clients: it randomly picks some Tor Onion Relays, builds circuits to them,
and asks them to act as Introduction Points by sending them its public key.
Figure 25: Hidden Server Setup - First Step
35

3.2.2 Hidden Service Setup - Second Step
The Hidden Service creates a descriptor containing its public key and a summary of each
Introduction Point. This is then signed with the Hidden Server’s private key and uploaded
into an online distributed hash table.
The descriptor will be found by Clients requesting ABC.onion where ABC is a 16 character name
derived from the Hidden Server’s public key. After this step, the Hidden Service is set up.
Figure 26: Hidden Server Setup - Second Step
3.2.3 Hidden Service Setup - Third Step
A Client Alice that wants to contact a Hidden Service needs to learn about its onion address.
After that, the Client can establish the connection by downloading the descriptor from the
Distributed Hash Table. If the download succeeds and a descriptor for ABC.onion is retrieved,
the Client knows which are the Introduction Points and the Public Key to use in order to
contact the Hidden Service. Meantime, the Client also creates a circuit to another randomly
picked Onion Relay asking it to act as a Rendezvous Point by sending it a One-Time Secret.
Figure 27: Hidden Server Setup - Third Step
36

3.2.4 Hidden Service Setup - Fourth Step
Once the descriptor is obtained and the Rendezvous Point is ready, the Client creates an
Introduce Message containing the address of the Rendezvous Point and the One-Time
Secret. The Introduce Message is then encrypted using Hidden Service’s public key and
sent to one of the Introduction Points, requesting it be delivered to the Hidden Service.
The whole communication is established through a Tor circuit: nobody can associate the Intro-
duce Message with the Client’s IP address, thus preserving the anonymity.
Figure 28: Hidden Server Setup - Fourth Step
3.2.5 Hidden Service Setup - Fifth Step
The Hidden Service receives the Introduce Message of the Client and it decrypts ﬁnding
the address of the Rendezvous Point and the One-Time Secret. Then, the Hidden Service
creates a circuit connected with the Rendezvous Point and sends the One-Time Secret to it
in a so called Rendezvous Message.
Figure 29: Hidden Server Setup - Fifth Step
37

N.B. : In this phase the Hidden Service must be attached to same Entry Guards while creating
new circuits: an attacker could set his own Tor Onion Router to force the Hidden
Service to establish an undefined number of circuits with the purpose of making his corrupted
relay chosen as entry guard, thus learning the IP address of the Hidden Service by using
a timing analysis attack.
3.2.6 Hidden Service Setup - Sixth Step
The Rendezvous Point receives the Rendezvous Message with the One-Time Secret and
it verifies that it’s the same as the one previously received by the Client. Then, it notifies the
Client about the successful connection establishment.
Now both the Client and the Hidden Service can use their Tor circuits to the Rendezvous
Point to communicate with each other. The Rendezvous Point in fact simply forwards end-to-
end encrypted messages from Client to service and vice versa.
Figure 30: Hidden Server Setup - Sixth Step
N.B. : The usage of Rendezvous Point instead of the Introduction Points for actual commu-
nication is very important: Introduction Points in fact know the public key of the
Hidden Service, while the Rendezvous Point does not know anything about its identity.
Thus, it reveals less info as possible to an attacker or a traffic analyzer.
In general, the complete connection between the Client and the Hidden Service consists
of 6 relays: 3 relays are picked by the client (with the 3rd being the Rendezvous Point) and
the other 3 are picked by the Hidden Service.
38

4 Practical Task
Setup a hidden service and report on the practical steps you had to carry out.
The hidden service must be working at time of delivery of your homework and should
print the hash SHA512(<your-email>). After my check and ack you can shut it off.
4.1 Hidden Service Setup
The configuration of the Hidden Service is quite easy if the user has a general knowledge of
web servers and system administration.
To host the Hidden Service, I choose a Linux Virtual Machine (with Debian OS) which I
have online and currently configured with nginx (web server) and SSH.
In order to have a running and working Hidden Service, the steps are:
Tor Installation: Tor is available in the Debian repository and it could be directly installed
from the Terminal; but, I had some problem with this procedure (version compatibility).
So, I manually added the Tor repository to the packet manager sources contained in the file:
/etc/apt/sources.list. The file was edited by adding the following two rows:
deb http://deb.torproject.org/torproject.org jessie main
deb-src http://deb.torproject.org/torproject.org jessie main
Then, I added the GPG Key of Tor which is used to sign the packages, by executing on
the Terminal (with administrative privileges) the two commands:
gpg --keyserver keys.gnupg.net --recv 886DDD89
gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add -
At the end, I installed the updated version of Tor by executing:
apt-get update
apt-get install tor deb.torproject.org-keyring
Tor Configuration: the configuration file of Tor is: /etc/tor/torrc; in this file I can spec-
ify the parameters that are used by Tor to locate and offer Hidden Service. So, in torrc file
I uncommented the two rows HiddenServiceDir and HiddenServicePort; then, I modified
them to indicate the path and the port number of the Hidden Service, respectively. At the
end, Tor was reloaded by executing the service tor reload command. When Tor reloads,
it creates some new files; one of them is the file /var/lib/tor/hidden service/hostname
which specifies the address of my Hidden Service.
The address that I obtained is: xu3kku2sor3kw2mr.onion.
Web Server Configuration: the usual configuration of the nginx Web Server must be
modified in in order to allow nginx to not reveal to users or attackers any info about me, the
location of the VM and info about the VM itself.
So, I edited the configuration file /etc/nginx/nginx.conf, hiding the version and disabling
the logs, by setting server tokens to off, error log in /dev/null to crit and by com-
menting the rows access log and error log.
39

Web Page: a very simply HTML web page index.html is created in the default directory
/var/www/html/ of nginx to offer the SHA512 hash value of my email address.
The SHA512 hash value is calculated by Python using the library hashlib. Then, I modified
configuration file of the web page /etc/nginx/sites-available/default so that the page
is offered by using the Tor network. At the end of the editing, the file contains:
Expose the Hidden Service: the last step is to restart the nginx Web Server with the
command service nginx restart, exposing the Hidden Service on the Tor Network.
Currently, the Hidden Service is set up and running. It could be reached in the Tor Network
(obviously, only by using the Tor Browser) by the address :
xu3kku2sor3kw2mr.onion
40

References
[1] F. D’Amore - Lecture of Web Security and Privacy (2017).
A simple introduction to Tor.
[2] R. Dingledine, N. Mathewson, P. Syverson.
Tor: The Second-Generation Onion Router.
https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf
[3] A. Davidsson.
Tor: The Onion Routing network.
https://www.cert.se/2015/11/2015-11-20_Tor_-_the_Onion_Routing_Network.pdf
[4] D. McCoy, K. Bauer, D. Grunwald, T. Kohno, D. Sicker.
Shining Light in Dark Places: Understanding the Tor Network.
https://homes.cs.washington.edu/~yoshi/papers/Tor/PETS2008_37.pdf
[5] M.G. Reed, P.F. Syverson, D.M. Goldschlag.
Anonymous Connections and Onion Routing.
https://www.onion-router.net/Publications/JSAC-1998.pdf
[6] P. Syverson
Onion Routing - Brief Selected History.
https://www.onion-router.net/History.html
[7] K. Bauer, D. McCoy, D. Grunwald, T. Kohno, D. Sicker.
Low-Resource Routing Attacks Against Tor.
https://www.freehaven.net/anonbib/cache/bauer:wpes2007.pdf
[8] Wikipedia: Tor (Anonymity Network).
https://en.wikipedia.org/wiki/Tor_(anonymity_network)
[9] Wikipedia: Garlic Routing.
https://en.wikipedia.org/wiki/Garlic_routing
[10] Tor Project: The Onion Router website.
https://www.torproject.org/
[11] Tor Network Status web application.
https://torstatus.blutmagie.de/#AppServer
[12] Tor Network Metrics.
https://metrics.torproject.org/userstats-relay-country.html
[13] Y. Sun, A. Edmundson, L. Vanbever, O. Li
RAPTOR: Routing Attacks on Privacy in Tor.
https://www.cs.princeton.edu/~annee/pdf/usenixsec15.pdf
YouTube: https://www.youtube.com/watch?v=KsqnV_ItFFg
[14] T. Abbott, K. Lai, M. Lieberman, E. Price
Browser-Based Attacks on Tor
https://www.petsymposium.org/2007/papers/PET2007_preproc_Browser_based.pdf
41

[15] R. Jansen, F. Tschorsch, A. Johnson, B. Scheuermann
The Sniper Attack: Anonymously Deanonymizing and Disabling the Tor Network
http://www.robgjansen.com/publications/sniper-ndss2014.pdf
[16] P. Winter, R. Kower, M. Mulazzani, M. Huber, S. Schrittwieser, S. Lindskog, E. Weippl
Spoiled Onions: Exposing Malicious Tor Exit Relays
https://www.cs.kau.se/philwint/spoiled_onions/pets2014.pdf
[17] A. Kwon, M. AlSabah, D. Lazar, M. Dacier, S. Devadas
Circuit Fingerprinting Attacks: Passive Deanonymization of Tor Hidden Services
https://www.usenix.org/system/files/conference/usenixsecurity15/
sec15-paper-kwon.pdf
[18] T. Wang, X. Cai, R. Nithyanand, R. Johnson, I. Goldberg
Eﬀective Attacks and Provable Defenses for Website Fingerprinting
http://www.cypherpunks.ca/~iang/pubs/webfingerprint-usenix14.pdf
[19] The Invisible Internet Project
https://geti2p.net/id/docs/how/garlic-routing
[20] Infosec Institute: Introduction to Anonymizing Networks - Tor vs I2P.
http://resources.infosecinstitute.com/anonymizing-networks-tor-vs-i2p/#gref
[21] Wikipedia: Garlic Routing.
https://en.wikipedia.org/wiki/Garlic_routing
[22] B. Conrad, F. Shirazi.
A Survey on Tor and I2P.
http://i2p-projekt.i2p.re/_static/pdf/icimp_2014_1_40_30015.pdf
[23] M. Ehlert.
I2p usability vs. Tor usability a bandwidth and latency comparison.
http://userpage.fu-berlin.de/semu/docs/2011_seminar_ehlert_i2p.pdf
[24] Tor: Hidden Service Protocol.
https://www.torproject.org/docs/hidden-services.html.en
[25] Installing Tor on Debian/Ubuntu
https://www.torproject.org/docs/debian.html.en
42

Anonymity in the Web based on Routing Protocols

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Similar to Anonymity in the Web based on Routing Protocols

Similar to Anonymity in the Web based on Routing Protocols (20)

More from Biagio Botticelli

More from Biagio Botticelli (9)

Recently uploaded

Recently uploaded (20)

Anonymity in the Web based on Routing Protocols