- tor-dev - lists.torproject.org

Raising AuthDirMaxServersPerAddr to 4?
by Roger Dingledine 04 Jun '19

04 Jun '19

Hi folks, I've been talking to a longtime exit relay operator, who is in the odd position of having a good 1gbit network connection, but only one IP address. He used to push an average of 500mbit on his exit relay, but then the HSDir DoS flatlined his relay for a while (!), and now, perhaps due to the bwauth variability, his exit relay only recovered to maybe 200mbit. He is running a second exit relay on that IP address, but also perhaps due to the bwauth variability, it hasn't attracted much attention either. The real answer is to fix the bandwidth measurement infrastructure. But while we're patiently waiting for progress there, I've been thinking to raise moria1's AuthDirMaxServersPerAddr to 4, i.e. to allow 4 relays per IP address onto the network. I don't think it would significantly increase our risk due to Sybil attacks, whereas there is a clear benefit in terms of some more 100's of mbits of good exit relay capacity. I will propose this change to the dir-auth list in a bit, but here is your chance to point out surprising impacts that I haven't thought of. Thanks! --Roger

3 14

Release: obfs4proxy-0.0.10
by Yawning Angel 02 Jun '19

02 Jun '19

Hello, I just tagged obfs4proxy-0.0.10. The primary changes are a minor fix to the meek_lite behavior when using `utls` as the TLS implementation, and a series of updates (primarily following upstream) to the `utls` library. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.1… https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.1… Changes in version 0.0.10 - 2019-04-12: - Disable behavior distinctive to crypto/tls when using utls. - Bump the version of the utls fork. Regards, -- Yawning Angel

5 6

Should we allow matrix.org users on tor IRC channels?
by teor 01 Jun '19

01 Jun '19

Hi all, JeremyRand has asked us to allow matrix.org users on the tor IRC channels on irc.oftc.net. matrix.org users are rejected at the moment, because they are not registered with OFTC. For details, see: https://trac.torproject.org/projects/tor/ticket/30717 T -- teor ----------------------------------------------------------------------

1 0

Fwd: Orbot 16.1.0-BETA-1-tor-0.4.0.4-rc
by Nathan Freitas 31 May '19

31 May '19

Tor 0.4.0.4 working well on Android. We've updated the tor-android library to 0.4.0.4-rc, and included it in the latest Orbot beta. It is available via Gradle at the usual spot (see below): https://github.com/guardianproject/tor-android/releases/tag/tor-android-bin… maven { url "https://raw.githubusercontent.com/guardianproject/gpmaven/master" } implementation 'org.torproject:tor-android-binary:0.4.0.4-rc' -------- Forwarded Message -------- Subject: Orbot 16.1.0-BETA-1-tor-0.4.0.4-rc Date: Fri, 31 May 2019 16:25:20 -0400 From: Nathan of Guardian <nathan(a)guardianproject.info> Organisation: Guardian Project To: Guardian Dev <guardian-dev(a)lists.mayfirst.org> /** 16.1.0-BETA-1-tor-0.4.0.4-rc / 31 May 2019 / 417e4fcd0720be57328d63a96d2c9fc0e119330f **/ TAG: https://gitlab.com/guardianproject/orbot/tags/16.1.0-BETA-1-tor-0.4.0.4-rc Thanks to @bitmold @sisbell and @eighthave for all the great work, not to mention the core Tor dev team making all things mobile better every day! APKs posted at: https://guardianproject.info/releases/ [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-arm64-v8a-release.apk 2019-05-31 15:17 12M [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-arm64-v8a-release.apk.asc 2019-05-31 15:17 833 [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-armeabi-release.apk 2019-05-31 15:18 12M [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-armeabi-release.apk.asc 2019-05-31 15:18 833 [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-armeabi-v7a-release.apk 2019-05-31 15:18 12M [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-armeabi-v7a-release.apk.asc 2019-05-31 15:18 833 [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-universal-release.apk 2019-05-31 15:18 32M [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-universal-release.apk.asc 2019-05-31 15:18 833 [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-x86-release.apk 2019-05-31 15:18 12M [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-x86-release.apk.asc 2019-05-31 15:18 833 [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-x86_64-release.apk 2019-05-31 15:18 12M [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-x86_64-release.apk.asc 417e4fcd update version to 16100003 aka 16.1.0-BETA-1-tor-0.4.0.4-rc 7ae000d0 fix pdnsd/VPN support dde1957d Merge pull request #219 from bitmold/delete_minimalperm_manifest a251d52f Merge pull request #218 from bitmold/ndk_app_platform_warning eda464bb remove incorrect torFile assignment a1c5806a update tor-android to 0.4.0.4-rc ad2e875b We no longer use the minimalperm product flavor so there's no need to keep this manifest file in app/src 917e49f5 Removes warning on ndk-build where the target API for NDK (16) is greater than the sdk version defined for the project. Since nothing was specified in the manifest it defaulted to 1 but we can set this to Orbot's minSdkVersion of 16 to get rid of this warning f83a98f4 Merge branch 'sisbell-issue_199' ff7d3dd5 (sisbell-issue_199) Merge branch 'issue_199' of https://github.com/sisbell/orbot into sisbell-issue_199 7c2cfc3e Merge pull request #212 from sisbell/issue_211 1316fd65 Merge branch 'bitmold-no_personalized_learning_kb' e3fd4afa (bitmold-no_personalized_learning_kb) Merge branch 'no_personalized_learning_kb' of https://github.com/bitmold/orbot into bitmold-no_personalized_learning_kb aa8ad867 Merge pull request #204 from bitmold/unreferenced_classes 16826a49 Merge branch 'bitmold-removed_obsolete_version_checks' 17154609 (bitmold-removed_obsolete_version_checks) Merge branch 'removed_obsolete_version_checks' of https://github.com/bitmold/orbot into bitmold-removed_obsolete_version_checks 0e4b42a7 add close bracket 4cee987c Merge branch 'master' into removed_obsolete_version_checks 08c35bd3 Remove unused resources. ae4ce1c9 Fixes #211: Resource Not Found on Command Line Build 2fb7e05a Merge pull request #210 from eighthave/fastlane 57120100 rename all metadata locale dirs after the Fastlane/Play names baced180 setup Fastlane to upload to Google Play d2feefdd Removed Obsolete @TaretApi Annotations for API Levels that are lower than Orbot's minimum, API Level 16 a32452e7 Make text inputs in Orbot declare that they do want to opt out of IME personalized learning. Of course, IMEs may ignore this request, but it's a nudge in the direction of Tor's general philosophy on user privacy, particularly with regards to minimizing the footprint that a Tor app leaves on the user's device. 7d8e41a6 Removed Constraint Layout Dependency 5d04d418 Removed Unused Classes 2b6abd7e Removed Obsolete Version Checks cd6560fa Merge pull request #202 from bitmold/no_constraint_layout a5d5c99f (public/master, gl/master) remove unused launcher art 9257b66f don't shrink or minify for now 56917567 (tag: 16.0.6-BETA-2-tor-0.3.5.8) many small changes to support new binary loading, startup and more - improved handling of port conflicts - fixed loading of tor binary on arm64-v8a - changed how w e execute shell commands 8ed080f9 Removed Constraint Layout Dependency 2a76b7af (tag: 16.0.6-BETA-1-tor-0.3.5.8) updated to SDK 28, added android.permission.FOREGROUND_SERVICE permission fb14c76c fixed strings with two many \\ escapes 45575772 updating to tor-0.3.5.8-rc to add support for Android Q 22d5ffdf update gradle tools 76796fea Merge pull request #200 from eighthave/fastlane-supply 6ba0cecc add .gitlab-ci.yml setup with errorprone 3face00a build gradle to 4.4.1, and make gradlew verify the download 69bd7fe9 move app store graphics into fdroid/fastlane file layout f93c11e7 Merge pull request #190 from SkewedZeppelin/master 8ab13f63 Fixup bad indentation from 6e4b7008 12b91c44 Expose PreferIPv6 and NoIPv4Traffic options 8ad76680 Move Google repo above jcenter d4befad1 cleanup and binary loading fixes 2d4e2a5f update tor to 0.3.5.6-RC 0f314214 (tag: 16.0.5-RC-2-tor-0.3.4.9) update to 16.0.5-RC-2-tor-0.3.4.9 2c59c848 ensure startForeground() is always immediately called - since we use startForegroundServce() we must ensure the receiving service complies!

