- tor-dev - lists.torproject.org

Upcoming Tor change with application impact: "Dormant Mode"
by Nick Mathewson 04 Jan '19

04 Jan '19

Hello! This email is about a new feature that has some implications here for applications that use Tor. I want to make sure we've thought about and prepared for those implications, since we still have time to tweak this feature. == Overview In 0.4.0.x, Tor will begin supporting a new "dormant" mode in which it does not initiate network activity, and tries to avoid CPU wakeups. This mode is intended to help mobile devices sleep, and to minimize the impact of unused Tor clients on the network, and on the devices that run them. For the implementation history, see: https://trac.torproject.org/projects/tor/ticket/28335 and https://trac.torproject.org/projects/tor/ticket/28624 By default, Tor will become dormant if it is a pure client (not a relay, not an onion service[*]), and if it has received not client activity for 24 hours. (You can change the interval with DormantClientTimeout.) Unlike "DisableNetwork 1", Tor in dormant mode will not close any listener ports, and will become active again as soon as it receives a client connection. But like a "DisableNetwork 1" Tor, a dormant Tor will not build predicted circuits, and will not download directory information -- and therefore, will not bootstrap. Controllers can make Tor become dormant or non-dormant by sending the commands "SIGNAL DORMANT" and "SIGNAL ACTIVE" respectively -- these are now documented in control-spec.txt. Dormant state is persistent: if Tor has been idle for 20 hours, and you stop tor and start it again, and idle for 4 more hours, Tor will become dormant. If you stop tor and start it again, Tor will start in dormant mode. == Documentation Here's the documentation we have so far -- please let me know if you have ideas for clarification: DormantClientTimeout N minutes|hours|days|weeks If Tor spends this much time without any client activity, enter a dormant state where automatic circuits are not built, and directory information is not fetched. Does not affect servers or onion services. Must be at least 10 minutes. (Default: 24 hours) DormantTimeoutDisabledByIdleStreams 0|1 If true, then any open client stream (even one not reading or writing) counts as client activity for the purpose of DormantClientTimeout. If false, then only network activity counts. (Default: 1) DormantOnFirstStartup 0|1 If true, then the first time Tor starts up with a fresh DataDirectory, it starts in dormant mode, and takes no actions until the user has made a request. (This mode is recommended if installing a Tor client for a user who might not actually use it.) If false, Tor bootstraps the first time it is started, whether it sees a user request or not. After the first time Tor starts, it begins in dormant mode if it was dormant before, and not otherwise. (Default: 0) == Compatibility issues I see two issues here: one minor, and one major. Minor issue: some applications periodically make requests to the tor network on their own -- for example, Tor Browser's update requests. These requests prevent Tor from becoming dormant. If this is undesired, we can add some way around this. Major issue: some applications expect that Tor will always bootstrap when it starts, and delay presenting their own UI until Tor is ready. But if Tor starts as dormant, then it will not bootstrap until it receives a request from the client or a "SIGNAL ACTIVE" command from the controller. This could lead to breakage as the application waits for Tor to tell it that it's ready, and Tor waits for somebody to tell it that it's needed. Are all application developers okay with the issues above, and okay with working around them? If not, we may need changes in Tor before 0.4.0.x is released. Let's talk! [*] I'd like to add support for dormant onion services, but that's harder. See https://trac.torproject.org/projects/tor/ticket/28424 . peace, -- Nick

7 10

Queries regarding Summer of Privacy 2019
by Pranav Vardia 04 Jan '19

04 Jan '19

Hi, I am Pranav Vardia , third year student from International Institute of Information Technology, Bangalore. I am writing this mail to clarify few of my queries regarding Summer of Privacy. Firstly, I would like to ask that is there a list of projects whcih we can work on or do we need to come up with our own proposal ? Secondly, I cannot find any timeline and project lists for previous years Summer of Privacy. It would be great if you could provide me links to the aforementioned. Regards, Pranav Vardia

2 1

HTTPS and Tor Onion v3 Services
by Nathaniel Suchy 28 Dec '18

28 Dec '18

