tor-dev May 2020

tor-dev@lists.torproject.org

28 participants
29 discussions

Proposal 315: Updating the list of fields required in directory documents
by Nick Mathewson 11 May '20

11 May '20

Filename: 315-update-dir-required-fields.txt Title: Updating the list of fields required in directory documents Author: Nick Mathewson Created: 23 April 2020 Status: Open 1. Introduction When we add a new field to a directory document, we must at first describe it as "optional", since older Tor implementations will not generate it. When those implementations are obsolete and unsupported, however, we can safely describe those fields as "required", since they are always included in practice. Making fields required is not just a matter of bookkeeping: it helps prevent bugs in two ways. First, it simplifies our code. Second, it makes our code's requirements match our assumptions about the network. Here I'll describe a general policy for making fields required when LTS versions become unsupported, and include a list of fields that should become required today. This document does not require to us to make all optional fields required -- only those which we intend that all Tor instances should always generate and expect. When we speak of making a field "required", we are talking about describing it as "required" in dir-spec.txt, so that any document missing that field is no longer considered well-formed. 2. When fields should become required We have three relevant kinds of directory documents: those generated by relays, those generated by authorities, and those generated by onion services. Relays generate extrainfo documents and routerdesc documents. For these, we can safely make a field required when it is always generated by all relay versions that the authorities allow to join the network. To avoid partitioning, authorities should start requiring the field before any relays or clients do. (If a relay field indicates the presence of a now-required feature, then instead of making the field mandatory, we may change the semantics so that the field is assumed to be present. Later we can remove the option.) Authorities generate authority certificates, votes, consensus documents, and microdescriptors. For these, we can safely make a field required once all authorities are generating it, and we are confident that we do not plan to downgrade those authorities. Onion services generate service descriptors. Because of the risk of partitioning attacks, we should not make features in service descriptors required without a phased process, described in the following section. 2.1. Phased addition of onion service descriptor changes Phase one: we add client and service support for the new field, but have this support disabled by default. By default, services should not generate the new field, and clients should not parse it when it is present. This behavior is controlled by a pair of network parameters. (If the feature is at all complex, the network parameters should describe a _minimum version_ that should enable the feature, so that we can later enable it only in the versions where the feature is not buggy.) During this phase, we can manually override the defaults on particular clients and services to test the new field. Phase two: authorities use the network parameters to enable the client support and the service support. They should only do this once enough clients and services have upgraded to a version that supports the feature. Phase three: once all versions that support the feature are obsolete and unsupported, the feature may be marked as required in the specifications, and the network parameters ignored. Phase four: once all versions that used the network parameters are obsolete and unsupported, authorities may stop including those parameters in their votes. 3. Directory fields that should become required. These fields in router descriptors should become required: * identity-ed25519 * master-key-ed25519 * onion-key-crosscert * ntor-onion-key * ntor-onion-key-crosscert * router-sig-ed25519 * proto These fields in router descriptors should become "assumed present": * hidden-service-dir These fields in extra-info documents should become required: * identity-ed25519 * router-sig-ed25519 The following fields in microdescriptors should become required: * ntor-onion-key The following fields in votes and consensus documents should become required: * pr

3 2

Is anybody using OnionPerf's measurement results in the .tpf format?
by Karsten Loesing 10 May '20

10 May '20

Hello list, if the subject line doesn't make any sense to you, this email is very likely irrelevant for you. But if it does make sense to you and you did use OnionPerf's [0] measurement in the .tpf format [1] in the past and/or plan to use this data in the future, you should comment on ticket #34141 [2] and tell us about your use case, ideally in the next couple of days. For what it's worth, the same measurements data is also available in OnionPerf's JSON format [3], and existing data from past measurements will continue to be available in the .tpf format. It's just that we want to get rid of the .tpf format for new measurements. All the best, Karsten [0] https://metrics.torproject.org/torperf.html [1] https://metrics.torproject.org/collector.html#type-torperf [2] https://trac.torproject.org/projects/tor/ticket/34141 [3] https://metrics.torproject.org/collector.html#type-onionperf

1 0

Example of how a stream of RELAY_DATA cells would work?
by Eli Vakrat 10 May '20

10 May '20

