As part of Sponsor 112, Tor has an objective to address covert channels
that malicious relays can use to deanonymize users. This proposal lays
the groundwork by categorizing these issues, and prioritizes them
according to their severity. Subsequent proposals will deal with
specific solutions.
I am posting just the intro section of this proposal here. The full
proposal is at:
https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/344-pr…
Filename: 344-protocol-info-leaks.txt
Title: Prioritizing Protocol Information Leaks in Tor
Author: Mike Perry
Created: 2023-07-17
Purpose: Normative
Status: Open
0. Introduction
Tor's protocol has numerous forms of information leaks, ranging from
highly severe covert channels, to behavioral issues that have been
useful in performing other attacks, to traffic analysis concerns.
Historically, we have had difficulty determining the severity of these
information leaks when they are considered in isolation. At a high
level, many information leaks look similar, and all seem to be forms of
traffic analysis, which is regarded as a difficult attack to perform due
to Tor's distributed trust properties.
However, some information leaks are indeed more severe than others: some
can be used to remove Tor's distributed trust properties by providing a
covert channel and using it to ensure that only colluding and
communicating relays are present in a path, thus deanonymizing users.
Some do not provide this capability, but can be combined with other info
leak vectors to quickly yield Guard Discovery, and some only become
dangerous once Guard Discovery or other anonymity set reduction is
already achieved.
By prioritizing information leak vectors by their co-factors, impact,
and resulting consequences, we can see that these attack vectors are not
all equivalent. Each vector of information leak also has a common
solution, and some categories even share the same solution as other
categories.
This framework is essential for understanding the context in which we
will be addressing information leaks, so that decisions and fixes can be
understood properly. This framework is also essential for recognizing
when new protocol changes might introduce information leaks or not, for
gauging the severity of such information leaks, and for knowing what to
do about them.
Hence, we are including it in tor-spec, as a living, normative document
to be updated with experience, and as external research progresses.
It is essential reading material for any developers working on new Tor
implementations, be they Arti, Arti-relay, or a third party implementation.
This document is likely also useful to developers of Tor-like anonymity
systems, of which there are now several, such as I2P, MASQUE, and Oxen.
They definitely share at least some, and possibly even many of these issues.
Readers who are relatively new to anonymity literature may wish to first
consult the Glossary in Section 3, especially if terms such as Covert
Channel, Path Bias, Guard Discovery, and False Positive/False Negative
are unfamiliar or hazy. There is also a catalog of historical real-world
attacks that are known to have been performed against Tor in Section 2,
to help illustrate how information leaks have been used adversarially,
in practice.
We are interested in hearing from journalists and legal organizations
who learn about court proceedings involving Tor. We became aware of
three instances of real-world attacks covered in Section 2 in this way.
Parallel construction (hiding the true source of evidence by inventing
an alternate story for the court -- also known as lying) is a
possibility in the US and elsewhere, but (so far) we are not aware of
any direct evidence of this occurring with respect to Tor cases. Still,
keep your eyes peeled...
0.1. Table of Contents
1. Info Leak Vectors
1.1. Highly Severe Covert Channel Vectors
1.1.1. Cryptographic Tagging
1.1.2. End-to-end cell header manipulation
1.1.3. Dropped cells
1.2. Info Leaks that enable other attacks
1.2.1. Handshakes with unique traffic patterns
1.2.2. Adversary-Induced Circuit Creation
1.2.3. Relay Bandwidth Lying
1.2.4. Metrics Leakage
1.2.5. Protocol Oracles
1.3. Info Leaks of Research Concern
1.3.1. Netflow Activity
1.3.2. Active Traffic Manipulation Covert Channels
1.3.3. Passive Application-Layer Traffic Patterns
1.3.4. Protocol or Application Linkability
1.3.5. Latency Measurement
2. Attack Examples
2.1. CMU Tagging Attack
2.2. Guard Discovery Attacks with Netflow Deanonymization
2.3. Netflow Anonymity Set Reduction
2.4. Application Layer Confirmation
3. Glossary
The remainder of this proposal can be read at:
https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/344-pr…
--
Mike Perry