Hi everyone, So I have an idea which may or may not be a possibility. Currently Tor Onion Services do not need HTTPS since they are already end to end encrypted. That said multiple layers of crypto cannot hurt, Facebook for example uses this approach. So I have the idea of some sort of mechanism that lets you sign a self-signed tls certificate with your Onion Service's hs_ed25519_secret_key and Tor Browser trusting the tls certificate based on this signature. Would this approach work? Would it be worth the effort? Look forward to hearing your thoughts :) Cordially, Nathaniel Suchy

3 3

Re: [tor-dev] Regarding projects and a begineer guide.
by teor 21 Dec '18

21 Dec '18

Hi, Here's the torsocks README: https://gitweb.torproject.org/torsocks.git/tree/README.md You could start by building and installing torsocks: https://gitweb.torproject.org/torsocks.git/tree/INSTALL T -- teor ---------------------------------------------------------------------- > On 16 Dec 2018, at 01:26, Durgesh Kumar <durgesh.17bcs1179(a)abes.ac.in> wrote: > > Thanks for your reply.. > > I am intrested in TORSOCKS under usability category. > Can you please provide me a begineer guide about the project so that i can get familiar with it. > > Sorry for late reply. > > > >> On Mon 10 Dec, 2018, 6:40 AM teor, <teor(a)riseup.net> wrote: >> Hi, >> >> > On 7 Dec 2018, at 02:28, Durgesh Kumar <durgesh.17bcs1179(a)abes.ac.in> wrote: >> > >> > Dear sir/mam >> > I am durgesh kumar from ABES engineering college,ghaziabad,uttar pradesh,india. >> > >> > I am currently in 2nd year of my graduation(Btech CSE ) >> > >> > I want to contribute in some of your prestigious project. So i request you to please provide me some of your top priority project and a begineer guide. >> > >> > I hope you will concern my request. >> >> Here's a list of our projects and some project ideas: >> https://www.torproject.org/getinvolved/volunteer.html.en#Projects >> >> Let us know which ones you're interested in. >> >> T >>

1 0

Update on Guardian Project Pluggable Transport work
by Hans-Christoph Steiner 13 Dec '18

13 Dec '18

The Guardian Project "PLUTO" project is our name for the work we're doing around Pluggable Transports. If you want to follow this work more closely, you can ask n8fr8 to add you to our semi-private PLUTO mailing list. n8fr8 is currently working on integrating PTs into Android apps in a reusable way. That work is mostly in https://github.com/guardianproject/AndroidPluggableTransports I recently did some work to port snowflake to Android. That should be useable now, but with some open issues about repeatable builds and verification that non-free libs are not linked in. That's mostly here: https://github.com/keroserene/snowflake/pull/43 Then we're doing full stack prototypes for using PTs in Android apps, based on Wikipedia, F-Droid and an RFA app. That stuff is scattered around. >From that work, uniqx (Michael Poehn) has produced a PT bridge server setup automation: https://gitlab.com/uniqx/pt-socks5-over-obfs4proxy uniqx and I are now focused on Encrypted SNI for use as a PT, so there will be some server automation around that, e.g. custom openssl/mod_ssl build included. .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556

1 0

prob_distr.c: LogLogistic fails stochastic tests on 32-bits mingw
by George Kadianakis 13 Dec '18

13 Dec '18

Hello Riastradh, as discussed on IRC, Appveyor recently started failing the stochastic tests of LogLogistic on 32-bit builds: https://github.com/torproject/tor/pull/576 https://ci.appveyor.com/project/torproject/tor/builds/20897462 I managed to reproduce the breakage by cross-compiling Tor and running the tests with wine, using this script of ahf: https://github.com/ahf/tor-win32/ Here are my findings: The following two test cases are breaking 100% reproducibly: ok = test_stochastic_log_logistic_impl(M_E, 1e-1); ok = test_stochastic_log_logistic_impl(exp(-10), 1e-2); The breakage seems to be because of the beta parameter. In particular, it seems like the test will break with any beta <= 0.26, and will succeed with a beta >= 0.27. The space in between is still unclear ;) I haven't managed to figure out what's actually offending the test but I can reproduce this so I can do some digging if you have any ideas. FWIW, I haven't noticed any other stochastic test breakage. Cheers!