Hi again everyone! It's Eli ... So thanks to Teor and Nick's help, my python client (tor OP) is finally able to successfully establish a three-hop circuit with any TOR relays in the whole public network! Now It's on to the Data Cells... As of writing this, I can send and receive the proper RELAY_BEGIN and RELAY_CONNECTED to and from my exit node, but I'm not quite sure what to do next... Do I just start sending RELAY_DATA cells (where the "data" of the cell is literally the encoded HTTP requests)? I've tried connecting to 'www.facebook.com:443' with the RELAY_BEGIN cells as a test (I do get a Relay Connected Cell so at least I know that part works). After getting back the RELAY_CONNECTED cell, I send a RELAY_DATA cell with the data of the cell being the following 'utf-8' encoded string: * #######this is how i wrote the literal in python#### * *'GET / HTTP/1.1\r\nHost: www.facebook.com <http://www.facebook.com>\r\nUser-Agent: python-requests/2.23.0\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nConnection: keep-alive\r\n\r\n\r\n'.encode() * What I get back is a short couple of bytes: *\x15\x03\x03\x00\x02\x022* I had no idea what this meant but after digging around a bit I found that this seems to be some part of the TLS handshake that is used in HTTPS. So now two questions arise: 1. Is this a good TLS response? What does it mean exactly? 2. Generally speaking, is this how the RELAY_DATA cells are supposed to be sent and received? Just to clarify it would be great if I could get an exact example of how the stream of data should look. For example, if someone could maybe break down the steps of how a basic HTTP GET request would work through a TOR circuit (starting from sending a RELAY_BEGIN cell) that would help me tremendously. Thanks again to everyone who've helped me so far, and thanks in advance to anyone with an answer to any of my questions! Regards, Eli

2 1

Tor Network Expansion Question/Suggestion
by Beecher Bruno 09 May '20

09 May '20

Hello All, I don’t know much in the ways of how the actual coding works, but I’m very familiar with computers. I’m a student in Network Systems Engineering Technology in the USA. After being introduced to Tor several years ago, I loved it. I recently had a potentially good idea in making the Tor network more resilient against tracking/surveillance attempts. My basic understanding is that information from one computer gets transmitted to a node, bounced around between different nodes, and then spit out somewhere else. Or, at least, that’s what it would look like from the outside, making it extremely difficult to pin down the actual origin computer. (Please do forgive me if this is an inaccurate representation). But what about expanding the network significantly, without truly widening the load on all the nodes? My idea was essentially this: an app for mobile devices and/or computers that would ask for consent from the user. Upon consent, that device could essentially fake its identity, so that everyone outside the network thought it was a node? Data that’s actually sent between nodes could just put in a random “fake” node at the beginning and end of a packet so, as far as anyone else knows, that data went through an extra two nodes? Just in case that’s not clear, imagine a Tor node receives packet A in Washington DC. On its complicated, 3 node journey to the end node in Hongkong, random devices that have been consented to be “fake nodes” will have added themselves in. Theoretically, by the time it arrives in Hongkong, this 5 node journey (DC Hongkong and the 3 in between) will look on the outside to be a 6 or 7 node journey. I’m not sure if this is possible, but if it is, I think it could help protect people’s privacy even more. I do apologize for emailing this list, I couldn’t exactly find an “Contact Us” page, probably for good reason. Have a great day! Stay safe out there. Beecher

1 0

My Introduction_GSoC Student
by Hashik Donthineni 07 May '20

07 May '20

Hello everyone! My name is Hashik Donthineni (IRC: HashikD), I am a GSoC 2020 student. I will be working on* Snowflake Proxy on the Android *project with the help of my mentors Cecylia (Cohosh), Phillipp (phw). I am really excited to join the Tor team! Thank you all for giving me this exciting opportunity! Regards, D. Hashik

1 0

Does a design document for the DoS subsystem exist?
by Lennart Oldenburg 07 May '20

07 May '20

Hi all, We are investigating how Tor protects itself against Denial-of-Service (DoS) attacks. So far, it has been difficult to find a comprehensive top-level design document for the DoS subsystem (e.g., a torspec or proposal) that reflects the decisions that lead to the subsystem in its current form. Specifically, we are looking at the DoS mitigation subsystem code for entry guards at src/core/or/dos.{h,c} [1]. We are trying to understand the chosen countermeasures and how the default and current consensus values came to be, e.g., the decision to limit to 3 circuits per second after the initial burst. 1) Could you kindly point us in the right direction if any such document exists? 2) If it does not exist, would you mind briefly explaining how the DoS threshold values (such as DoSCircuitCreationMinConnections, DoSCircuitCreationRate, DoSCircuitCreationBurst, and DoSConnectionMaxConcurrentCount) were chosen? Thank you very much in advance. Kind regards Lennart Oldenburg KU Leuven [1] https://gitweb.torproject.org/tor.git/tree/src/core/or/dos.c

3 4

(No walking onions update for last week)
by Nick Mathewson 04 May '20

04 May '20

Hi all! Sending a short note that I won't be doing a walking onions update from the past week -- my time went to follow-on tasks for personnel transitions, and I didn't make much progress to speak of on the walking onions specs. I hope to get more done this week, and send an update then. -- Nick

1 0

Fwd: Orbot 16.2.0 RC-1 (tor-0.4.2.7)
by Nathan Freitas 04 May '20

