tor-dev November 2018

tor-dev@lists.torproject.org

22 participants
19 discussions

the consequences of deprecating debian alpha repos with every new major branch
by nusenu 21 Dec '21

21 Dec '21

Hi, tldr: - more outdated relays (that is a claim I'm making and you could easily proof me wrong by recreating the 0.3.3.x alpha repos and ship 0.3.3.7 in them and see how things evolve after a week or so) - more work for the tpo website maintainer - less happy relay operators [3][4] - more work for repo maintainers? (since a new repo needs to be created) When the tor 0.3.4 alpha repos (deb.torproject.org) first appeared on 2018-05-23 I was about to submit a PR for the website to include it in the sources.list generator [1] on tpo but didn't do it because I wanted to wait for a previous PR to be merged first. The outstanding PR got merged eventually (2018-06-28) but I still did not submit a PR to update the repo generator for 0.3.4.x nonetheless and here is why. Recently I was wondering why are there so many relays running tor version 0.3.3.5-rc? (see OrNetStats or Relay Search) (> 3.2% CW fraction) Then I realized that this was the last version the tor-experimental-0.3.3.x-* repos were shipping before they got abandoned due to the new 0.3.4.x-* repos (I can no longer verify it since they got removed by now). Peter made it clear in the past that the current way to have per-major-version debian alpha repos (i.e. tor-experimental-0.3.4.x-jessie) will not change [2]: > If you can't be bothered to change your sources.list once or twice a > year, then you probably should be running stable. but maybe someone else would be willing to invoke a "ln" commands everytime a new new alpha repo is born. tor-alpha-jessie -> tor-experimental-0.3.4.x-jessie once 0.3.5.x repos are created the link would point to tor-alpha-jessie -> tor-experimental-0.3.5.x-jessie It is my opinion that this will help reduce the amount of relays running outdated versions of tor. It will certainly avoid having to update the tpo website, which isn't a big task and could probably be automated but it isn't done currently. "..but that would cause relay operators to jump from i.e. 0.3.3.x to 0.3.4.x alphas (and break setups)!" Yes, and I think that is better than relays stuck on an older version because the former repo no longer exists and operators still can choose the old repos which will not jump to newer major versions. [1] https://www.torproject.org/docs/debian.html.en#ubuntu [2] https://trac.torproject.org/projects/tor/ticket/14997#comment:3 [3] https://lists.torproject.org/pipermail/tor-relays/2018-June/015549.html [4] https://trac.torproject.org/projects/tor/ticket/26474 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

4 7

DNS-over-HTTPS (DOH) in Firefox/Torbrowser
by nusenu 01 Jul '20

01 Jul '20

Hi, since Mozilla did tests [0] on DOH [1] in Firefox I was wondering if Torbrowser developers have put any thought into that as well? Note: I'm _not_ suggesting to use DOH in torbrowser I'm just asking because the answer probably matters for exit documentation in the relay guide if clients do DNS themselves over TCP connections instead of relying on the exit (even if torbrowser is not the only tor client). thanks, nusenu [0] https://www.ghacks.net/2018/03/20/firefox-dns-over-https-and-a-worrying-shi… [1] https://datatracker.ietf.org/doc/draft-hoffman-dns-over-https/ -- https://mastodon.social/@nusenu twitter: @nusenu_

4 4

Lets give every circuit its own exit IP?
by nusenu 18 Mar '20

18 Mar '20

The unbearable situation with Google's reCAPTCHA motivated this email (but it is not limited to this specific case). This idea came up when seeing a similar functionality in unbound (which has it for a different reason). Assumption: There are systems that block some tor exit IP addresses (most likely the bigger once), but they are not blocked due to the fact that they are tor exits. It just occurred that the IP got flagged because of "automated / malicious" requests and IP reputation systems. What if every circuit had its "own" IP address at the exit relay to avoid causing collateral damage to all users of the exit if one was bad? (until the exit runs out of IPs and starts to recycle previously used IPs again) The goal is to avoid accumulating a bad "reputation" for the single used exit IP address that affects all tor users of that exit. Instead of doing it on the circuit level you could do it based on time. Change the exit IP every 5 minutes (but do _not_ change the exit IPs for _existing_ circuits even if they live longer than 5 minutes). Yes, no one has that many IPv4 addresses but with the increasing availability of IPv6 at exits and destinations, this could be feasible to a certain extend, depending on how many IPv6 addresses the exit operator has. There are exit operators that have entire /48 IPv6 blocks. problems: - will not solve anything since reputation will shift to netblocks as well (How big of a netblock are you willing to block?) - you can tell two tor users easily apart from each other even if they use the same exit (or more generally: you can tell circuits apart). There might be all kinds of bad implications that I'm not thinking off right now. - check.tpo would no longer be feasible - how can do we still provide the list of exit IPs for easy blocking? Exits could signal their used netblock via their descriptor. What if they don't? (that in turn opens new kinds of attacks where an exit claims to be /0 and the target effectively blocks everything) - more state to track and store at the exit -... some random thoughts, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

4 6

#3600 tech doc
by Richard Pospesel 13 Mar '19

13 Mar '19

Hey y'all, For the past little while I've been working on a technical overview doc for #3600 (Prevent redirects from transmitting+storing cookies+identifiers) detailing the problems, scenarios and possible solutions. Please take a look and feel free to comment, edit or add! Link: https://storm.torproject.org/grain/X4nhdNqR9fGRc7sgTefFkg/ best, -Richard

3 7

Network team meeting on Tuesday at 2300 UTC
by teor 10 Dec '18

10 Dec '18

Hi everyone, This week's network team meeting is on Tuesday at 2300 UTC. (If this time doesn't work for you, we'll see you the week after.) Our meetings are held on #tor-meeting on OFTC. We'll be back to our regular schedule next week, but we'll meet an hour earlier due to daylight saving time. First meeting each month: Tuesday at 2300 UTC. Other meetings each month: Mondays at 1700 UTC. T -- teor ----------------------------------------------------------------------

1 3

Dealing with frequent suspends on Android
by Michael Rogers 04 Dec '18

04 Dec '18

Hi all, It's great to see that some children of #25500 have already been released in the 0.3.4 series. Can I ask about the longer-term plan for this work, and whether #23289 (or something similar) is part of it? The context for my question is that we're trying to reduce Briar's power consumption. Until now we've held a wake lock to keep the CPU awake all the time, but normally an Android device would go into "deep sleep" (which corresponds to suspend on other platforms) whenever the screen's turned off, apart from brief wakeups for alarms and incoming network traffic. Holding a permanent wake lock has a big impact on battery life. Most of our background work can be handled with alarms, but we still need to hold a wake lock whenever Tor's running because libevent timers don't fire when the CPU's asleep, and Tor gets a nasty surprise when it wakes up and all its timers are late. It looks like most of the work has been moved off the one-second periodic timer, which is great, but I assume that work's now being scheduled by other means and still needs to be done punctually, which we can't currently guarantee on Android without a wake lock. As far as I can tell, getting rid of the wake lock requires one of the following: 1. Tor becomes extremely tolerant of unannounced CPU sleeps. I don't know enough about Tor's software architecture to know how feasible this is, but my starting assumption would be that adapting a network-oriented codebase that's been written for a world where time passes at a steady rate and timers fire punctually, to a world where time passes in fits and starts and timers fire eventually, would be a nightmare. 2. Tor tolerates unannounced CPU sleeps within some limits. This is similar to the previous scenario, except the controller sets a regular alarm to ensure the CPU never sleeps for too long, and libevent ensures that when the CPU wakes up, any overdue timers fire immediately (maybe this happens already?). Again, I'd assume that adapting Tor to this environment would be a huge task, but at least there'd be limits on the insanity. One of the difficulties with this option is that under some conditions, the controller can only schedule one alarm every 15 minutes. Traffic from the guard would also wake the CPU, so if we could ask the guard for regular keepalives, we might be able to promise that the CPU will wake once every keepalive interval, unless the guard connection's lost, in which case it will wake once every 15 minutes. But keepalives from the guard would require a protocol change, which would take time to roll out, and would let the guard know (if it doesn't already) that the client's running on Android. 3. Tor knows when it next needs to wake up, and relies on the controller to wake it. This requires a way for the controller to query Tor, and Tor to query libevent, for the next timer that needs to fire (perhaps from some subset of timers that must fire punctually even if the CPU's asleep). Libevent doesn't need to detect overdue timers by itself, but it needs to provide a hook for re-checking whether timers are overdue. The delay until the next timer needs to be at least a few seconds long, at least some of the time, for sleeping to be worthwhile. And finally, even if all those conditions are met, we run up against the 15-minute limit on alarms again. None of these options are good. I'm not even sure if the first and third are feasible. But I don't know enough about Tor or libevent to be sure. If you do, I'd be really grateful for your help in understanding the constraints here. Cheers, Michael

6 13

Merging Tor Bug #27490
by Neel Chauhan 29 Nov '18

29 Nov '18

Hi, I noticed that while you all have accepted bug #27490 (When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at random), it has not been merged. Is there anything I can do to speed up the process since I also have code ready for #27491 and #27492 but am awaiting the merger of #27490 before I submit them? I am also currently working on Bug #27647. Thank You, Neel Chauhan

2 1

New sbws milestones on trac
by teor 28 Nov '18

28 Nov '18

Hi all, I just made some changes to the simple bandwidth scanner (sbws) milestones on trac. sbws 1.0.0 was released a while ago, the latest release is sbws 1.0.2. We had two sbws 1.0 milestones: sbws 1.0 (MVP must) and sbws 1.0 (MVP nice). Putting priorities in milestone names is confusing, and it makes it hard to do queries in trac. Here's what I did with the remaining 1.0 tickets: (Using the same naming system as Core Tor/Tor.) sbws: 1.0.x-final Bugfixes that we need before we deploy sbws to another directory authority. Due date: December before Tor's Christmas shutdown https://trac.torproject.org/projects/tor/report/70 sbws: 1.1.x-final Features that we need to diagnose slow and missing relays. (sbws uses semantic versioning, so features require a minor version bump.) Due date: February after the network team hackfest sbws: 1.2.x-final Future changes that we might make to the bandwidth measurement system. No Due Date We can change the due dates depending on how much progress we make. T -- teor ----------------------------------------------------------------------

1 0

Whitepaper draft: Towards Side Channel Analysis of Datagram Tor vs Current Tor
by Nick Mathewson 27 Nov '18

27 Nov '18

# Towards Side Channel Analysis of Datagram Tor vs Current Tor Version 0.6, 27 Nov 2018 by Nick Mathewson and Mike Perry ## Disclaimers This whitepaper assumes that you know how Tor works. There are probably some very good references here that we didn't remember to cite. ## Introduction Tor's current design requires that its data cells be transmitted from one end of a circuit to the other using a reliable, in-order delivery mechanism. To meet this requirement, Tor relays need to buffer cells--spending resources, hurting performance, and risking susceptibility to out-of-memory attacks. In order to improve Tor's performance and resilience, researchers have made several proposals for ways to relax the requirement for reliable in-order delivery. In general, these "datagram-based" proposals would allow relays to drop or reorder cells as needed, and move the responsibility for providing a reliable stream protocol to the endpoints (the client and the exit relays). But by increasing flexibility for the relays, and by increasing the complexity of the endpoints, these datagram proposals also create some new attack vectors. Before we can deploy any of these designs, we need to consider whether these attacks weaken Tor's security, or whether they are irrelevant given other, stronger attacks against Onion Routing. This whitepaper tries to list these attacks, and to provide a framework for thinking about them as we move forward with our design analysis. We hope that this whitepaper will help researchers and others in the Tor community to understand these issues, so that we can work together to find new ideas to analyze and mitigate the attacks described here, and to help deploy a faster and more reliable network while still maintaining our current (or better) security guarantees. We hope that our description of the problem space will inspire, not discourage, future experiments in this area, and help with a holistic understanding of the risks, rewards, and future areas of work. ### A toy system We will be analyzing a system that differs from Tor in the following ways. * The link between a client and its guard, and between each pair of relays uses DTLS over UDP: packets can be dropped or re-ordered by an attacker on the link, but not modified, read, or forged. Each DTLS packet contains an integer number of cells. * Each circuit between a client and an exit traverse several relays, as before. The cells on a circuit are no longer guaranteed to arrive reliably, but can be dropped or re-ordered on the wire, or by a relay. * To provide reliable service end-to-end, the client and the exit each use a TCP-like protocol to track which application bytes have been sent and received. Received data is acknowledged; dropped data is retransmitted. * The cryptography to be used for circuit encryption is not specified here. * A reliable signaling mechanism between relays (to create, destroy, and maintain circuits) is not specified here. (It is likely that many readers will be able to design a system that resists the attacks below better than the design above. But please remember as you do, that a design which improves a system in one way may constrain it in others, or may offer insufficient benefits to be clearly superior to Tor as it is today. Before we can deploy, we will need not just defenses, but also a systemic way to compare the effect of these defenses, used together, to the Tor status quo.) ## Some preexisting attacks to consider To put the datagram-based attacks into context, we'll start out by listing some attacks against the current non-datagram Tor design (and proposed defenses for those, where they exist). We assume, as usual, an adversary who controls some but not all relays, and some but not all ISPs. A note on attack power: the accuracy of many of these attacks, particularly the passive ones, depends on the type of traffic being sent, the quantity of similar traffic elsewhere on the Tor network, the quantity of concurrent activity by the same client, the adversary's observation position and data retention resolution, the quantity of padding, and the tendency of the network to preserve or alter packet timing information in transit. In many cases, we don't have good metrics or evaluation methodology to determine how much harder or easier one attack is than another. ### End-to-end passive traffic correlation attacks. Here's the gold-standard base-line attack: an attacker who can watch any two points on the same circuit is assumed to be able to realize, without having observed very much traffic at all, that the two points are indeed on the same circuit by correlating the timing and volume of data sent at those two points. When one of these points is also linked to the client, and one is linked to the client's activity, this attack deanonymizes the client. Tor's current design focuses on minimizing this probability, and also shifting its characteristics, through things like network diversity and long-term entry points. The attack may also become harder (and/or slower) when there is a lot of similar concurrent traffic on the Tor network, which means that adding users who use Tor for many things is in itself a form of mitigation. Proposed defenses in this area include deliberate obfuscation of message volume through padding, and of message timing through random delays, as well as things like traffic splitting and more complex traffic scheduling for loud flows. While we have completed some work on link padding, and are progressing on a deployment for circuit padding, it is not yet clear if we can use these defenses in an affordable way against a correlation attack, and it is hard to measure their effectiveness on a realistic Tor-sized network. ### Data tagging side-channels by relays If two relays are on the same circuit, they can surreptitiously communicate with one another transforming the data in the RELAY cells, and un-transforming the data before passing it on. Since Tor's current encryption protocol is malleable, this allows them to send a large number of bits per cell. This attack can also be used when two relays do not know if they are on the same circuit. One relay modifies a cell, and the other one looks for such modifications. If the data is processed by an honest relay, it will destroy the circuit, but the client may or may not notice that the circuit has destroyed. (And the dishonest relay may delay informing the client!) To defend against this, we plan to replace our encryption with a non-malleable algorithm. See for example proposals 202, 261, and 295. ### Destructive side-channels (internal) Even if we remove the malleability in Tor's encryption, a smaller side-channel remains: A dishonest relay can destroy a circuit at any time, either by corrupting the circuit or simply sending a DESTROY cell along it. A third party can destroy a large number of circuits at once by remotely attacking a client or relay -- either disabling that relay, or making it close circuits because of the OOM handler. (See the Sniper Attack paper.) If a circuit is corrupted (as would happen if a relay attempted data tagging against one of the non-malleable cryptographic algorithms mentioned above), other points on the circuit can tell which cell is the first corrupted cell. If a circuit is destroyed at one point, other points on the circuit can tell how many cells were sent before the destruction. It is likely that based on data or traffic patterns, most parties on a circuit will be able to distinguish a prematurely destroyed circuit from one that was shut down normally. In each case, this attack can be used to send (log n) bits of information per circuit, at the cost of destroying the circuit, where n is the number of cells that might be sent over the circuit in total. Some noise will exist, since we expect some circuits to be prematurely closed on their own. We don't know how much noise. We also have various heuristics that can attempt to detect if this happens too often; however at best they likely reduce the rate that information that can be sent in this way rather than eliminate it. We also lack methodology to measure the rate of information in this case, to help determine if we can successfully reduce it further. ### Destructive network probes (external) Though TLS is resilient against many forms of active attacks, it can't resist an attacker who focuses against the underlying TCP layer. Such an attacker can, by forging TCP resets, cause all the entire TLS connection to be dropped, thereby closing all the circuits on it. This kind of attack can be observed at other points on the network in a way similar to the destructive side-channels noted above. This class of attack seems to be easier against Tor's current design than it would be against (some) datagram-based designs, since datagram-based designs are resilient to more kinds of traffic interference. ### Timing-based watermarking attacks Hostile relays can also introduce a side channels to a circuit by introducing patterned delays into the cells. For example, a relay could buffer a large number of cells, then transmit a "1" bit by sending a cell in a given time period, or a "0" by not sending cells in that time period. An attacker can also mount this attack without controlling relays: if the attacker performs a DoS attack against a relay or its traffic, it can observe changes in the traffic volume elsewhere on the network. [See https://www.freehaven.net/anonbib/cache/ccs07-latency-leak.pdf and http://cybercentre.cs.ttu.ee/wp/wp-content/uploads/2017/01/crw2017_final.pdf ] The bandwidth of this side-channel will be limited, since other relays on the network will naturally buffer and delay traffic, obscuring the pattern some. There are also limits to how long packets can be delayed before the relay is no longer usable. [See: - Rainbow: https://www.freehaven.net/anonbib/cache/ndss09-rainbow.pdf - Swirl: https://www.freehaven.net/anonbib/cache/ndss11-swirl.pdf - Backlit (detection): https://www.freehaven.net/anonbib/cache/acsac11-backlit.pdf ] Proposals for resisting this type of watermarking attack are mostly of the same type that would be needed for resisting end-to-end correlation. An adversary that can perform active attacks to introduce their own unique traffic patterns intuitively seems much stronger than one that must passively use potentially common patterns. We lack a unified framework to tell us how much stronger this adversary is than the passive one, especially against various defenses. ### Traffic injection attacks Related to the active timing attack, in some positions (like exit and RP) relays can inject cells that are ignored by the other endpoint. These injected patterns will not impact the user's experience, but will allow unique traffic patterns to be sent and detected by the adversary at crucial times. [See https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf] These injection attacks arise from former adherence to Postel's Maxim. Tor has since departed from this maxim, and instead opted for stricter forward compatibility through feature versioning, but removing instances in the codebase where injected cells can be permitted has proven challenging. ## Attacks unique to datagram designs Here are some attacks that are enabled by (or at any rate behave differently under) datagram-based designs. ### Traffic-stream tagging (by relays and internet links) Because the new system permits a number of transformations on traffic that were not previously allowed, we need to look at how those transformations can be used to attack users. As a trivial example, any router can relay an arbitrary subset of the cells that it receives on a circuit, in an arbitrary order, due to the exact properties the reliable transport aims to provide. The pattern induced in this way will be detectable by the exit relay when it attempts to reconstruct the stream. Because we explicitly allow this kind of transformation, the circuit will not be killed after a single dropped cell, but rather will continue working silently. Moreover, any ISP can mount the same attack by dropping and/or re-ordering DTLS calls. A remote attacker may also be able to mount this attack by flooding any router between a client and its guard, thereby causing some of the DTLS messages to get dropped. If we are using TCP between client and exit, the acknowledgments sent by each endpoint will provide confirmation about which data it received and which it did not. If instead of TCP, we use some other protocol where the end-points communicate even more information about which packets they did and did not receive, this can provide an even higher-bandwidth side-channel. The bandwidth of this side-channel is fairly high, since it allows the attacker to send over a bit per cell. But it will be somewhat noisy, since some cells will dropped and reordered naturally. Padding, traffic splitting, and concurrent activity will increase the noise of this attack; we lack metrics to tell us how much, and we have no framework as of yet to measure the throughput of the resulting side channel in these conditions. ### Traffic Fingerprinting of TCP-like systems Today, because Tor terminates TCP at the guard node, there is limited ability for the exit node to fingerprint client TCP behavior (aside from perhaps measuring some effects on traffic volume, but those are not likely preserved across the Tor network). However, when using a TCP-like system for end-to-end congestion control, flow control, and reliability, the exit relay will be able to make inferences about client implementation and conditions based on its behavior. Different implementations of TCP-like systems behave differently. Either party on a stream can observe the packets as they arrive to notice cells from an unusual implementation. They can probe the other side of the stream, nmap-style, to see how it responds to various inputs. If two TCP-like implementations differ in their retransmit or timeout behavior, an attacker can use this to distinguish them by carefully chosen patterns of dropped traffic. Such an attacker does not even need to be a relay, if it can cause DTLS packets between relays to be dropped or reordered. This class of attacks is solvable, especially if the exact same TCP-like implementation is used by all clients, but it also requires careful consideration and additional constraints to be placed on the TCP stack(s) in use that are not usually considered by TCP implementations -- particularly to ensure that they do not depend on OS-specific features or try to learn things about their environment over time, across different connections. ### Retransmit-based watermarking Even if all TCP-like implementations are identical, they will retransmit with different timing and volume based on which cells have been acked or not acked. These differences may be observable from many points on the circuit, or from outside the network. Such retransmissions can be induced from outside the network, by hostile relays, or even by a hostile endpoint that pretends not to have received some of the packets. We again lack metrics to indicate that it is substantially worse (or not worse) than other similar attacks. Intuitively, the key difference in degree would come from how much easier it is to perform this attack than the delay based watermarking attacks on traditional Tor above. ### Congestion and flow control interference To the extent that the TCP-like stack uses information learned from one stream to alter its behavior on another stream, an attacker can exploit this interference between streams make all of the streams from a given party more linkable. All implementations will have some amount of interference, to the extent that their bandwidth is limited. But some may have more than necessary. ### Non-malleable encryption designs only currently exist for in-order transports (or the return of data tagging attacks) Our proposed defenses against data tagging require us to move to non-malleable encryption, with each cell's encryption tweaked by a function of all previous cells, so that if even a single cell is modified, not only is that cell corrupted, but no subsequent cell can be decrypted. It seems nontrivial to achieve this property with datagram based designs, since we require that cells on a circuit can be decrypted even when previous cells have not arrived. We can achieve data-based non-malleability by using a per-hop MAC for each cell -- but we would no longer be able to get the property that a since altered cell would make the whole circuit unrecoverable. This would enable a one-bit-per-cell side-channel, similar but possibly more powerful than the packet dropping side-channel above. (Because the congestion window is essentially a bit vector of received cells, the adversary in this scenario gets to corrupt cells in carefully chosen ways instead of merely dropping them.) Perhaps other cryptographic schemes could be found to resist data-tagging in a datagram-based environment or limit its impact, but we'll need to figure out what the requirements and models are. As a proof-by-example of a mitigating system: Proposal 253 describes a way to send a rolling MAC out of band, to ensure integrity of packets between those cells. But can we do better? Can middle nodes enforce integrity in some other way? ### The risks of success: lower latency strengthens timing attacks? There are two factors that make timing-correlation and timing-watermark attacks more difficult in practice: similarity between different users' traffic, and distortion in timing patterns caused by variance in cell latency on the network. To whatever extent we successfully reduce this distortion by lowering latency, it seems that we'll make these attacks more powerful. In particular, geolocation attacks based on observed circuit setup times may get worse [See again https://www.freehaven.net/anonbib/cache/ccs07-latency-leak.pdf]. We're already making improvements to Tor that may make these attacks worse -- Tor latency has dropped and will continue to drop due to improvements like KIST, more relays, and better load balancing. Further incremental improvements like explicit congestion control on the existing Tor network will reduce latency even further. It may be that a more performant Tor becomes less safe than a slower, less usable Tor. On the other hand, a more usable Tor will likely be used by more people, which we know makes many forms of traffic analysis harder (slower?) in general. However, we have no way to measure this tradeoff on many different attack types. Delay and latency can also be added back in, and this has been a common defense against both active adversaries and timing attacks in the anonymity literature, but such delays have user-facing consequences, unless they are carefully restricted to the cases where the adversary can directly measure RTT and can be amortized away by things like pre-emptive circuit building. In this and other cases, it is also not clear to what degree adding delay is more useful than adding more padding. ## Towards comparing attacks A high-bandwidth attack is worse than a low-bandwidth attack. One bit is enough to send "is this the targeted user?", but 32 bits is enough to send a whole IP address. The impact of these attacks become worse if they can be repeated over time. An attack that can be performed by an ISP relaying traffic is worse than one that can be performed by a relay. An attack that can be performed remotely against either of these is worse still. We need some kind of methodology to help us compare the new side channels that datagram transports may enable to the existing side channels in Tor, particularly delay-based and congestion-based side channels. Ideally, these metrics or evaluation methodology would also allow us to compare these side channels under various forms of defense, such as padding. At the very least, we need some way to compare the side channels in datagram transports to those that already exist. We also likely need a common reference research prototype and/or platform to experiment with and study, so that attacks and defenses are reproducibly comparable. Reproducibility in attack and defense literature is often not reliable, due to differing implementations, in addition to differing methodology and evaluation frameworks. ## Open Questions Why permit reordering? There are schemes (like order-preserving encryption) that we could deploy on middle nodes to prevent reordering, without allowing earlier nodes to differentiate padding from non-padding. Do we derive any benefit by allowing a relay to send cells on a single circuit in a different order than the order in which it receives those cells on that circuit? This may be an answered question in congestion control research, but we lack the domain expertise to know what this tradeoff is. Related: what cryptography to use? Our current stateful encryption schemes benefit from having access to "all previous cells" when encrypting or decrypting each following cell. If we allow a cell to be {de,en}crypted before previous cells are received, we'll need a new model for onion-routing cryptography -- possibly one with significantly bigger headers. ## Future work We hope to investigate these issues with researchers and others in the Tor community as we work towards solutions to help scale and strengthen the Tor network. Understanding the risks and rewards that datagram-based transports introduce to Tor is important to help us select designs that both help improve performance but also guarantee safety for Tor users. We hope that by cataloging these risks, future conversations about improved network designs can bring answers and broader improvements. We look forward to working with others interested in helping solve these problems to design a better Tor. ## Acknowledgments Our thanks to Chelsea Komlo for many helpful suggestions and comments on earlier drafts of this whitepaper, and for writing the request for future work. ## Further reading Steven Murdoch, "Comparison of Tor Datagram Designs", 2011. https://murdoch.is/papers/tor11datagramcomparison.pdf Mashael AlSabah and Ian Goldberg. "PCTCP: per-circuit TCP-over-IPsec transport for anonymous communication overlay networks", 2013. http://cacr.uwaterloo.ca/techreports/2013/cacr2013-09.pdf Michael F. Nowlan, David Wolinsky, and Bryan Ford. "Reducing Latency in Tor Circuits with Unordered Delivery", 2013. https://www.usenix.org/system/files/conference/foci13/foci13-nowlan.pdf Rob Jansen, Florian Tschorsch, Aaron Johnson, and Björn Scheuermann The Sniper attack: Anonymously Deanonymizing and Disabling the Tor Network", 2013 https://www.nrl.navy.mil/itd/chacs/sites/edit-www.nrl.navy.mil.itd.chacs/fi…

3 2

OnionShare bug that's possibly caused by an upstream v3 onion bug
by Micah Lee 26 Nov '18

26 Nov '18

I've been working on a major OnionShare release that, among other things, will use v3 onion services by default. But it appears that either something in stem or in Tor deals with v3 onions differently than v2 onions, and causes a critical bug in OnionShare. It took a lot of work to track down exactly how to reproduce this bug, and I haven't opened an upstream issue for either stem or tor because I feel like I don't understand it enough yet. Here is the OnionShare issue [1]. Does anyone know if this is an issue with stem or tor, and how to go about mitigating it? Here's some background: When you share files with OnionShare it starts a local web server and then makes it an ephemeral onion service. Someone else loads this onion service in Tor Browser and downloads your files. If the setting "Stop sharing after first download" is checked (this is the default behavior), then as soon as the download completes, OnionShare stops the onion service and web server. If I share a 1mb file and a Tor Browser client makes an HTTP request to download it, OnionShare will respond with a 1mb HTTP response. As soon as it's done sending the 1mb, OnionShare stops the server and alerts the user that transfer is complete -- however, it's not actually complete yet. If you look at the client in Tor Browser, it's still downloading. It depends on the Tor circuit, but it might be only ~32% done, and you have to wait a few seconds for it to finish. This is because when the final byte of the 1mb file leaves the OnionShare web server, it takes a few seconds for that final byte to make it through the onion circuit and into Tor Browser download. This works fine with v2 onion services. But with v3 onion services, as soon as the OnionShare web server finishes sending the full HTTP response, the torified HTTP client stops downloading. I made a small python script, onion-bug.py, that reproduces the issue that you can test [2]. This script connects to the default Tor control port for Tor Browser, so open Tor Browser in the background. It then start an HTTP server and creates an onion service, and if you make a GET request to the server it responds with 2mb of "A" characters, and then immediately stops the web server and onion service. You have to pass in either "v2" or "v3", depending on which type of onion service to make. Like OnionShare, this script uses stem, and specifically the Controller.create_ephemeral_hidden_service method [3]. I just ran "./onion-bug.py v2" in one terminal and waited for it to start: ``` $ ./onion-bug.py v2 http service: http://127.0.0.1:8080/ starting onion service with: key_type='NEW', key_content='RSA1024' http://d7vomh45i7ryhhfw.onion/ ``` Then in a second terminal, I made the GET request: ``` $ torify curl http://d7vomh45i7ryhhfw.onion/ > out2 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1024k 0 1024k 0 0 125k 0 --:--:-- 0:00:08 --:--:-- 245k ``` The script in the first terminal finished and quit (while curl on the second term finished the download for a few more seconds): ``` 127.0.0.1 - - [24/Nov/2018 21:12:52] "GET / HTTP/1.1" 200 - shutting down http server ``` The file, out1, is exactly 1mb. Now I tried doing the same, but with a v3 onion service: ``` $ ./onion-bug.py v3 http service: http://127.0.0.1:8080/ starting onion service with: key_type='NEW', key_content='ED25519-V3' http://htrzngqgb7ogyifsvah6qz7t6spe3rr7bikdws7d3rigkpwy5kuyrlqd.onion/ 127.0.0.1 - - [24/Nov/2018 21:14:22] "GET / HTTP/1.1" 200 - shutting down http server ``` And in the other terminal: ``` $ torify curl http://htrzngqgb7ogyifsvah6qz7t6spe3rr7bikdws7d3rigkpwy5kuyrlqd.onion/ > out2 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 29830 0 29830 0 0 3399 0 --:--:-- 0:00:08 --:--:-- 3399 ``` It only downloaded 29830 bytes before the download connection stopped, so out2 is only 30kb. I just tried it again, and this time only got 12kb downloaded. And I tried it again, and got 41kb downloaded. It appears to depend on the speed of the Tor circuit. The download only stops when the v3 onion service is shut down -- if you uncomment out the time.sleep(5) before calling remove_ephemeral_hidden_service at the end of the script, you'll be able to download the full 1mb using the v3 onion server. I'm pretty stumped on how to fix this and I'd appreciate any help. Until it's fixed, we'll either have to not include support for v3 onion services in OnionShare in the next major release (version 2.0), or include support but with the "Stop sharing after first download" only available for v2 onion services -- so probably we'd default to using v2 onion services, and users could optionally use v3 if they don't need the autostop feature. Of course, I'd much prefer to find a way to solve this and release with v3 onion services by default. [1] https://github.com/micahflee/onionshare/issues/812 [2] https://gist.github.com/micahflee/bade960e96d35007bc5c182a0ca61b56 [3] https://stem.torproject.org/api/control.html#stem.control.Controller.create…

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev November 2018