Prop344: Update and Categorize Vectors; Ground in Threat Model
I've re-grounded the entire proposal in Tor's OG Design Doc Threat Model language, and provide a background of this threat model as part of the introduction, to help new folks get up to speed and better conceptualize this proposal.
The proposal has been updated to classify all vectors into the following three categories:
- Internal Covert Channels
- Behavior Manipulation
- Augmented Observation
It now also proposes that Tor's threat model be expanded to explicitly cover these categories. These categories (and their vectors) were either explicitly excluded, or in an ambigous status before.
Additionally, the following vectors have been added:
- Guard Trapper Attacks
- Relay DoS/OOM
The following examples have been added to existing vectors
- Path restriction problems
- .exit notation
- Exit Policy abuse by websites+exits
- circuit dirtyness abuse by exits
- Dropped cells types unique to onion services
Merge request reports
Activity
requested review from @ahf
assigned to @mikeperry
mentioned in issue #318
mentioned in issue #277 (closed)
@ahf also, for couch-review, here's a handy link to inside the CI build: https://tpo.pages.torproject.net/-/core/torspec/-/jobs/914777/artifacts/public/proposals/344-protocol-info-leaks.html
89 37 - 2.4. [Application Layer Confirmation](#24-application-layer-confirmation) 90 38 3. [Glossary](#3-glossary) 51 52 Readers who are relatively new to anonymity literature may wish to first 53 consult the Glossary in [Section 3](#3-glossary), especially if terms such as 54 Covert Channel, Path Bias, Guard Discovery, and False Positive/False Negative 55 are unfamiliar or hazy. There is also a catalog of historical real-world 56 attacks that are known to have been performed against Tor in [Section 57 2](#2-attack-examples), to help illustrate how information leaks have been 58 used adversarially, in practice. 59 60 We are interested in hearing from journalists and legal organizations who 61 learn about court proceedings involving Tor. We became aware of three 62 instances of real-world attacks covered in [Section 2](#2-attack-examples) in 63 this way. Parallel construction (hiding the true source of evidence by 64 inventing an alternate story for the court -- also known as lying) is a 65 possibility in the US and elsewhere, but we are not aware of any direct 66 evidence of this occurring with respect to Tor cases. Keep your eyes peeled... -
How should they contact us? Maybe add a link here to https://www.torproject.org/contact/ ?
changed this line in version 2 of the diff
58 used adversarially, in practice. 59 60 We are interested in hearing from journalists and legal organizations who 61 learn about court proceedings involving Tor. We became aware of three 62 instances of real-world attacks covered in [Section 2](#2-attack-examples) in 63 this way. Parallel construction (hiding the true source of evidence by 64 inventing an alternate story for the court -- also known as lying) is a 65 possibility in the US and elsewhere, but we are not aware of any direct 66 evidence of this occurring with respect to Tor cases. Keep your eyes peeled... 67 68 ## 0.1. Background: Gaps in Tor's Original Threat Model 69 70 Tor's [original threat 71 model](https://svn-archive.torproject.org/svn/projects/design-paper/tor-design.html#subsec:threat-model) 72 focused on local adversaries who can observe limited portions of the Tor 73 network, excluding global adversaries with full network visibility. 127 categories. 128 129 However, as we shall see, the three above areas also correspond to a severity 130 ordering: Covert Channels directly inside the Tor Protocol yield more 131 comprehensive deanonymization capability than Behavior Manipulation, and 132 Behavior Manipulation typically is used to assist Augmented Observation to 133 become sufficiently accurate for deanonymization. 134 135 To support this ordering, we will examine the kinds of attacks each 136 information leak vector in each category enables, in terms of their 137 deanonymization capability. This examination will also drive the severity 138 ordering of each vector within its category. The most severe vectors are 139 listed first, in both cases. 140 141 Each vector of information leak also has a common solution, and some vectors 142 share the same solution as other vectors. -
While this text was not directly LLM generated, I did have several conversations with an LLM about it, brainstorming various categorizations, before I arrived at these categories myself.
However, it is very possible I have been infected by its hallucinations, and my very notion of reality has thus become irreparably distorted.
This may also prevent some members of network team from being able to review this section. Let's worry.
140 141 Each vector of information leak also has a common solution, and some vectors 142 share the same solution as other vectors. 143 144 # 1. Closing the Gaps 145 146 In this section, we prioritize and categorize the info leak vectors that exist 147 in the three new areas of Tor's threat model, in order of highest priority 148 first. 149 150 Corresponding to the expanded threat model's new categories, these categories 151 are: "Highly Severe Covert Channels", "Zero-Click Behavior Manipulation 152 Primitives", and "Augmented Observation Primitives". 153 154 The first category allows malicious relays to communicate their presence in a 155 circuit prior to any application traffic, which yields dragnet deanonymization changed this line in version 2 of the diff
199 to compromised Guards (or Bridges). These Guards can in turn use this 200 section's covert channels to ensure that all of these circuits are directed 201 only to compromised Exits. This removes both `c/n` factors, fully 202 deanonymizing all users who are subject to this censorship firewall. In these 203 specific circumstances, Tor is actually less secure than a 1-hop VPN. 204 205 > This style of censorship-based deanonymization attack was first academically 206 > published in [\[TRAPPING_TOR\]][refs], and it also includes a covert 207 > channel. However, their covert channel (stream correlation) does not satisfy 208 > the first requirement of this section, because it relies on streams already 209 > sending data. In practice, this means that targeted users would notice their 210 > connections were repeatedly being terminated mid-download, and would have 211 > great difficulty actually using Tor to download anything. The covert 212 > channels in this section, by contrast, enable closing circuits *before* 213 > application traffic begins, thus making them invisible to targeted users, 214 > other than as a higher circuit failure rate. changed this line in version 2 of the diff
339 covert channel attacks. In this case, these 3-5 bits would just be a collusion 340 signal to the exit to keep the circuit (or to close it when the signal is 341 absent). This will reduce the amount of non-compromised traffic that malicious 342 exit must carry (see the following [Section 1.1.3](#113-dropped-cells)). If 343 the adversary is an ISP with censorship capability, this combined vector can 344 be used to deanonymize all Tor traffic at that ISP, using 345 [\[TRAPPER_TOR\]][refs] Guard filtering. 346 347 While more cumbersome than cryptographic tagging attacks from [Section 348 1.1.1](#111-cryptographic-tagging), in practice this attack is just as 349 successful, if these cell command types are not restricted and limited. It is 350 somewhat surprising that the [FBI used this attack](#21-cmu-tagging-attack) 351 before cryptographic tagging, but perhaps that was just a lucky coincidence of 257 352 opportunity. 258 353 354 The CGO proposal (an updated form of Prop#308) will eliminate the ability of -
Not merged yet but I will just use https://spec.torproject.org/proposals/359 for now.
changed this line in version 2 of the diff
298 client->guard connection. 299 300 The severity of this covert channel is extreme (zero false positives; zero 301 false negatives) when they are injected in cases where the circuit is 390 - Invalid relay commands 391 - Unsupported (or consensus-disabled) relay commands or extensions 392 - Out-of-context relay commands 393 - Duplicate relay commands 394 - Relay commands that hit any error codepaths 395 - Relay commands for an invalid or already-closed stream ID 396 - Semantically void relay cells (incl relay data len == 0, or PING) 397 - Onion descriptor-appended junk 398 399 Additionally, clients can send arbitrary relay commands to onion services, which includes the above set, plus: 400 - RELAY_BEGIN to invalid addrs/ports 401 - RELAY_BEGIN to reused stream-ids changed this line in version 2 of the diff
470 Instead, they enable the adversary to control or manipulate client behavior, 471 and combine it with relative uniqueness of Tor Protocol handshake traffic 472 patterns, to build potent attacks, without any user-initiated application 473 activity. In some cases, this still results in full deanonymization. 474 475 Importantly, these information leaks and their resulting attacks still are 476 entirely the fault of the Tor Protocol and Tor implementation behavior, and 477 are not inherent to low-latency mix networks in general. 478 479 ### 1.2.1. Guard Trapping Attacks 480 481 **At a glance:** 482 483 | **Characteristic** | **Information** | 484 |----|-----| 485 | **Accuracy**: | FP=0, FN=0 | changed this line in version 2 of the diff
727 vectors, or engage in censorship. 728 729 An adversary can confirm that a Guard is used by an onion service by 730 maintaining a connection to it while taking it offline, to watch the 731 connection close. Such an adversary may be more interested in the resulting 732 Guard discovery surveillance opportunities, rather than removing the Guard 733 flag itself. 487 734 488 735 **Mitigation Plan**: 489 736 490 737 | **Action** | **Details** | 491 738 |----|----| 492 | **Solution**: | Mesh-vanguards (Prop#292); Vanguards-lite (Prop#333); rate limiting circuit creation attempts; rate limiting the total number of distinct paths used by circuits | 493 | **Status**: | Vanguards-lite deployed in Tor 0.4.7; Mesh-vanguards is vanguards addon; Conflux leg failures are limited per-exit; Exitpolicy scanner exists | 494 | **Funding**: | Not explicitly funded | 739 | **Solution**: | C-Tor has an oom killer to free memory under pressure; Circuits with excessive queues are force-closed at relays | changed this line in version 2 of the diff
-
All in all, very good work here
It's easy to read, but I tried to read it a bit with a newcomer in mind, so I have some minor edit requests for spelling out certain things in the text, and some minor styling things. The styling things are optional though and you can decide to fix that yourself or not.
One thing I noticed that I am not sure is a normal thing to do in english text, but in lists/emumerations, there is often not a punctuation at the end of each item. I do not personally care for that, but it was just something I thought of when going over it in the Markdown file. I didn't notice it during the pass over the rendered HTML version.
If you want some feedback on the English text, then I have used Micah in the past, but I don't think that is needed here.
-
I fixed most of the nits. The list thing feels weird.. Most of those lists aren't complete sentences, but are sentence fragments. My mind doesn't like periods after sentence fragments, but I am not a style wonk.
I expect the language lawyers to bust out Elements of Style on my ass before this moves up to spec level. And I will probably just have an LLM fix these things, at that point, in that case.
added 1 commit
- e65e55bc - Prop344: Readability fixes from Alex's review