1 0

Merger and Mainline Handovers
by teor 30 May '19

30 May '19

Hi Nick, George, David, (I'm sending this email to tor-dev so everyone knows how Core Tor merges are going.) Mainline Mergers David is back from leave, so I'm going to stop doing mainline merges. But please let me know if there's a merge I can help with. (Email or Signal is best, IRC has a lot of backlog.) Do we need to do a handover some time? The next team meeting might be a good time. Mainline Merge Ready Tickets I moved my mainline merge trac wiki queries to this page: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/Mainlin… That page should show all of the mainline merge_ready tickets, sorted by owner and reviewer. Your name is in bold, so you can work out which tickets you should merge. (We want 3 people to look at every ticket before it merges, except for trivial changes.) Here is our full list of task tracking wiki pages: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam#TaskTra… When does 0.4.0 stop being mainline? It looks like people aren't merging backports to 0.4.0 any more. That's probably a good idea: we should minimise release candidate changes. When should I start doing 0.4.0 merges as part of the backports? Backport Status We released 0.4.0.4-rc last week, so I'm going to backport some low-risk changes to 0.2.9 and later. Most of these changes have been tested in 0.4.0.3-alpha. I should be able to do the backports tomorrow or Tuesday. Here are the backports for the next few days: https://trac.torproject.org/projects/tor/wiki/user/teor#Backports:0.5dayspe… Here are the backports I will do after I get back from my leave in May: https://trac.torproject.org/projects/tor/wiki/user/teor/HiddenBackports T -- teor ----------------------------------------------------------------------

2 2

Network team: New status page for 0.4.1; help needed on ticket triage
by Nick Mathewson 30 May '19

30 May '19

Hi! This mail is mainly for the network-team folks, but I'm sending it to tor-dev anyway in case it's helpful to anybody else. I've made a new page for our 0.4.1 status, based on Teor's previous 040 status page. Here it is: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… Note that this time I'm using two different keywords: 041-must and 041-should. The difference here is that 041 stuff should be things that would really block a release candidate, whereas 041-should stuff is stuff that we might in theory release without fixing. (It might annoy our users or violate our best practices, so we _should_ try to fix it, at least.) At the bottom of the page are all the tickets in the milestone that are *not* marked 041-must or 041-should. Some of these are things we could still fix anyway in 041; many will be removed. Let's triage these together! As discussed at the last meeting, we are currently in feature freeze for 0.4.1. Other than tickets that are marked "postfreeze-ok", we're planning not to take any more features in Tor 0.4.1. (Network team folks, please remember to spend your time on 041-must and 041-should tickets, and on Sponsor 19 tickets. If we make enough progress on these, we can open up 0.4.2 for merging early.) happy hacking, -- Nick

1 1

Proposal 302: Hiding onion service clients using WTF-PAD
by George Kadianakis 27 May '19

27 May '19

Filename: 302-padding-machines-for-onion-clients.txt Title: Hiding onion service clients using padding Author: George Kadianakis, Mike Perry Created: Thursday 16 May 2019 Status: Accepted Ticket: #28634 0. Overview Tor clients use "circuits" to do anonymous communications. There are various types of circuits. Some of them are for navigating the normal Internet, others are for fetching Tor directory information, others are for connecting to onion services, while others are simply for measurements and testing. It's currently possible for MITM type of adversaries (like tor-network-level and local-area-network adversaries) to distinguish Tor circuit types from each other using a wide array of metadata and distinguishers. In this proposal, we study various techniques that can be used to distinguish client-side onion service circuits and provide WTF-PAD circuit padding machines (using prop#254) to hide them against certain adversaries. 1. Motivation We are writing this proposal for various reasons: 1) We believe that in an ideal setting MITM adversaries should not be able to distinguish circuit types by inspecting traffic. Tor traffic should look amorphous to an outside observer to maximize uncertainty and anonymity properties. Client-side onion service circuits are an easy target for this proposal, because we believe we can improve their privacy with low bandwidth overhead. 2) We want to start experimenting with the WTF-PAD subsystem of Tor, and this use-case provides us with a good testbed. 3) We hope that by actually starting to use the WTF-PAD subsystem of Tor, we will encourage more researchers to start experimenting with it. 2. Scope of the proposal [SCOPE] Given the above, this proposal sets forth to use the WTF-PAD system to hide client-side onion service circuits against the classifiers of paper by Kwon et al. above. By client-side onion service circuits we refer to these two types of circuits: - Client-side introduction circuits: Circuit from client to the introduction point - Client-side rendezvous circuits: Circuit from client to the rendezvous point Service-side onion service circuits are not in scope for this proposal, and this is because hiding those would require more bandwidth and also more advanced WTF-PAD features. Furthermore, this proposal only aims to cloak the naive distinguishing features mentioned in the [KNOWN_DISTINGUISHERS] section, and can by no means guarantee that client-side onion service circuits are totally indistinguishable by other means. The machines specified in this proposal are meant to be lightweight and created for a specific purpose. This means that they can be easily extended with additional states to do more advanced hiding. 3. Known distinguishers against onion service circuits [KNOWN_DISTINGUISHERS] Over the past years it's been assumed that motivated adversaries can distinguish onion-service traffic from normal Tor traffic given their special characteristics. As far as we know, there has been relatively little research-level work done to this direction. The main article published in this area is the USENIX paper "Circuit Fingerprinting Attacks: Passive Deanonymization of Tor Hidden Services" by Kwon et al. [0] The above paper deals with onion service circuits in sections 3.2 and 5.1. It uses the following three "naive" circuit features to distinguish circuits: 1) Circuit construction sequence 2) Number of incoming and outgoing cells 3) Duration of Activity ("DoA") All onion service circuits have particularly loud signatures to the above characteristics, but WTF-PAD (prop#254) gives us tools to effectively silence those signatures to the point where the paper's classifiers won't work. 4. Hiding circuit features using WTF-PAD According to section [KNOWN_DISTINGUISHERS] there are three circuit features we are attempting to hide. Here is how we plan to do this using the WTF-PAD system: 1) Circuit construction sequence The USENIX paper uses the directions of the first 10 cells sent in a circuit to fingerprint them. Client-side onion service circuits have unique circuit construction sequences and hence they can be fingeprinted using just the first 10 cells. We use WTF-PAD to destroy this feature of onion service circuits by carefully sending padding cells (relay DROP cells) during circuit construction and making them look exactly like most general tor circuits up till the end of the circuit construction sequence. 2) Number of incoming and outgoing cells The USENIX paper uses the amount of incoming and outgoing cells to distinguish circuit types. For example, client-side introduction circuits have the same amount of incoming and outgoing cells, whereas client-side rendezvous circuits have more incoming than outgoing cells. We use WTF-PAD to destroy this feature by changing the number of cells sent in introduction circuits. We leave rendezvous circuits as is, since the actual rendezvous traffic flow usually resembles well normal Tor circuits. 3) Duration of Activity ("DoA") The USENIX paper uses the period of time during which circuits send and receive cells to distinguish circuit types. For example, client-side introduction circuits are really short lived, wheras service-side introduction circuits are very long lived. OTOH, rendezvous circuits have the same median lifetime as general Tor circuits which is 10 minutes. We use WTF-PAD to destroy this feature of client-side introduction circuits by setting a special WTF-PAD option, which keeps the circuits open for 10 minutes completely mimicking the DoA of general Tor circuits. 4.1. A dive into general circuit construction sequences [CIRCCONSTRUCTION] In this section we give an overview of how circuit construction looks like to a network or guard-level adversary. We use this knowledge to make the right padding machines that can make intro and rend circuits look like these general circuits. In particular, most general Tor circuits used to surf the web or download directory information, start with the following 6-cell relay cell sequence (cells surrounded in [brackets] are outgoing, the others are incoming): [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [BEGIN] -> CONNECTED When this is done, the client has established a 3-hop circuit and also opened a stream to the other end. Usually after this comes a series of DATA cell that either fetches pages, establishes an SSL connection or fetches directory information: [DATA] -> [DATA] -> DATA -> DATA The above stream of 10 relay cells defines the grand majority of general circuits that come out of Tor browser during our testing, and it's what we are gonna use to make introduction and rednezvous circuits blend in. Please note that in this section we only investigate relay cells and not connection-level cells like CREATE/CREATED or AUTHENTICATE/etc. that are used during the link-layer handshake. The rationale is that connection-level cells depend on the type of guard used and are not an effective fingerprint for a network/guard-level adversary. 5. WTF-PAD machines For the purposes of this proposal we will make use of four WTF-PAD machines as follows: - Client-side introduction circuit hiding machine (origin-side) - Client-side introduction circuit hiding machine (relay-side) - Client-side rendezvous circuit hiding machine (origin-side) - Client-side rendezvous circuit hiding machine (relay-side) In the following sections we will analyze these machines. 5.1. Client-side introduction circuit hiding machines [INTRO_CIRC_HIDING] These two machines are meant to hide client-side introduction circuits. The origin-side machine sits on the client and sends padding towards the introduction circuit, whereas the relay-side machine sits on the middle-hop (second hop of the circuit) and sends padding towards the client. The padding from the origin-side machine terminates at the middle-hop and does not get forwarded to the actual introduction point. Both of these machines only get activated for introduction circuits, and only after an INTRODUCE1 cell has been sent out. This means that before the machine gets activated our cell flow looks like this: [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [INTRODUCE1] Comparing the above with section [CIRCCONSTRUCTION], we see that the above cell sequence matches the one from general circuits up to the first 7 cells. However, in normal introduction circuits this is followed by an INTRODUCE_ACK and then the circuit gets teared down, which does not match the sequence from [CIRCCONSTRUCTION]. Hence when our machine is used, after sending an [INTRODUCE1] cell, we also send a [PADDING_NEGOTIATE] cell, which gets answered by a PADDING_NEGOTIATED cell and an INTRODUCE_ACKED cell. This makes us match the [CIRCCONSTRUCTION] sequence up to the first 10 cells. After that, we continue sending padding from the relay-side machine so as to fake a directory download, or an SSL connection setup. We also want to continue sending padding so that the connection stays up longer to destroy the "Duration of Activity" fingerprint. To calculate the padding overhead, we see that the origin-side machine just sends a single [PADDING_NEGOATIATE] cell, wheras the origin-side machine sends a PADDING_NEGOTIATED cell and between 7 to 10 DROP cells. This means that the average overhead of this machine is 11 padding cells. In terms of WTF-PAD terminology, these machines have three states (START, OBF, END). They move from the START to OBF state when the first non-padding cell is received on the circuit, and they stay in the OBF state until all the padding gets depleted. The OBF state is controlled by a histogram which specifies the parameters described in the paragraphs above. After all the padding finishes, it moves to END state. We also set a special WTF-PAD flag which keeps the circuit open even after the introduction is performed. In particular, with this feature the circuit will stay alive for the same durations as normal web circuits before they expire (usually 10 minutes). 5.2. Client-side rendezvous circuit hiding machines The rendezvous circuit machines apply on client-side rendezvous circuits and only after the rendezvous point has been established (REND_ESTABLISHED has been received). Up to that point, the following cell sequence has been observed on the circuit: [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [ESTABLISH_REND] -> REND_ESTABLISHED which matches the general circuit construction sequence [CIRCCONSTRUCTION] up to the first 6 cells. However after that, normal rendezvous circuits receive a RENDEZVOUS2 cell followed by a [BEGIN] and a CONNECTED, which does not fit the circuit construction sequence we are trying to imitate. Hence our machine gets activated right after REND_ESTABLISHED is received, and continues by sending a [PADDING_NEGOTIATE] and a [DROP] cell, before receiving a PADDING_NEGOTIATED and a DROP cell, effectively blending into the general circuit construction sequence on the first 10 cells. After that our machine gets deactivated, and we let the actual rendezvous circuit shape the traffic flow. Since rendezvous circuits usually immitate general circuits (their purpose is to surf the web), we can expect that they will look alike. In terms of overhead, this machine is quite light. Both sides send 2 padding cells, for a total of 4 padding cells. 6. Overhead analysis Given the parameters above, intro circuit machines have an overhead of 11 padding cells, and rendezvous circuit machines have an overhead of 4 cpadding ells. . This means that for every intro and rendezvous circuit there will be an overhead of 15 padding cells in average, which is about 7.5kb. In the PrivCount paper [1] we learn that the Tor network sees about 12 million successful descriptor fetches per day. We can use this figure to assume that the Tor network also sees about 12 million intro and rendezvous circuits per day. Given the 7.5kb overhead of each of these circuits, we get that our padding machines infer an additional 94GB overhead per day on the network, which is about 3.9GB per hour. XXX Isn't this kinda intense????? Using the graphs from metrics we see that the Tor network has total capacity of 300 Gbit/s which is about 135000GB per hour, so 3.9GB per hour is not that much, but still... 7. Discussion 7.1. Alternative approaches These machines try to hide onion service client-side circuits by obfuscating their looks. This is a reasonable approach, but if the resulting circuits look unlike any other Tor circuits, they would still be fingerprintable just by that fact. Another approach we could take is make normal client circuits look like onion service circuits, or just make normal clients establish fake onion service circuits periodically. The hope here is that the adversary won't be able to distinguish fake onion service circuits from real ones. This approach has not been taken yet, mainly because it requires additional WTF-PAD features and poses greater overhead risks. 7.2. Future work As discussed in [SCOPE], this proposal only aims to hide some very specific features of client-side onion service circuits. There is lots of work to be done here to see what other features can be used to distinguish such circuits, and also what other classifiers can be built using deep learning and whatnot. --- [0]: https://www.usenix.org/node/190967 https://blog.torproject.org/technical-summary-usenix-fingerprinting-paper [1]: "Understanding Tor Usage with Privacy-Preserving Measurement" by Akshaya Mani, T Wilson-Brown, Rob Jansen, Aaron Johnson, and Micah Sherr In Proceedings of the Internet Measurement Conference 2018 (IMC 2018).

4 5

Next Network Team Meeting Times
by teor 23 May '19

23 May '19

Hi, Monday 27 May is a US public holiday, so we've changed the next two meeting times: May schedule: * Tuesday 28 May at 2300 UTC (Monday is a US public holiday) June schedule: * Monday 3 June at 1700 UTC (The 28 May meeting was at the patch party time) We're back to our regular schedule after that: * Monday 10 June at 1700 UTC * Monday 17 June at 1700 UTC * Monday 24 June at 1700 UTC We meet in the #tor-meeting channel on irc.oftc.net. T -- teor ----------------------------------------------------------------------

1 0

TrackTor - GUI Based Implementation for Monitoring Tor
by Harsh Gandhi 21 May '19

21 May '19

Hello, We are under-graduate students from Malaviya National Institute of Technology currently pursuing Computer Science & Engineering. We have developed a GUI Based Tool for monitoring TOR (inspired by Nyx). We have packaged and uploaded the same on, PyPI - https://pypi.org/project/TrackTor/ Please do give it a try and suggest for improvements. Also, please let us know on how can we incorporate/integrate this with The Tor Project? Thank You! Cheers! -- Regards, Harsh Rajiv Gandhi B.Tech Final Year Department of Computer Science and Engineering Malaviya National Institute of Technology Jaipur - 302017, Rajasthan +91-9983543656

2 1

Network Health Monitoring
by Iain Learmonth 21 May '19

21 May '19

Hi All, I'm working on #28322 to improve the monitoring of Tor Metrics services, but this also has the side effect of monitoring network health. For example, we'd like to know when Onionoo messes up and starts reporting zero relays, but we also get to learn for free in the same check how many relays we have and alert if that number does something weird. What would be the most useful checks to add here? * Range of expected total relays * Range of expected relays with Guard flag * Range of expected relays with Exit flag * Range of expected consensus weight in each position Each one of these is basically an if statement in the script so I'm happy to add these. I can do this by trial and error but if someone has already thought about it then please reply or comment on the ticket. Thanks, Iain.

3 2

Submit to FOCI '19: deadline in ten days
by Roger Dingledine 13 May '19

13 May '19

The submission deadline for this year's Free and Open Communications on the Internet (FOCI) workshop is coming up in ten days. The workshop will be co-located with Usenix Security in Santa Clara in August. https://www.usenix.org/conference/foci19 Here's the blurb: "The Free and Open Communications on the Internet (FOCI) workshop, now in its 9th year, is a vibrant, peer-reviewed event dedicated to bringing together researchers and practitioners from technology, law, and policy who are working on a wide variety of censorship-related topics. This includes direct censorship mechanisms---both technical and legal---as well as indirect methods of censorship through coordinated harassment campaigns and online astroturfing that may be used to drown out and/or chill free expression." We encouraged Susan and Michael, the chairs this year, to make it their own by adding the areas they find most fascinating, and they picked the harassment and astroturfing angle, which I agree needs much more attention from both the research and practitioner worlds. So, you should submit your workshop paper! And even if you don't submit, you should come to the workshop. There will be a bunch of great censorship circumvention and censorship measurement people there, including as usual some Tor people. --Roger

1 0

Re: [tor-dev] tor-dev Digest, Vol 100, Issue 8
by amar memisevic 08 May '19

08 May '19

1 0

My implementation of hash for controller password - torhash
by Damon (TheDcoder) 08 May '19

08 May '19

Hello everyone! I have written a very simple tool called torhash <https://github.com/TheDcoder/torhash> to generate hashed passwords/strings according to the instructions in control spec to authenticate with the controller interface (TC?). I did not actually study the S2K algorithm since I found it hard to understand RFC 2440, I studied source code and bit by bit I figured out what was happening behind the scenes! The reason I did this is that I am working on another program called ProxAllium <https://proxallium.dtw.tools/> which acts as a graphical user interface for Tor, I am currently in the process of rewriting <https://github.com/DcodingTheWeb/ProxAllium/tree/next-gen> it in C to make it cross-platform (along with a few other reasons...). I hit a roadblock while I was implementing support for interacting with the controller interface, I had to make a choice between calling Tor to generate the hashed password or to hash the password in the program itself. I felt like hashing the password in the program itself was the right choice, I had a few other weak reasons to not call Tor for hashing the password but my gut was the main motivator behind this choice. I created torhash (apologies about the bad name choice) as a proof-of-concept and to improve my general programming skills, I had no prior experience working with cryptography or hash functions on this level, so I went with the simplest library I could find for hashing the data. I could have gone with OpenSSL, as I believe that it is the de-facto cross-platform standard for cryptography and cryptographic hashing, I am currently looking into using it, but I am not yet sure if this is a good idea. I would be grateful if some of you can take out some time to have a look, I am very excited to hear your opinions and any advice that you may have to help me improve, the code itself is very simple and short (114 lines of code). Pardon any mistakes or bad code that I may have written, I have only begun programming relatively recently and my experience with low-level development (with C) is very recent. Thank you for reading and for the input in advance! Best Regards, Damon H. (TheDcoder)

2 1

Solving World's Tor Users Being Blocked by Websites (was: Tor exit bridges)
by grarpamp 08 May '19

08 May '19

On 5/7/19, nusenu <nusenu-lists(a)riseup.net> wrote: > > juanjo: >> Tor relays are public and easily blocked by IP. To connect to Tor >> network users where Tor is censored have to use bridges and even PTs. >> But, what happens on the exit? Many websites block Tor IPs so using >> it to access "clearweb" is not possible. Should we allow and start >> using "exit bridges"? In I2P we have not this problem since there is >> no central IP list of relays. > > there is no need to extend to one more hope to achieve this > > https://lists.torproject.org/pipermail/tor-dev/2018-March/013036.html > > https://lists.torproject.org/pipermail/tor-relays/2019-May/017273.html It's possible to augment such outbound solution offerings even further by running an OpenVPN termination service so users can transport UDP between clearnet as well. VPNGate.net project has an idea there too. Even large regional IPv6 pools could be bought and shared by operators and rotated through. More tor relay operators should consider some of the above options, whether as a requested "bridge" service mechanism, or listed in the consensus "contact" field, or as more of a standalone VPNGate support, or "ExitGate" project sort of arrangement. Using only tor right now, a user needs to use a clearnet service that does not scrape consensus, or one not fronted by services doing similar to CloudFlare's spiteful default tor blocking policy, or find a lucky exit within whatever geolocation game the clearnet service uses, or get lucky through traditional vpn or proxy. But those are only fun statistical hacks, not real long term solutions to the underlying problem. It's unfortunate that such braindead blocking, stupid policy regimes, sites refusal to developing creative solutions [1] for so many world's users legitimate privacy, info risk, anonymity needs... often results in users accounts being locked out and escalated into forcing disclosure of users private info and ID to sites to unlock them, thus exposing users to ongoing long term fraud, cost, and stress when that info (in most cases truly unnecessary to collect) is eventually shared misused and stolen by both sites and criminals... or outright auto deletion of user's valued account, built up social networks, etc... all for doing nothing wrong, and harming no one or thing. Death by DriveByExit :( And really shameful to deny world's users the right to simply read a website, be it social, commercial, information, etc or even sadly their own tax-theft funded governmental public sites doing this blocking too. There are some related projects, best practice, as well... https://trac.torproject.org/projects/tor/wiki/org/projects/WeSupportTor https://trac.torproject.org/projects/tor/wiki/org/projects/DontBlockMe https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-access Positive outreach and direct engagement by Tor community is key here, and perhaps not enough of that is happening, at least not publicly. It's a big enough issue that it really needs a dedicated, active, allied, and even funded subproject... a MegaProject that needs to happen. [1] Such as forfeitable cryptocurrency and mailed-in cash deposits refundable in time, increasing account priviledges and features based on account age and activity, community moderation and behaviour support within the sites, opensource third party tracking-free local SecurImage style captcha throughout a sites features, privacy preserving non-SMS non-Google/Apple pure TOTP authenticator protocols, PGP recovery, letting users simply *read* websites without any hindrance, while utilizing these methods only for *write* operations, etc and so many more ways you can envision... Cc'd for awareness and inclusion. *Please remove tor-dev and tor-relays, and move this to tor-talk or tor-access for ongoing discussion and progress. Thanks.

1 0

Controller: text connection vs SNMP
by grarpamp 07 May '19

07 May '19

Speaking of MIBs and management, was SNMP ever seriously looked at back when desire for a control mechanism evolved? If I recall, agent libs and clients weren't wished as middleware, thus demurring to a text connection shell interface. Though commercial routers have both, the shell connection is usually richer and more capable, but harder to parse (Juniper being more programmatic), and requires downstream development to speak to each vendor's shell in automated fashion.

1 0

Tor exit bridges
by juanjo 07 May '19

07 May '19

Tor relays are public and easily blocked by IP. To connect to Tor network users where Tor is censored have to use bridges and even PTs. But, what happens on the exit? Many websites block Tor IPs so using it to access "clearweb" is not possible. Should we allow and start using "exit bridges"? In I2P we have not this problem since there is no central IP list of relays.

3 2

[RFC] control-spec: Specify add/remove/view client auth commands (client-side).
by George Kadianakis 07 May '19

07 May '19

Hello list, here is a control spec patch for adding v3 client auth commands to add/remove/view clients from the client-side (so Tor Browser -> Tor): https://github.com/torproject/torspec/pull/81/commits/3a26880e80617210b4729… I'm currently unhappy with the naming of those commands, and in general with how easy it is to confuse them with the (non-existent) service-side commands. I'm wondering how to name them better so that when we add the respective service-side commands (at some point we should) there is no confusion. Let me know what you think! Thanks! :)

6 9

Fuck You Van Gegel
by Mark Kepler 07 May '19

07 May '19

Fuck You Van Gegel, you dumb fuck. You think you can post stupid shit to our lists? I'm going to stop you from postiing you dumb motherfucker. I'm going to eat you alive. You're a dumb cocksucking faggot and I enjoyed fucking your mother in her face. I yelled FACE FUCK while I was doing it BITCH. You DONT KNOW SHIT AND YOU ANNOY AND HARRASS PEOPLE WITH YOUR BULLSHIT. YOU WILL STOP POSTING HERE YOU DUMB MOTHER FUCKER. WE WILL GET YOU. WE WILL FIND YOU. WE WILL KILL YOU. LOLOLOLOL.

2 1

(no subject)
by ttoto Q 04 May '19

04 May '19

confirmar 0ef436bfd7e6ffc09e94bdfa53554c4eeb67bd72

1 0

[GSoD] Project 4: Help us write architecture documentation for Tor
by Pranam Lashkari 02 May '19

02 May '19

Hello, I want to participate in Google Season of Docs as a technical writer. I have closely looked at the ideas available on the ideas page and found project 4 interesting. I have also skimmed through the existing documentation for the same. What are the further procedures? (E.g: In GSoC most of the organizations make students take competency test or make them contribute by solving small bugs or patches) Do we have something similar in Tor for the GSoD? *About me:* I am a final year computer engineering student. I have been involved in open source since last two years. I have been a GSoC 2018 student with Boost C++ Libraries and Google Code-In mentor with KDE and JBoss. Apart from that, I would have been Admin of Boost C++ Library in GSoD but unfortunately, Boost isn't a part of GSoD this year due to limited slots for organizations in GSoD's pilot year. I initiated a technical newsletter at my college where I generated content for 1 year along with leading the committee for the same. This initiative involved writing tutorials for the new aspirants, reviewing trending technologies and documenting college projects. Thank you, Pranam Lashkari

1 0

Denial of service defences for onion services
by George Kadianakis 30 Apr '19

30 Apr '19

Hello list, This is a thread summarizing and brainstorming various defences about denial of service defences for onion services after an in-depth discussion with David Goulet. We've been thinking about denial of service defences for onion services lately. This has been a recurrent topic that has been creeping up every once in a while: Last time we had to tackle this issue it was back in early 2018 when we had to design a DoS mitigation subsystem because the network was crumbling down (https://trac.torproject.org/projects/tor/ticket/24902) Unfortunately, while the DoS mitigation subsystem improved the health of the network and stopped the DoS attacks back then, it did not address the total space of possible attacks, and onion services and the network is still open to various attacks. The main DoS attack right now is the naive attack of flooding the service with too many introduction requests, and this is the attack that this post is gonna be dealing with. We don't like DoS attacks because they cause two issues to Tor: a) They damage the health of the Tor network impacting every user b) They kill availability of legitimate onion services. In this thread we will handle these two issues independently, as there is no single solution that improves both areas at once. We have some pretty good ideas on (a), but we would appreciate ideas on (b), so feel free to give us your input. == a) Minimizing the damage to the network caused by DoS attacks: Most of the damage caused during DoS attacks is from the circuits created by the attacker to introduce/rendezvous to the victim onion service, and also by the circuits created by the victim onion service as it tries to rendezvous with all those clients. An attacker can literally create tens of thousands of introduction circuits in less than a minute, which get amplified by the service launching that many rendezvous circuits. Not good. Here are a few ways to reduce the damage to the network: == 1) Rate limiting introduction circuits There should be a way to rate-limit introductions so that services do not get overwhelmed. There are various places where we can rate-limit: we could rate-limit on the guard-layer, or on the intro-point layer or on the service-layer. We have already attempted at rate-limiting on the guard-layer with #24902, but it's hard to go deeper there because the guard does not know if the circuit is a DoS attacker, or a busy onion service, or 150 Tor users in an airport. We also think that rate-limiting on the service-layer won't do much good since that's too far down the circuit, and we are trying to reduce the operations it has to do so that it doesn't get overwhelmed (see #15463 for various queue-management approaches for rate-limiting on the service side). So we've been thinking of rate-limiting on the introduction point layer, since it's a nice soaking point that does not do much right now. See #15516 (comment 28) for a concrete proposal by arma which results in far less damage to the network (since evil traffic does not get carried through to the service-side introduction circuit, and no extra rendezvous circuits get launched), and also a swifter way for legit clients to know that an onion-service circuit won't work. == 2) Stop needless circuit rotation on service-side Right now, services will rotate their introduction circuits after a certain number of introductions (#26294). This means that during an attack, the service not only needs to handle thousands of fake introduction circuits, but also continuously tear down and recreate introduction circuits and publish new descriptors. See comment 8 on that ticket for a short-term proposal on how to improve the situation here, by not continuously rotating introduction points. == 3) Optimize CPU performance on the service-side Right now, onion services during an attack are actually CPU bound. See #30221 for various improvements we can do to improve the performance of services. However, improving CPU performance might have the opposite effect, since processing cells quicker means that the service will make even more rendezvous circuits. == 4) Make sure attackers don't take shortcuts around the protocol We should make sure that attackers don't take shortcuts around the Tor protocol to launch their attacks. Examples here involve requiring a proof-of-rendezvous from clients (#25066), and not allowing single-hop proxies to do introductions (#22689). The above suggestions (maybe in priority order) are ways we can improve the damage dealt to the network by DoS attackers. But that still does not make DoS attacks less effective. So here follows the section about improving service availability: == b) Improve service availability during DoS attacks Unfortunately, it's really hard to accurately stop DoS attacks in the Tor protocol. There is just no good way to distinguish between innocent clients trying to access content, and a bad actor trying to disable an onion service. Here is the main way we've thought of addressing this issue: == 1) Binding the application-layer with the Tor introduction-layer We think that the Tor protocol layer might not be the right place for handling DoS attacks. There are literally million-dollar companies trying hard to tackle this issue on the application-layer, where it's easier since you can do machine learning, give out captchas, zone out users, etc. And that's why we think that the solution to this issue lies on the application-layer and not on the Tor protocol layer. In particular, a plausible solution here might involve for the client to embed application-layer information (e.g. a username/password) in its INTRODUCE1 cell, which then gets passed to the service. The service, can then check whether the given username/password should be allowed to connect (see "rendezvous approver" concept at #16059), and allow or reject the connection as it wishes. This way onion service operators can have complicated application-layer software that analyzes the activity of users and decide whether users should be allowed in or not (based on the number of introductions, or their application-layer (web) activity). +===========================================+ | Tor network | +===========================================+ ^ ^ | +-----+ | +-------->| Tor |-------------------+ INTRO2 | HS | rendezvous circuit with +-----+ only if approved user/pass ^ | | v +----------+ +-------+ |Rendezvous|<------->|sqlite?| |approver | +-------+ +----------+ We think that this is a solution that could allow onion services to continue existing under high-load scenarios, since no rendezvous circuits would be established during DoS scenarios (and we know that rendezvous circuits is what causes the most CPU/network/availability damage). However, this is a very complicated solution from an engineering perspective given that it requires changes on the client-side (to enhance INTRO1 cells with application-layer data), and also involves various enhancements on the service-side (various control port commands to interact with the (nonexistent) "rendezvous approver" software, which in turn needs to interact with other application-layer software (e.g. sql databases to manage membership). There is also serious UX concerns with how this would look like on the client-side? Also, how does this interact with client auth? And how does this interact with intro-point-level rate limiting proposed above (onions should be given the option to disable intro-layer rate limiting)? How is this related to #17254? All in all, we feel like we have pretty good options for reducing the damage that DoS attacks cause on our network, but we are still lacking easy and practical solutions for ensuring availability of onion services that are under DoS. For the next months, we plan to focus on reducing the damage on the network, since the damage on the network has a cummulative effect as circuits fail and get endlessly retried, where nothing ends up working right. At the same time, we will be thinking of good solutions for keeping a high availability on services that receive DoS attacks. We would love your feedback and suggestions. Thanks!