04 May '20

Now with integrated MOTE bridge request support, just like on Onion Browser iOS, courtesy of Benjamin Erhart (aka tla). -------- Forwarded Message -------- Subject: Orbot 16.2.0 RC-1 (tor-0.4.2.7) Date: Mon, 4 May 2020 12:03:13 -0400 From: Nathan of Guardian <nathan(a)guardianproject.info> Organization: Guardian Project To: Guardian Dev <guardian-dev(a)lists.mayfirst.org> Orbot 16.2.0 RC-1 (tor-0.4.2.7) Tag: https://gitweb.torproject.org/orbot.git/tag/?h=16.2.0-RC-1-tor-0.4.2.7 APKs: - https://github.com/guardianproject/orbot/releases/tag/16.2.0-RC-1-tor-0.4.2… - Universal: https://guardianproject.info/releases/Orbot-16.2.0-RC-1-tor-0.4.2.7-1-geed7… (.asc) - ARM64: https://guardianproject.info/releases/Orbot-16.2.0-RC-1-tor-0.4.2.7-1-geed7… (.asc) - F-Droid soon... Thanks to the fantastic contributions by @bitmold @tladesignz and @Hashik-Donthineni Highlights Resolved many issues related to startup of Tor and Obfs4/Meek bridges on Android Q/10 VPN fixes resolved through unifying 2 background services (TorVPNService, TorService) into one (OrbotService) Update tor to 0.4.2.7 and obfs4proxy to 0.0.12 latest Brand new "beta" integrated bridge fetch feature through Tor's MOTE service (just like in Tor Browser) Brand new custom bridge configuration, setup UI Zulu language random switch bug FINALLY fixed.... now the language you choose remains! (sorry, Zulu!) and much more... /** 16.2.0-RC-1-tor-0.4.2.7 / 4 May 2020 / 0a3a4f7 **/ 0a3a4f7 (HEAD -> master) update version code to 16202001 a631077 (HEAD -> master, origin/master, origin/HEAD) Merge branch 'tladesignz-master' 875f18a (tladesignz-master) Merge branch 'master' of https://github.com/tladesignz/orbot into tladesignz-master 85e027c update version code cabf328 don't start tun2socks/VPN if it is already running 718bb42 Issue #324: Implemented CustomBridgesActivity analogous to Onion Browser iOS. 12a3f4a (tag: 16.2.0-BETA-4-tor-0.4.2.7) remove TorVpnService from manifest to address #327 crash 22d7ef8 (tag: 16.2.0-BETA-3-tor-0.4.2.7) update to 16201003 22bd248 update binary install scripts, to fix pdnsd install - now pdnsd is packaged as libpdsnd.so to work on newer platforms e93c8bc (tag: 16.2.0-BETA-2-tor-0.4.2.7) update version code to 16201002 d0fec8e update tor and obfs4proxy binary libs to address #326 hopefully 3ac5a70 Issue #309: Activate newly required bridges, fixed accidental reset through Tor status notification. e1425d3 Issue #309: Also disable CAPTCHA solution EditText, as long as there's no CAPTCHA to solve and while letting it check. ff7cbcf Issue #309: Error alert button should say "OK" instead of "Cancel", since there's nothing to cancel, really, just to acknowledge the error. 54f5f31 Issue #309: Hide refresh option menu item instead of disable, because Android doesn't visualize that adequately. Additionally: Fix issue where you couldn't refresh after a network error. 3bfaa8a Issue #309: Fixed potential crash, when activity went away. c41d453 (public/master) fix unneeded includes 4f4300a (tag: 16.2.0-BETA-1A-tor-0.4.2.7, tag: 16.2.0-BETA-1-tor-0.4.2.7, ghdev/master) update version to 16201001 7d7b2e9 remove app updater code to address concerns in #323 ec47151 major VPN refactor with Android Q updates for #263 #261 #151 #316 and #303 - integrate TorVPNService directly into OrbotService, so just one service now - removed VPNEnableActivity, and just have VPN activated by service now - changes address start on boot with VPN enable - also improvements to managing PDNSD daemon d64b4d0 (tag: 16.1.5-BETA-2-tor-0.4.2.7) update version code to 16150001 d5bc374 update to SDK 29 919c211 improve pdnsd pid checking e78c27b remove unneeded commands in tor config and startup 5cd6cc8 update tor to 0.4.2.7 785fa8f Merge branch 'master' of github.com:guardianproject/orbot 93a0786 Merge pull request #322 from bitmold/AboutDialogCrashFix b24750e Fixes #321 IlleglaStateException on about dialog 2e6c9b1 (tag: 16.1.5-BETA-1-tor-0.4.2.5-rc) small tweaks to request bridge strings 3c80df0 Merge branch 'bitmold-compile_erorr+refactor' 08de553 (bitmold-compile_erorr+refactor) Merge branch 'compile_erorr+refactor' of https://github.com/bitmold/orbot into bitmold-compile_erorr+refactor df847ff Merge branch 'tladesignz-master' b2646a3 update AndroidPT to latest 1.0.8 with fixes for obfs4 and meek on Android 10 feedb3b fix string variable values 155980f Change from using String resources for a bundle key in Onboarding ec0ad26 Fixes compile error on master branch right now f2c8473 Merge branch 'master' of https://github.com/tladesignz/orbot into tladesignz-master 732c153 Merge branch 'master' of https://github.com/guardianproject/orbot 09ded59 (githubgp/master) Merge pull request #311 from bitmold/email_bridges_fix b1049ca Merge branch 'master' of https://github.com/guardianproject/orbot b9804c1 Merge pull request #305 from Hashik-Donthineni/AppIntroOrientationFix 410ae03 tweaks to app data storage and control port interaction - in some cases, Orbot connection to local control port can hang. Make changes to address that. 19d5054 Color indeterminate ProgressBar. 1749167 Fixed behaviour on device turn. f94931e Don't allow refresh button to trigger while request ongoing. 7a9b9d1 Adapted to naming convention of project. 964c311 Fixed MoatActivity startup when Tor is not running. Reset old bridge configuration, when not completed. 5c99859 Finish BridgeWizardActivity on successful MOAT. a34ee22 Improved UI: show progress spinner, start request on keyboard enter. a46e463 Updated Gradle to latest version. c026e20 Check OrbotService status, start Tor, if down, switch to Meek, when started, fetch CAPTCHA, as soon as done with that. Proxy Volley correctly. Improved option menu handling. Not working, yet: Tor doesn't come up. Why? e7cfe46 Added first stab at a MoatActivity. Doesn't change bridges automatically, yet. Also, Volley needs to be proxied. 469d4cf Fixed most warnings and errors in OrbotMainActivity. 3eb76e6 Updated Gradle. 4283221 Updated BUILD info. 446dfa6 Fixes bugs in #289 pertaining to parsing bridges 8627989 Merge pull request #310 from bitmold/zulu_context_menu 29541f3 Fixes #300 Where Locale is set to Zulu when settings are opened bfbb85b Changed variable names for better understanding a09b4eb Fixed Unused Imports f4580cf Added comments for better understanding 6c09f67 Extracted String Resources ee3e054 Fixed blank screen when orintation changed in AppIntro 8a3727a Merge pull request #301 from PLNech/patch-1 0dcba0d fix FAQ URL in README 73b0b0d handle NPE since node is not yet set Assets 6 Orbot-16.2.0-RC-1-tor-0.4.2.7-1-geed732a3-fullperm-arm64-v8a-release.apk 11.2 MB Orbot-16.2.0-RC-1-tor-0.4.2.7-1-geed732a3-fullperm-arm64-v8a-release.apk.asc 833 Bytes Orbot-16.2.0-RC-1-tor-0.4.2.7-1-geed732a3-fullperm-universal-release.apk 32.2 MB Orbot-16.2.0-RC-1-tor-0.4.2.7-1-geed732a3-fullperm-universal-release.apk.asc 833 Bytes Source code (zip) Source code (tar.gz)