2 3

Regarding projects and a begineer guide.
by Durgesh Kumar 10 Dec '18

10 Dec '18

Dear sir/mam I am durgesh kumar from ABES engineering college,ghaziabad,uttar pradesh,india. I am currently in 2nd year of my graduation(Btech CSE ) I want to contribute in some of your prestigious project. So i request you to please provide me some of your top priority project and a begineer guide. I hope you will concern my request.

2 1

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

Failure to connect to a 0.3.4.9 bridge--downgrading to 0.2.9.17 fixes it
by David Fifield 08 Dec '18

08 Dec '18

Here, a user reported a failure to connect to their own bridge, stopping at 25% bootstrapped. teor and I went through the basic troubleshooting steps of checking the bridge syntax, system time, and firewall settings. With or without obfs4 didn't make a difference. The user eventually tried downgrading the bridge from 0.3.4.9 to 0.2.9.17--and that fixed it. Their client version was 0.3.4.9. https://bugs.torproject.org/28717#comment:18 They also tried with two bridges from BridgeDB. The one running 0.3.4.9 didn't work, and the one running 0.2.9.17 did. A possible lead are these client log messages: [info] handle_response_fetch_desc(): Received server info (body size 0) from server 'X.X.X.X:YYYY' [info] handle_response_fetch_desc(): Received http status code 404 ("Servers unavailable") from server 'X.X.X.X:YYYY' while fetching "/tor/server/authority.z". I'll try again soon.

1 1

Re: [tor-dev] Easy(?) adaptation of meek-client for ESNI
by Hans-Christoph Steiner 07 Dec '18

07 Dec '18

Nathan of Guardian: > On Mon, Sep 24, 2018 at 08:23:58PM -0600, David Fifield wrote: >> What we would need in order for meek to used encrypted SNI would be >> either: >> 1) support for encrypted SNI in Go's crypto/tls package; or >> 2) support for encrypted SNI in the Firefox that ships with Tor >> Browser, which meek-client could use through its TLS camouflage >> helper support. >> >> IMO (2) is less desirable because I'd like to get rid of the TLS >> camouflage helper support and replace it with a Go-level TLS camouflage >> library: https://github.com/refraction-networking/utls. The TLS helper >> works, but its complexity is a pain to deal with and leads to problems >> like https://bugs.torproject.org/12774 https://bugs.torproject.org/25405. > > I wrote an untested overview of how to adapt meek to use ESNI, using an > external copy of Firefox Nightly rather than Tor Browser's built-in copy > of Firefox. Testing this out to see if it works would be a good task for > someone who wants to get involved with pluggable transports. > > Use ESNI via Firefox HTTPS helper > https://bugs.torproject.org/28168 > > 1. Download Tor Browser and Firefox Nightly. > 2. Go to about:config in Firefox nightly and set > network.trr.mode=3 > network.trr.uri=https://1.1.1.1/dns-query > network.security.esni.enabled=true > 3. Copy the meek-http-helper(a)bamsoftware.com.xpi from Tor Browser to > Firefox Nightly. > 4. Hack meek-client-torbrowser/{mac,linux,windows}.go to point > firefoxPath at the copy of Firefox Nightly and disable the custom > profile. (Additional hacks to remove hardcoded Tor Browser > assumptions may be required.) > 5. Set up a Cloudflare instance pointing to https://meek.bamsoftware.com/, > call it https://meek.example.com/. > 6. Set up a custom bridge in Tor Browser, using url= without front= > (because we're no longer domain fronting). > bridge meek 0.0.2.0:3 url=https://meek.example.com/ > > The only slightly weird part I foresee is hacking > meek-client-torbrowser; it has some internal hardcoded paths and > profiles that are specific to the Tor Browser directory layout, and > you'll have to point those to an external Firefox Nightly. Of course, > once ESNI support makes its way into Tor Browser itself, there won't be > a need for another external copy of Firefox. Two things to follow up on this thread: 1) I believe ESNI support is now in the Firefox betas, so that approach is looking like an option 2) Guardian Project got a grant to work on a full stack prototype of using Pluggable Transports. We're going to try to do it with ESNI using Stephen Farrell's patches to openssl. My last thought on this topic for today: we should be careful about making it too easy to use ESNI for circumvention before its gained any server side implementers. If it gets branded a activist tool, I could see many orgs failing to adopt ESNI. I think Cloudflare is the only active provider offering it. .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556

1 0

Scheduled changes to Tor Metrics CSV files in the Performance and the Traffic category
by Karsten Loesing 06 Dec '18

06 Dec '18

Hi, if you're not pulling CSV files from the Tor Metrics website in an automated fashion, you can stop reading now. We just scheduled some changes to the Tor Metrics CSV files in the Performance and the Traffic category: - December 20, 2018 (scheduled): Remove source parameters and output rows with aggregates over all sources from Time to download files over Tor, Timeouts and failures of downloading files over Tor, Circuit build times, Circuit round-trip latencies graphs. - December 20, 2018 (scheduled): Remove two graphs Total relay bandwidth and Consumed bandwidth by Exit/Guard flag combination, and update the data format of the Advertised and consumed bandwidth by relay flag graph to cover all data previously contained in the first two graphs. For more details, see: https://metrics.torproject.org/stats.html I'm posting this note here, because some folks might pull these CSV files automatically, and they should have at least a two-weeks warning to update their scripts. All the best, Karsten

2 1

Throughput of each circuit
by marziyeh latifi 05 Dec '18

05 Dec '18

Hello, I want to count the number of cells that are sent from circuit queue to the output buffer in each relay. How can I do this? Any opinion? thanks, marziyeh

2 1

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

Tor summer of privacy
by Ziad Marghany 24 Nov '18

24 Nov '18

Hi, I would like to participate in Tor summer of privacy, and I would like how I can start preparing from now on. Also, I would like to ask about if I want to propose a project idea, how I should present my idea and should I make a prototype ? I know this is maybe a bit early but I wasn't able to participate last year because I haven't prepared early so, I would like to take my time this year. Thank you for your help and your time.

2 1

Pastly stepping away from sbws
by Matt Traudt 21 Nov '18

21 Nov '18

I don't have the resources to continue paying attention to the going-ons of sbws development. It's time for me to clearly and cleanly step away from sbws and let Tor do with it what they will. It's in good hands. I've taken the steps I could think of: - Removed myself from the sbws-admins github team - Removed myself from the default CC list on trac - #28559 to revoke my push power to gitweb.tpo/sbws.git You should feel free to CC me on tickets or grab my attention for specific issues. Matt

1 0

PrivCount and Prio IRC Meeting
by teor 20 Nov '18

20 Nov '18

Hi all, We are meeting to discuss PrivCount and Prio at 2200 UTC on Tuesday 20 November in #tor-meeting on irc.oftc.net. We will log the meeting, so that people who can't attend can catch up later. Here's some background: Henry Corrigan-Gibbs recently built a private statistics system called Prio <https://crypto.stanford.edu/prio/> that is now used for privately collecting telemetry at Mozilla <https://hacks.mozilla.org/2018/10/testing-privacy-preserving-telemetry-with…>. It provides a similar functionality to PrivCount <https://ohmygodel.com/publications/privcount-ccs2016.pdf> that Tor is planning to use, and also provides strong robustness against malformed or malicious reports. Some questions we'll discuss: How can we design Tor's statistics to make it easy to: * defend against corruption attacks, and * support more complex aggregate statistics. How does PrivCount in Tor's design handle aggregation server failures? Some background: Here's my quick comparison of Prio and PrivCount in Tor: * Prio servers can do complex calculations using linear data structures * PrivCount is limited to additive totals (and histograms) * Prio servers can defend against corruption attacks using SNIPs (secret non-interactive proofs) * PrivCount in Tor has an optional scheme to defend against corruption, but it requires adding additional noise * Prio doesn't have differential privacy (yet) * PrivCount guarantees differential privacy across the entire set of statistics * Prio increases security by failing when one server fails * PrivCount in Tor is robust to server failure, and compensates for the decreased security by adding more noise (The PrivCount design used for our research papers was not robust, and failed whenever any server or client failed.) Here are our latest specs, notes, and code for PrivCount in Tor: https://gitweb.torproject.org/torspec.git/tree/proposals/288-privcount-with… https://trac.torproject.org/projects/tor/wiki/org/meetings/2018MexicoCity/N… https://trac.torproject.org/projects/tor/wiki/org/meetings/2018MexicoCity/N… https://github.com/nmathewson/privcount_shamir T -- teor ----------------------------------------------------------------------

