- tor-dev - lists.torproject.org

Deprecating Tor Protocol Versions
by teor 15 May '20

15 May '20

Hi all, Nick and I were talking about how we remove legacy features in tor, and their corresponding subprotocol versions. Here is a list of the current subprotocol versions: https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n2049 Here's a recent protocol version proposal, which deals with recommending and requiring new features: https://gitweb.torproject.org/torspec.git/tree/proposals/303-protover-remov… But we don't have a similar proposal for removing support for older protocol versions from the tor codebase. For an example of what that proposal could look like, see our proposal for deprecating consensus methods: https://gitweb.torproject.org/torspec.git/tree/proposals/290-deprecate-cons… Here's the original conversation Nick and I had: https://github.com/torproject/tor/pull/1874#discussion_r423713579 But after reading our consensus methods deprecation proposal, I've changed my mind. I think that we should check for "protocol N, and any later version" by default. That's what we do for consensus methods, and it seems to work well. We can drop the earliest consensus methods, and recent tor versions just keep working. If we need an incompatible change, we can make it another protocol version, and recommend then require support for it. So here's an edited version of my notes on that ticket: There are a few instances of ">=" and "=" confusion in protocol versions. We should try to fix them all. It only matters when we remove protocol versions. We haven't really specified, tested, or exercised this functionality in practice. And so our reviewers lack experience. (And when we did discover a need for it with NSS and LinkAuth, it was more complicated than we expected.) I'd like to see a proposal that tells us how to check future protocol versions as they are added. Along with a migration plan for disabling protocol versions. So let's also open a ticket to check for "any future version". We should replace all "=" checks with ">=". Let's make sure we check all the places where we use protocol versions, even if they don't have a summary flag. Overall, I think it would be helpful if future protocol versions were orthogonal. Or if they depend on earlier features, that dependency should be clearly documented. (For example, Relay=3 IPv6 extends depends on Relay=2 EXTEND2 cells. So if we were checking EXTEND2 cell support, it would be Relay=2 or Relay=3.) T -- teor ----------------------------------------------------------------------

2 2

Re: [tor-dev] Chutney code refactoring
by c 15 May '20

15 May '20

On Fri, 17 Apr 2020 18:01:42 -0400 Nick Mathewson <nickm(a)freehaven.net> wrote: > If you want to work on this it would be helpful to maybe start by > listing (here or elsewhere) some places where you *don't* feel like > you could (or would want to) write documentation: those would be a > good target for devs who _have_ worked on Chutney before. I came across Node.specialize() which does not seem to be called elsewhere, and I cannot guess at its purpose. So, if anyone knows off the top of their head what this is for (not what it does, because it's quite obvious from the code itself) then I'd greatly appreciate and I will document its purpose accordingly. It is one of the functions that is listed as "to be called by the user". Other than that I added docstrings where they were missing in TorNet (useful both for Python's on-line help() and for checking whether code agrees with intent) and made mental note of some areas I would like to improve in the code (changing function names to better align with what they actually do, figure out if some longer functions can be split into more atomical and easier-to-digest parts, ...). Caitlin

3 3

woswos - GSoC 2020
by Barkin Simsek 12 May '20

12 May '20

Hi everyone, I'm Barkin (woswos in IRC), and I study Computer Engineering at New York University Abu Dhabi. This summer, I will be working on the "Cloudflare CAPTCHA Monitoring" project as a part of the GSoC program with my mentors Georg and Roger. I’m very excited about working on this project! The Cloudflare CAPTCHA Monitoring project aims to track how often Cloudflare fronted webpages return CAPTCHAs to Tor clients. The project aims to achieve this by fetching webpages via both Tor and other mainstream web browsers and comparing the results. The tests are repeated periodically to find the patterns over time. Collected metadata, metrics, and results are analyzed and displayed on a dashboard to understand how Cloudflare manipulates internet traffic and affects people's access to the internet. I will be creating a bunch of trac tickets to record my progress and to get feedback from the community. Until then, you can leave your comments and suggestions under the ticket #33010 You can find more detailed information about the project on this wiki page: https://trac.torproject.org/projects/tor/wiki/doc/CAPTCHAMonitor This wiki page will also contain the links to the trac tickets I mentioned. I try to place all sorts of information on the wiki page to make it the "go-to place" to get information about my project. Best, Barkin