1 0

Proposing sbws changes
by teor 24 Apr '19

24 Apr '19

Hi all, We finished our first working version of sbws in March, and deployed it to a directory authority. We're now working on deploying it to a few more directory authorities: https://trac.torproject.org/projects/tor/ticket/29290 We're also working on archiving and analysing the bandwidth files produced by sbws and Torflow: https://trac.torproject.org/projects/tor/ticket/21378 During this work, we've discovered some missing sbws features: https://trac.torproject.org/projects/tor/ticket/30255 We need a better process for proposing and reviewing sbws changes. At the moment, I am spending a lot of time reviewing and designing sbws changes. And that's not sustainable. We need a process that works when I go on leave, or get busy with other tasks. I suggest that we use the tor proposals process: https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt We can submit small changes as diffs to the bandwidth file spec: https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt But large changes, controversial changes, and changes with multiple competing options should have their own proposal. Then, once we decide what to do, we can integrate those changes into the spec. T -- teor ----------------------------------------------------------------------

1 1

PrivCount Status
by teor 24 Apr '19

24 Apr '19

Hi, Nick asked me to send a status email about PrivCount, before I go on leave for a few weeks. Plan We want to add the following counters to a PrivCount Proof of Concept: * check counters (zero, relay count, time in seconds) * consumed bandwidth Nick also suggested adding connection counts. That seems like a good counter, but we want to make sure we do bandwidth in the first release, because it's a high-risk statistic. Status In March and April, I deferred PrivCount tasks to work on chutney for one of our other sponsors. I also delayed these tasks, because I was waiting for #29017 and #29018 to merge: * #29017 PaddingStatistics should be disabled when ExtraInfoStatistics is 0 * #29018 Make all statistics depend on ExtraInfoStatistics Tickets The top-level ticket is: PrivCount proof of concept with existing statistics https://trac.torproject.org/projects/tor/ticket/27908 I was mainly working on code for these tickets: PrivCount proof of concept: implement check counters https://trac.torproject.org/projects/tor/ticket/29004 PrivCount proof of concept: implement consumed bandwidth counters https://trac.torproject.org/projects/tor/ticket/29005 Make relays report bandwidth usage more often in test networks https://trac.torproject.org/projects/tor/ticket/29019 Code I have incomplete branches for #29004, #29005, and #29019 here: https://github.com/teor2345/tor/tree/ticket29004-wip https://github.com/teor2345/tor/tree/ticket29005 https://github.com/teor2345/tor/tree/ticket29019 I think all the necessary code is present in these branches. (But maybe it's not???) But it needs some cleanup: * rebase on to the current master, * put the commits on the right branches * make sure it does what these tickets say it should do I'm happy to do that after I come back from leave. I am also happy if Nick wants to clean up this code. See also my previous email about BridgeDB and PrivCount. Maybe we can save ourselves some effort by using PrivCount's obfuscation on BridgeDB's statistics. T -- teor ----------------------------------------------------------------------