2 2

Bandwidth scanner: request for feedback
by teor 20 Nov '18

20 Nov '18

Hi, Juga and pastly have been working hard on sbws. Sbws' results are now similar to torflow's results: https://trac.torproject.org/projects/tor/attachment/ticket/27135/20180826_0… Now that sbws is close to torflow, we want some feedback on its design. We’ll work on the design at the tor meeting in September. Please feel free to give feedback by email, or on the tickets: What happens when sbws doesn't match torflow? https://trac.torproject.org/projects/tor/ticket/27339 We suggest this rule: If an sbws deployment is within X% of an existing bandwidth authority, sbws is ok. (The total consensus weights of the existing bandwidth authorities are within 25% - 50% of each other, see #25459.) How long should sbws keep relay bandwidths? https://trac.torproject.org/projects/tor/ticket/27338 Torflow uses the latest self-reported relay observed bandwidth and bandwidth rate. Torflow uses a complex feedback loop for measured bandwidths. We think sbws can use a simple average or exponentially decaying weighted average. How should we scale sbws consensus weights? https://trac.torproject.org/projects/tor/ticket/27340 If sbws' total consensus weight is different to torflow's total consensus weight, how should we scale sbws? (The weights might differ because the measurement method is different, or because scanners and servers are in different locations.) In the bandwidth file spec, we suggest linear scaling. How should we round sbws consensus weights? https://trac.torproject.org/projects/tor/ticket/27337 Torflow currently rounds to 3 significant figures (which is a maximum of 0.5%). But I suggest 2 significant figures for sbws (or max 5%), because: - tor has a daily usage cycle that varies by 10% - 20% - existing bandwidth authorities vary by 25% - 50% Proposal 276 contains a slightly more complicated rounding algorithm, which we may want to implement in sbws or in tor: https://gitweb.torproject.org/torspec.git/tree/proposals/276-lower-bw-granu… Does sbws need a maximum consensus weight fraction? https://trac.torproject.org/projects/tor/ticket/27336 Torflow uses 5%, but I suggest 1%, because the largest relay right now is only 0.5%. T -- teor Please reply @torproject.org New subkeys 1 July 2018 PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ----------------------------------------------------------------------

4 4

How does Tor plan to deal with HTTP/3 (HTTP over QUIC)
by neel＠neelc.org 17 Nov '18

17 Nov '18

Hi @tor-dev mailing list, How would Tor deal with HTTP/3 (a.k.a. HTTP over QUIC), considering that Tor is a TCP anonymizer, and HTTP over QUIC (and QUIC itseld) uses UDP? Would we need Tor to support UDP? Just QUIC? Thanks, Neel Chauhan === https://www.neelc.org/

2 1

Empty menu item in Help menu
by scootergrisen 12 Nov '18

12 Nov '18

I tried testing Tor Browser in macOS (VirtualBox) and at the bottom of the Help menu i see a empty menu item. If i remember correct nothing happened if i clicked it.

2 1

Icon misaligned in macOS drag icon dialog
by scootergrisen 12 Nov '18

12 Nov '18

The icon is misaligned in macOS for the installer or whatever it is called.

2 1

network team weekly meeting - nov 12th
by Gaba 12 Nov '18

12 Nov '18

Hi! This week's network team meeting is on Monday at 1800 UTC. Our meetings are held on #tor-meeting on OFTC. cheers, gaba

1 0