1 0

Proposal 318: Limit protover values to 0-63
by Nick Mathewson 12 May '20

12 May '20

``` Filename: 318-limit-protovers.md Title: Limit protover values to 0-63. Author: Nick Mathewson Created: 11 May 2020 Status: Open ``` # Limit protover values to 0-63. I propose that we no longer accept protover values higher than 63, so that they can all fit nicely into 64-bit fields. (This proposal is part of the Walking Onions spec project.) ## Motivation Doing this will simplify our implementations and our protocols. Right now, an efficient protover implementation needs to use ranges to represent possible protocol versions, and needs workarounds to prevent an attacker from constructing a protover line that would consume too much memory. With Walking Onions, we need lists of protocol versions to be represented in an extremely compact format, which also would benefit from a limited set of possible versions. I believe that we will lose nothing by making this change. Currently, after nearly two decades of Tor development and 3.5 years of experiences with protovers in production, we have no protocol version high than 5. Even if we did someday need to implement higher protocol versions, we could simply add a new subprotocol name instead. For example, instead of "HSIntro=64", we could say "HSIntro2=1". ## Migration Immediately, authorities should begin rejecting relays with protocol versions above 63. (There are no such relays in the consensus right now.) Once this change is deployed to a majority of authorities, we can remove support in other Tor environments for protocol versions above 63.

2 1

Walking onions: week 10 update
by Nick Mathewson 12 May '20

12 May '20

Walking Onions: week 10 update On our current grant from the zcash foundation, I'm working on a full specification for the Walking Onions design. I'm going to try to send out these updates once a week. My previous updates are linked below: Week 1: formats, preliminaries, git repositories, binary diffs, metaformat decisions, and Merkle Tree trickery. https://lists.torproject.org/pipermail/tor-dev/2020-March/014178.html Week 2: Specifying details of SNIP and ENDIVE formats, in CDDL. https://lists.torproject.org/pipermail/tor-dev/2020-March/014181.html Week 3: Expanding ENDIVEs into SNIPs. https://lists.torproject.org/pipermail/tor-dev/2020-March/014194.html Week 4: Voting (part 1) and extending circuits. https://lists.torproject.org/pipermail/tor-dev/2020-March/014207.html Week 5: Voting (part 2) https://lists.torproject.org/pipermail/tor-dev/2020-April/014218.html Week 6: Editing, voting rules, and client behavior (part 1) https://lists.torproject.org/pipermail/tor-dev/2020-April/014222.html Week 7: Exit policies: How do they work? https://lists.torproject.org/pipermail/tor-dev/2020-April/014232.html Week 8: Onion services, relay honesty, migration and families https://lists.torproject.org/pipermail/tor-dev/2020-April/014255.html Week 9: (There was no week 9) == Now with an introduction I left the Introduction section of the proposal till late in the game; now I have it in place as a new section 1: == Proposals into the pipeline I've also revised all of the "other proposals" that were logically separate from the rest of Walking Onions. Three of them were ready to go to tor-dev, so I've added them as: 318-limit-protovers.md Limit protover values to 0-63. 319-wide-everything.md RELAY_FRAGMENT cells 320-tap-out-again.md Removing TAP usage from v2 onion services == In the home stretch I've got till the end of the month to wrap up this proposal, so let's see where we are. We have a minimal viable proposal, I believe: if we were to sit down and start implementing, we would probably get most of the way based on what we have now. There are a few additional things I'd like to wrap up before I call the proposal done, however: * I've got all the necessary machinery written up for generating and calculating indices, but before I actually move ahead, I should fill in the details in sections 2 through 4. * One of the original goals of Walking Onions was to permit us to move to alternative topologies where not every relay connects to every other relay. That's not something that we can include in this proposal, since the research here is quite preliminary, but I still want to prepare for it by making sure that clients can handle getting SNIPs that say "this SNIP is only valid when given by a relay of type X". * I should take another pass through the CDDL format to see whether there are any opportunities to save a bunch of bytes. I should also fill in a couple of example SNIPs to see how big they are with this proposal. * There are places all over the proposal where I have marked uncertain points with XXXX. I should go through them and resolve them all before I call the proposal done. [INTRO] https://github.com/nmathewson/walking-onions-wip/blob/master/specs/01-intro…

1 0

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