[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec/master] add 302-padding-machines-for-onion-clients.txt
commit 9503a261020ad906bb07595d8fba25b4542bba8a
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date: Thu May 16 09:45:15 2019 -0400
add 302-padding-machines-for-onion-clients.txt
---
proposals/000-index.txt | 2 +
.../302-padding-machines-for-onion-clients.txt | 299 +++++++++++++++++++++
2 files changed, 301 insertions(+)
diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index a504c27..5982230 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -222,6 +222,7 @@ Proposals by number:
299 Preferring IPv4 or IPv6 based on IP Version Failure Count [OPEN]
300 Walking Onions: Scaling and Saving Bandwidth [DRAFT]
301 Don't include package fingerprints in consensus documents [ACCEPTED]
+302 Hiding onion service clients using padding [ACCEPTED]
Proposals by status:
@@ -262,6 +263,7 @@ Proposals by status:
288 Privacy-Preserving Statistics with Privcount in Tor (Shamir version)
292 Mesh-based vanguards
301 Don't include package fingerprints in consensus documents
+ 302 Hiding onion service clients using padding
META:
000 Index of Tor Proposals
001 The Tor Proposal Process
diff --git a/proposals/302-padding-machines-for-onion-clients.txt b/proposals/302-padding-machines-for-onion-clients.txt
new file mode 100644
index 0000000..d7f583e
--- /dev/null
+++ b/proposals/302-padding-machines-for-onion-clients.txt
@@ -0,0 +1,299 @@
+Filename: 302-padding-machines-for-onion-clients.txt
+Title: Hiding onion service clients using padding
+Author: George Kadianakis, Mike Perry
+Created: Thursday 16 May 2019
+Status: Accepted
+Ticket: #28634
+
+0. Overview
+
+ Tor clients use "circuits" to do anonymous communications. There are various
+ types of circuits. Some of them are for navigating the normal Internet,
+ others are for fetching Tor directory information, others are for connecting
+ to onion services, while others are simply for measurements and testing.
+
+ It's currently possible for MITM type of adversaries (like tor-network-level
+ and local-area-network adversaries) to distinguish Tor circuit types from
+ each other using a wide array of metadata and distinguishers.
+
+ In this proposal, we study various techniques that can be used to
+ distinguish client-side onion service circuits and provide WTF-PAD circuit
+ padding machines (using prop#254) to hide them against certain adversaries.
+
+1. Motivation
+
+ We are writing this proposal for various reasons:
+
+ 1) We believe that in an ideal setting MITM adversaries should not be able
+ to distinguish circuit types by inspecting traffic. Tor traffic should
+ look amorphous to an outside observer to maximize uncertainty and
+ anonymity properties.
+
+ Client-side onion service circuits are an easy target for this proposal,
+ because we believe we can improve their privacy with low bandwidth
+ overhead.
+
+ 2) We want to start experimenting with the WTF-PAD subsystem of Tor, and
+ this use-case provides us with a good testbed.
+
+ 3) We hope that by actually starting to use the WTF-PAD subsystem of Tor, we
+ will encourage more researchers to start experimenting with it.
+
+2. Scope of the proposal [SCOPE]
+
+ Given the above, this proposal sets forth to use the WTF-PAD system to hide
+ client-side onion service circuits against the classifiers of paper by Kwon
+ et al. above.
+
+ By client-side onion service circuits we refer to these two types of circuits:
+ - Client-side introduction circuits: Circuit from client to the introduction point
+ - Client-side rendezvous circuits: Circuit from client to the rendezvous point
+
+ Service-side onion service circuits are not in scope for this proposal, and
+ this is because hiding those would require more bandwidth and also more
+ advanced WTF-PAD features.
+
+ Furthermore, this proposal only aims to cloak the naive distinguishing
+ features mentioned in the [KNOWN_DISTINGUISHERS] section, and can by no
+ means guarantee that client-side onion service circuits are totally
+ indistinguishable by other means.
+
+ The machines specified in this proposal are meant to be lightweight and
+ created for a specific purpose. This means that they can be easily extended
+ with additional states to do more advanced hiding.
+
+3. Known distinguishers against onion service circuits [KNOWN_DISTINGUISHERS]
+
+ Over the past years it's been assumed that motivated adversaries can
+ distinguish onion-service traffic from normal Tor traffic given their
+ special characteristics.
+
+ As far as we know, there has been relatively little research-level work done
+ to this direction. The main article published in this area is the USENIX
+ paper "Circuit Fingerprinting Attacks: Passive Deanonymization of Tor Hidden
+ Services" by Kwon et al. [0]
+
+ The above paper deals with onion service circuits in sections 3.2 and 5.1.
+ It uses the following three "naive" circuit features to distinguish circuits:
+ 1) Circuit construction sequence
+ 2) Number of incoming and outgoing cells
+ 3) Duration of Activity ("DoA")
+
+ All onion service circuits have particularly loud signatures to the above
+ characteristics, but WTF-PAD (prop#254) gives us tools to effectively
+ silence those signatures to the point where the paper's classifiers won't
+ work.
+
+4. Hiding circuit features using WTF-PAD
+
+ According to section [KNOWN_DISTINGUISHERS] there are three circuit features
+ we are attempting to hide. Here is how we plan to do this using the WTF-PAD
+ system:
+
+ 1) Circuit construction sequence
+
+ The USENIX paper uses the directions of the first 10 cells sent in a
+ circuit to fingerprint them. Client-side onion service circuits have
+ unique circuit construction sequences and hence they can be fingeprinted
+ using just the first 10 cells.
+
+ We use WTF-PAD to destroy this feature of onion service circuits by
+ carefully sending padding cells (relay DROP cells) during circuit
+ construction and making them look exactly like most general tor circuits
+ up till the end of the circuit construction sequence.
+
+ 2) Number of incoming and outgoing cells
+
+ The USENIX paper uses the amount of incoming and outgoing cells to
+ distinguish circuit types. For example, client-side introduction circuits
+ have the same amount of incoming and outgoing cells, whereas client-side
+ rendezvous circuits have more incoming than outgoing cells.
+
+ We use WTF-PAD to destroy this feature by changing the number of cells
+ sent in introduction circuits. We leave rendezvous circuits as is, since
+ the actual rendezvous traffic flow usually resembles well normal Tor
+ circuits.
+
+ 3) Duration of Activity ("DoA")
+
+ The USENIX paper uses the period of time during which circuits send and
+ receive cells to distinguish circuit types. For example, client-side
+ introduction circuits are really short lived, wheras service-side
+ introduction circuits are very long lived. OTOH, rendezvous circuits have
+ the same median lifetime as general Tor circuits which is 10 minutes.
+
+ We use WTF-PAD to destroy this feature of client-side introduction
+ circuits by setting a special WTF-PAD option, which keeps the circuits
+ open for 10 minutes completely mimicking the DoA of general Tor circuits.
+
+4.1. A dive into general circuit construction sequences [CIRCCONSTRUCTION]
+
+ In this section we give an overview of how circuit construction looks like
+ to a network or guard-level adversary. We use this knowledge to make the
+ right padding machines that can make intro and rend circuits look like these
+ general circuits.
+
+ In particular, most general Tor circuits used to surf the web or download
+ directory information, start with the following 6-cell relay cell sequence (cells
+ surrounded in [brackets] are outgoing, the others are incoming):
+
+ [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [BEGIN] -> CONNECTED
+
+ When this is done, the client has established a 3-hop circuit and also
+ opened a stream to the other end. Usually after this comes a series of DATA
+ cell that either fetches pages, establishes an SSL connection or fetches
+ directory information:
+
+ [DATA] -> [DATA] -> DATA -> DATA
+
+ The above stream of 10 relay cells defines the grand majority of general
+ circuits that come out of Tor browser during our testing, and it's what we
+ are gonna use to make introduction and rednezvous circuits blend in.
+
+ Please note that in this section we only investigate relay cells and not
+ connection-level cells like CREATE/CREATED or AUTHENTICATE/etc. that are
+ used during the link-layer handshake. The rationale is that connection-level
+ cells depend on the type of guard used and are not an effective fingerprint
+ for a network/guard-level adversary.
+
+5. WTF-PAD machines
+
+ For the purposes of this proposal we will make use of four WTF-PAD machines
+ as follows:
+
+ - Client-side introduction circuit hiding machine (origin-side)
+ - Client-side introduction circuit hiding machine (relay-side)
+
+ - Client-side rendezvous circuit hiding machine (origin-side)
+ - Client-side rendezvous circuit hiding machine (relay-side)
+
+ In the following sections we will analyze these machines.
+
+5.1. Client-side introduction circuit hiding machines [INTRO_CIRC_HIDING]
+
+ These two machines are meant to hide client-side introduction circuits. The
+ origin-side machine sits on the client and sends padding towards the
+ introduction circuit, whereas the relay-side machine sits on the middle-hop
+ (second hop of the circuit) and sends padding towards the client. The
+ padding from the origin-side machine terminates at the middle-hop and does
+ not get forwarded to the actual introduction point.
+
+ Both of these machines only get activated for introduction circuits, and
+ only after an INTRODUCE1 cell has been sent out.
+
+ This means that before the machine gets activated our cell flow looks like this:
+
+ [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [INTRODUCE1]
+
+ Comparing the above with section [CIRCCONSTRUCTION], we see that the above
+ cell sequence matches the one from general circuits up to the first 7 cells.
+
+ However, in normal introduction circuits this is followed by an
+ INTRODUCE_ACK and then the circuit gets teared down, which does not match
+ the sequence from [CIRCCONSTRUCTION].
+
+ Hence when our machine is used, after sending an [INTRODUCE1] cell, we also
+ send a [PADDING_NEGOTIATE] cell, which gets answered by a PADDING_NEGOTIATED
+ cell and an INTRODUCE_ACKED cell. This makes us match the [CIRCCONSTRUCTION]
+ sequence up to the first 10 cells.
+
+ After that, we continue sending padding from the relay-side machine so as to
+ fake a directory download, or an SSL connection setup. We also want to
+ continue sending padding so that the connection stays up longer to destroy
+ the "Duration of Activity" fingerprint.
+
+ To calculate the padding overhead, we see that the origin-side machine just
+ sends a single [PADDING_NEGOATIATE] cell, wheras the origin-side machine
+ sends a PADDING_NEGOTIATED cell and between 7 to 10 DROP cells. This means
+ that the average overhead of this machine is 11 padding cells.
+
+ In terms of WTF-PAD terminology, these machines have three states (START,
+ OBF, END). They move from the START to OBF state when the first
+ non-padding cell is received on the circuit, and they stay in the OBF
+ state until all the padding gets depleted. The OBF state is controlled by
+ a histogram which specifies the parameters described in the paragraphs
+ above. After all the padding finishes, it moves to END state.
+
+ We also set a special WTF-PAD flag which keeps the circuit open even after
+ the introduction is performed. In particular, with this feature the circuit
+ will stay alive for the same durations as normal web circuits before they
+ expire (usually 10 minutes).
+
+5.2. Client-side rendezvous circuit hiding machines
+
+ The rendezvous circuit machines apply on client-side rendezvous circuits and
+ only after the rendezvous point has been established (REND_ESTABLISHED has
+ been received). Up to that point, the following cell sequence has been
+ observed on the circuit:
+
+ [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [ESTABLISH_REND] -> REND_ESTABLISHED
+
+ which matches the general circuit construction sequence [CIRCCONSTRUCTION]
+ up to the first 6 cells. However after that, normal rendezvous circuits
+ receive a RENDEZVOUS2 cell followed by a [BEGIN] and a CONNECTED, which does
+ not fit the circuit construction sequence we are trying to imitate.
+
+ Hence our machine gets activated right after REND_ESTABLISHED is received,
+ and continues by sending a [PADDING_NEGOTIATE] and a [DROP] cell, before
+ receiving a PADDING_NEGOTIATED and a DROP cell, effectively blending into
+ the general circuit construction sequence on the first 10 cells.
+
+ After that our machine gets deactivated, and we let the actual rendezvous
+ circuit shape the traffic flow. Since rendezvous circuits usually immitate
+ general circuits (their purpose is to surf the web), we can expect that they
+ will look alike.
+
+ In terms of overhead, this machine is quite light. Both sides send 2 padding
+ cells, for a total of 4 padding cells.
+
+6. Overhead analysis
+
+ Given the parameters above, intro circuit machines have an overhead of 11
+ padding cells, and rendezvous circuit machines have an overhead of 4
+ cpadding ells. . This means that for every intro and rendezvous circuit
+ there will be an overhead of 15 padding cells in average, which is about
+ 7.5kb.
+
+ In the PrivCount paper [1] we learn that the Tor network sees about 12
+ million successful descriptor fetches per day. We can use this figure to
+ assume that the Tor network also sees about 12 million intro and rendezvous
+ circuits per day. Given the 7.5kb overhead of each of these circuits, we get
+ that our padding machines infer an additional 94GB overhead per day on the
+ network, which is about 3.9GB per hour.
+
+ XXX Isn't this kinda intense????? Using the graphs from metrics we see that
+ the Tor network has total capacity of 300 Gbit/s which is about 135000GB per
+ hour, so 3.9GB per hour is not that much, but still...
+
+7. Discussion
+
+7.1. Alternative approaches
+
+ These machines try to hide onion service client-side circuits by obfuscating
+ their looks. This is a reasonable approach, but if the resulting circuits
+ look unlike any other Tor circuits, they would still be fingerprintable just
+ by that fact.
+
+ Another approach we could take is make normal client circuits look like
+ onion service circuits, or just make normal clients establish fake onion
+ service circuits periodically. The hope here is that the adversary won't be
+ able to distinguish fake onion service circuits from real ones. This
+ approach has not been taken yet, mainly because it requires additional
+ WTF-PAD features and poses greater overhead risks.
+
+7.2. Future work
+
+ As discussed in [SCOPE], this proposal only aims to hide some very specific
+ features of client-side onion service circuits. There is lots of work to be
+ done here to see what other features can be used to distinguish such
+ circuits, and also what other classifiers can be built using deep learning
+ and whatnot.
+
+---
+
+ [0]: https://www.usenix.org/node/190967
+ https://blog.torproject.org/technical-summary-usenix-fingerprinting-paper
+
+ [1]: "Understanding Tor Usage with Privacy-Preserving Measurement"
+ by Akshaya Mani, T Wilson-Brown, Rob Jansen, Aaron Johnson, and Micah Sherr
+ In Proceedings of the Internet Measurement Conference 2018 (IMC 2018).
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits