[tor-dev] Prop#344: Prioritizing Protocol Information Leaks in Tor

[Mike Perry]

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-protocol-info-leaks.txt



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-protocol-info-leaks.txt


-- 
Mike Perry