1 0

Export BridgeDB usage statistics
by Philipp Winter 24 Apr '19

24 Apr '19

Hi Karsten, I'm working on <https://bugs.torproject.org/9316>, which will make BridgeDB export usage statistics. I would like these statistics to be public, privacy-preserving, and -- ideally -- added to Tor Metrics. I wanted to hear your thoughts on 1) what statistics we should collect, 2) how we can collect these statistics safely, and 3) what format these statistics should have. Broadly speaking, these statistics should answer the following questions: * How many requests does BridgeDB see per day? * What obfuscation protocols are the most popular? * What bridge distribution mechanisms are the most popular? * From what countries do we see the most bridge requests? * How many BridgeDB requests fail and succeed, respectively? * How many requests does BridgeDB see from Yahoo/Gmail/Riseup? * How many HTTPS requests are coming from proxies? * How many requests are suspicious, and likely issued by bots? Each request to BridgeDB carries with it some information, which allows us to answer the above questions. I suggest that we collect the following: * The distribution mechanism. Currently, this is HTTPS, email, or Moat. * The requested transport. Currently this is vanilla, fte, obfs3, obfs4, or scramblesuit. * The request's origin. For Moat and HTTPS, it's the two-letter country code, e.g., IT for Italy. For email, it's the user's email domain (Gmail, Yahoo, or Riseup). * Whether the request was successful or unsuccessful, i.e., resulted in BridgeDB handing out bridges or not. * Whether the request was issued by a user or a bot. David suggested heuristics that would allow us to estimate if a request came from a bot: <https://bugs.torproject.org/9316#comment:19> I like these suggestions but I'm not sure yet how to encode them -- it's more complex than a simple binary flag. The combination of these statistics results in ~16,800 buckets (3 mechanisms * 5 transports * ~280 ISO country codes * 2 success states * 2 bot states). We only need to export statistics with non-empty buckets. To protect users whose request is the only one in a given bucket (e.g., there may be only one user in Turkmenistan who successfully requested an FTE bridge over HTTPS on 2019-04-02), we should bin the statistics by rounding them up to the next multiple of, say, 10. We should further export statistics infrequently -- maybe once a day. Here's an example of a simple CSV format that takes into account the above: timestamp,mechanism,transport,country|domain,success,count,origin 1555977600,https,vanilla,it,successful,40,user 1555977600,https,obfs4,ca,unsuccessful,10,user 1555977600,email,vanilla,yahoo.com,successful,50,user ... What are your thoughts? Thanks, Philipp

2 1

Next Network Team Meeting Time
by teor 19 Apr '19

19 Apr '19

Hi, The next network team meeting is at 2300 UTC on Tuesday 23 April. (Our "patch party" and "first meeting of the month" time.) Here is our schedule for the next few months: April schedule: * Tuesday 23 April at 2300 UTC (at the "patch party" time) * Monday 29 April at 1700 UTC May schedule: * Monday 6 May at 1700 UTC (first May meeting, but at the normal time) * Monday 13 May at 1700 UTC * Monday 20 May at 1700 UTC * Monday 27 May at 1700 UTC June schedule: * Tuesday 4 June at 2300 UTC (first meeting of the month) * Monday 10 June at 1700 UTC T -- teor ----------------------------------------------------------------------

3 4