1 0

Proposal Idea: IPv6-Only Exit Relays
by teor 01 May '20

01 May '20

Hi all, The network team is making it easier to set up a dual-stack Tor relay. We're currently working on: * IPv6 reachability self-tests * IPv6 address auto-detection * IPv6 relay statistics We're also thinking about the next IPv6 project. One possibility is adding IPv6-only exits to the Tor network. We'd need to solve two technical problems: 1. stop requiring IPv4 in the consensus and circuit code 2. avoiding delays when using an IPv6-only exit for an IPv4-only site And one deployment problem: 3. Get more dual-stack middle relays (50% - 75%) Here's a quick sketch of a solution to the IPv4-only site issue: Clients open two exit streams for every site. One of those streams must use an exit with IPv4 support. The client uses whichever stream succeeds first. Just like the "happy eyeballs" protocol, there is a delay between launching the two streams: https://www.rfc-editor.org/rfc/rfc8305.txt Here are some benefits of a universal change: * code and protocol consistency * makes traffic analysis harder * also helps with other exit failures, for a better user experience Here are some drawbacks: * extra load We can change the delay to manage the tradeoff between load, user experience, and traffic analysis resistance. Making the delay longer reduces the load, but makes the user experience worse. Traffic analysis resistance is a bit more complex. Consistency across different clients is important, but we also don't want to create obvious traffic patterns. So there are also some benefits to randomisation. If I get time, I'd like to turn these ideas into a proposal. T -- teor ----------------------------------------------------------------------

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev May 2020