- tor-dev - lists.torproject.org

Proposal Idea: Consensus Options
by teor 21 Feb '19

21 Feb '19

Hi all, I have a Tor proposal idea: we should make it easier for tor to get options from the consensus. At the moment, a few tor options are set from the consensus. (If they aren't already set in the torrc.) But there's no abstraction in tor's code, so they're all implemented slightly differently. We could refactor the code so these options are much easier to declare. And we could provide a graceful upgrade path from off-by-default features, to on-by-default features. 1. Tor refactoring We refactor the tor config code, so that options can be declared as consensus options. If the option is configured locally, that value is used. Otherwise, the consensus value is used. If there is no configured or consensus value, the default is used. Each entry in the option declaration table would need 3 extra values: * a flag that tells tor whether to check the consensus * a minimum permitted value from the consensus * a maximum permitted value from the consensus At the same time, we might also want to: * declare a minimum and maximum value for all options, not just the consensus options * add a log message fragment that explains the value restriction So far, this is a refactoring idea. But here's where it gets interesting… 2. Tor authority behaviour change We also want to gracefully upgrade new features, so that they are on-by-default. For privacy sensitive features, we would keep the current process: 1. Deploy the feature off-by-default, but make it a consensus option 2. Manually change the consensus parameter so the option is on-by-default 3. Change the next release of Tor so the option is on-by-default 4. When all supported Tor versions have the feature on-by-default, manually remove the consensus parameter This upgrade path allows us to make sure that almost all the network has the same behaviour. But for other features, we could upgrade faster: 1. Deploy the feature off-by-default, but make it a consensus option 2. Change the next release of Tor so the option is on-by-default 3. When the authorities upgrade to the next release, they automatically vote the consensus parameter on-by-default 4. When all supported Tor versions have the feature on-by-default, remove the flag telling authorities to write the consensus parameter from the option 5. When the authorities upgrade to the next release, they automatically stop voting for the consensus parameter This upgrade path turns the option on when a majority of authorities upgrade. We wouldn't be able to use it for options where flapping is an issue. Each option declaration would need one extra value: * a flag that tells tor authorities whether to write to the consensus If the consensus parameter is explicitly set on an authority, then it would override the default from the option declaration. I think we could implement this proposal as part of Sponsor 31, which is about refactoring tor. We have some tickets for refactoring tor's config code, and making it easier to implement optional features. If anyone wants to help me write it up, let me know! T -- teor ----------------------------------------------------------------------

2 2

Re: [tor-dev] tor-dev Digest, Vol 97, Issue 19
by Gedropi 19 Feb '19

19 Feb '19

Attn: Iain Learmonth <irl(a)torproject.org> Thank you for your thoughtful response. Perhaps this was the wrong mailing list in some ways. Backing up on Iain's email conversation, I have always built my desktop computers from scratch. Salvaged hardware and researched drivers, etc. There is nothing pre-installed. (My colleagues affectionately call me the Queen of Setup and Config.") By design. I have an OEM version of XP that I put on initially, but that is only the start. Since xp is not locked down like Windows 7 and beyond, I then reconfigure so much! You would be right in assuming that a standard xp install is a security risk. But I am constantly tracing packets, studying the traffic at the back end to see where the leaks are. Then I figure out what I can do to plug / understand the leaks. Partly therefore, xp is a learning / testing tool. I use xp for basic apps. But I would sooner drink lye than use Windows 7 and beyond. Therefore, as you already suggested, I did have a dual boot with a Parrot distribution. That is, until my sata drive died. Upon purchase, I will return to the dual boot or to two machines. So therefore, I am back to xp for the time being. Until such time as I have the dual/two machine option again, I surely would like to be able to update as much of Tor as I can. (I know that you are serving the masses and not an individual person). Anyhow, I love Tor and I love having kindred spirits that 'get' security. Thank you for what you are doing. ~Emily On Tue, Feb 19, 2019, at 12:00 PM, tor-dev-request(a)lists.torproject.org wrote: > Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. Re: xp + T (Iain Learmonth) > 2. Sending multiple streams throuh a single Tor circuit > (Piyush Kumar Sharma) > 3. Re: Sending multiple streams throuh a single Tor circuit (meejah) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 18 Feb 2019 14:32:11 +0000 > From: Iain Learmonth <irl(a)torproject.org> > To: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] xp + T > Message-ID: <4b405fbe-6130-ef98-1a8d-74bcacc8bc5f(a)torproject.org> > Content-Type: text/plain; charset="utf-8" > > Hi, > > On 13/02/2019 16:56, neel(a)neelc.org wrote: > > I don't think this is the right mailing list. > > This is entirely the correct mailing list as it is discussing a > technical policy of the network team. This policy can be found here: > > https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/Support… > > > You probably shouldn't be using Windows XP, otherwise the EOL'd OS would > > be a weak point in security. One option could be to dual-boot Windows XP > > and Linux/*BSD, using Linux/*BSD for Tor and browsing, and XP for > > applications that haven't been ported. > > It is worth remembering that most people do not have the privileges to > install software on the computers that they use. > > Unfortunately, the current policy of the network team is that they will > not even accept patches for Windows XP support and will merge changes > that break Windows XP support. > > I would be interested in statistics that show the current Windows XP > user base, especially in countries with users that can most benefit from > Tor. The policy has been drawn up primarily on technical considerations > but if it is shown that this has negative impacts for large numbers of > users then it may be reconsidered. > > Thanks, > Iain. > >

1 0

Marking Proposal 299 (Preferring IPv4 or IPv6 based on IP Version Failure Count) as Accepted
by neel＠neelc.org 18 Feb '19

18 Feb '19

Hi tor-dev@ mailing list, My proposal "Preferring IPv4 or IPv6 based on IP Version Failure Count" (a.k.a. Prop299) is here: https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt I haven't gotten any comments for requests when I asked for them, so I am assuming this proposal is okay. If it is, could someone please mark this proposal as Accepted? If not, what does this proposal require? Thank You, Neel Chauhan === https://www.neelc.org/

2 1

Sending multiple streams through a single Tor circuit
by Piyush Kumar Sharma 16 Feb '19

16 Feb '19

Hello all, I am a PhD student, and am working on some measurements in Tor. I am stuck at a point where i need to send multiple applications(streams) traffic through a single circuit. I am currently using torsocks/torify to send traffic of these multiple applications through Tor. The main problem is that, despite trying many different ways to achieve the same (sending multiple streams through a single circuit), i am not successful. Things i have tried : 1.) Force Tor process to create only a single circuit at a time preventing any new circuit creation, so that any new stream would be attached to this only available circuit. To acheive this i have set the following Tor options : set __DisablePredictedCircuits to 1 set MaxClientCircuitsPending to 1 set newcircuitperiod to 999999999 set maxcircuitdirtiness to 999999999 The problem with the above method is that it seems to work sometimes randomly. But most of the times for some reason, a new circuit is still created. 2.) Next, i assumed that maybe running torify multiple times for each application is the culprit, as it may try to create new circuit for each run. So i created a new bidirectional stream using socat, which listens on a local TCP port, and forwards the data to the Tor SOCKS port assuming that it will lead to a singe connection to local SOCKS. Even this did not work and still new circuits were created randomly. 3.) Next i tried to attach streams to circuits manually, using the stem library following the link : https://stem.torproject.org/tutorials/to_russia_with_love.html#custom-path-… . This seemed to work initially, but then after every 4-5 runs, the streams seemed to detach automatically. Moreover, the original circuit crashed too. It would be great, if someone could tell a simple way to achieve the same, or would point me to any mistakes that can be improved in the above methodologies to make them work. Regards Piyush

1 0

Proposal 300: Walking Onions: Scaling and Saving Bandwidth
by Nick Mathewson 13 Feb '19

13 Feb '19

Filename: 300-walking-onions.txt Title: Walking Onions: Scaling and Saving Bandwidth Author: Nick Mathewson Created: 5-Feb-2019 Status: Draft 0. Status This proposal describes a mechanism called "Walking Onions" for scaling the Tor network and reducing the amount of client bandwidth used to maintain a client's view of the Tor network. This is a draft proposal; there are problems left to be solved and questions left to be answered. Once those parts are done, we can fill in section 4 with the final details of the design. 1. Introduction In the current Tor network design, we assume that every client has a complete view of all the relays in the network. To achieve this, clients download consensus directories at regular intervals, and download descriptors for every relay listed in the directory. The substitution of microdescriptors for regular descriptors (proposal 158) and the use of consensus diffs (proposal 140) have lowered the bytes that clients must dedicate to directory operations. But we still face the problem that, if we force each client to know about every relay in the network, each client's directory traffic will grow linearly with the number of relays in the network. Another drawback in our current system is that client directory traffic is front-loaded: clients need to fetch an entire directory before they begin building circuits. This places extra delays on clients, and extra load on the network. To anonymize the world, we will need to scale to a much larger number of relays and clients: requiring clients to know about every relay in the set simply won't scale, and requiring every new client to download a large document is also problematic. There are obvious responses here, and some other anonymity tools have taken them. It's possible to have a client only use a fraction of the relays in a network--but doing so opens the client to _epistemic attacks_, in which the difference in clients' views of the network is used to partition their traffic. It's also possible to move the problem of selecting relays from the client to the relays themselves, and let each relay select the next relay in turn--but this choice opens the client to _route capture attacks_, in which a malicious relay selects only other malicious relays. In this proposal, I'll describe a design for eliminating up-front client directory downloads. Clients still choose relays at random, but without ever having to hold a list of all the relays. This design does not require clients to trust relays any more than they do today, or open clients to epistemic attacks. I hope to maintain feature parity with the current Tor design; I'll list the places in which I haven't figured out how to do so yet. I'm naming this design "walking onions". The walking onion (Allium x proliferum) reproduces by growing tiny little bulbs at the end of a long stalk. When the stalk gets too top-heavy, it flops over, and the little bulbs start growing somewhere new. The rest of this document will run as follows. In section 2, I'll explain the ideas behind the "walking onions" design, and how they can eliminate the need for regular directory downloads. In section 3, I'll answer a number of follow-up questions that arise, and explain how to keep various features in Tor working. Section 4 (not yet written) will elaborate all the details needed to turn this proposal into a concrete set of specification changes. 2. Overview 2.1. Recapping proposal 141 Back in Proposal 141 ("Download server descriptors on demand"), Peter Palfrader proposed an idea for eliminating ahead-of-time descriptor downloads. Instead of fetching all the descriptors in advance, a client would fetch the descriptor for each relay in its path right before extending the circuit to that relay. For example, if a client has a circuit from A->B and wants to extend the circuit to C, the client asks B for C's descriptor, and then extends the circuit to C. (Note that the client needs to fetch the descriptor every time it extends the circuit, so that an observer can't tell whether the client already had the descriptor or not.) There are a couple of limitations for this design: * It still requires clients to download a consensus. * It introduces a extra round-trip to each hop of the circuit extension process. I'll show how to solve these problems in the two sections below. 2.2. An observation about the ntor handshake. I'll start with an observation about our current circuit extension handshake, ntor: it should not actually be necessary to know a relay's onion key before extending to it. Right now, the client sends: NODEID (The relay's identity) KEYID (The relay's public onion key) CLIENT_PK (a diffie-hellman public key) and the relay responds with: SERVER_PK (a diffie-hellman public key) AUTH (a function of the relay's private keys and *all* of the public keys.) Both parties generate shared symmetric keys from the same inputs that are are used to create the AUTH value. The important insight here is that we could easily change this handshake so that the client sends only CLIENT_PK, and receives NODEID and KEYID as part of the response. In other words, the client needs to know the relay's onion key to _complete_ the handshake, but doesn't actually need to know the relay's onion key in order to _initiate_ the handshake. This is the insight that will let us save a round trip: When the client goes to extend a circuit from A->B to C, it can send B a request to extend to C and retrieve C's descriptor in a single step. Specifically, the client sends only CLIENT_PK, and relay B can include C's keys as part of the EXTENDED cell. 2.3. Extending by certified index Now I'll explain how the client can avoid having to download a list of relays entirely. First, let's look at how a client chooses a random relay today. First, the client puts all of the relays in a list, and computes a weighted bandwidth for each one. For example, suppose the relay identities are R1, R2, R3, R4, and R5, and their bandwidth weights are 50, 40, 30, 20, and 10. The client makes a table like this: Relay Weight Range of index values R1 50 0..49 R2 40 50..89 R3 30 90..119 R4 20 120..139 R5 10 140..149 To choose a random relay, the client picks a random index value between 0 and 149 inclusive, and looks up the corresponding relay in the table. For example, if the client's random number is 77, it will choose R2. If its random number is 137, it chooses R4. The key observation for the "walking onions" design is that the client doesn't actually need to construct this table itself. Instead, we will have this table be constructed by the authorities and distributed to all the relays. Here's how it works: let's have the authorities make a new kind of consensus-like thing. We'll call it an Efficient Network Directory with Individually Verifiable Entries, or "ENDIVE" for short. This will differ from the client's index table above in two ways. First, every entry in the ENDIVE is normalized so that the bandwidth weights maximum index is 2^32-1: Relay Normalized weight Range of index values R1 0x55555546 0x00000000..0x55555545 R2 0x44444438 0x55555546..0x9999997d R3 0x3333332a 0x9999997e..0xcccccca7 R4 0x2222221c 0xcccccca8..0xeeeeeec3 R5 0x1111113c 0xeeeeeec4..0xffffffff Second, every entry in the ENDIVE is timestamped and signed by the authorities independently, so that when a client sees a line from the table above, it can verify that it came from an authentic ENDIVE. When a client has chosen a random index, one of these entries will prove to the client that a given relay corresponds to that index. Because of this property, we'll be calling these entries "Separable Network Index Proofs", or "SNIP"s for short. For example, a single SNIP from the table above might consist of: * A range of times during which this SNIP is valid * R1's identity * R1's ntor onion key * R1's address * The index range 0x00000000..0x55555545 * A signature of all of the above, by a number of authorities Let's put it together. Suppose that the client has a circuit from A->B, and it wants to extend to a random relay, chosen randomly weighted by bandwidth. 1. The client picks a random index value between 0 and 2**32 - 1. It sends that index to relay B in its EXTEND cell, along with a g^x value for the ntor handshake. Note: the client doesn't send an address or identity for the next relay, since it doesn't know what relay it has chosen! (The combination of an index and a g^x value is what I'm calling a "walking onion".) 2. Now, relay B looks up the index in its most recent ENDIVE, to learn which relay the client selected. (For example, suppose that the client's random index value is 0x50000001. This index value falls between 0x00000000 and 0x55555546 in the table above, so the relay B sees that the client has chosen R1 as its next hop.) 3. Relay B sends a create cell to R1 as usual. When it gets a CREATED reply, it includes the authority-signed SNIP for R1 as part of the EXTENDED cell. 4. As part of verifying the handshake, the client verifies that the SNIP was signed by enough authorities, that its timestamp is recent enough, and that it actually corresponds to the random index that the client selected. Notice the properties we have with this design: - Clients can extend circuits without having a list of all the relays. - Because the client's random index needs to match a routing entry signed by the authorities, the client is still selecting a relay randomly by weight. A hostile relay cannot choose which relay to send the client. On a failure to extend, a relay should still report the routing entry for the other relay that it couldn't connect to. As before, a client will start a new circuit if a partially constructed circuit is a partial failure. We could achieve a reliability/security tradeoff by letting clients offer the relay a choice of two or more indices to extend to. This would help reliability, but give the relay more influence over the path. We'd need to analyze this impact. In the next section, I'll discuss a bunch of details that we need to straighten out in order to make this design work. 3. Sorting out the details. 3.1. Will these routing entries fit in EXTEND2 and EXTENDED2 cells? The EXTEND2 cell is probably big enough for this design. The random index that the client sends can be a new "link specifier" type, replacing the IP and identity link specifiers. The EXTENDED2 cell is likely to need to grow here. We'll need to implement proposal 249 ("Allow CREATE cells with >505 bytes of handshake data") so that EXTEND2 and EXTENDED2 cells can be larger. 3.2. How should SNIPs be signed? We have a few options, and I'd like to look into the possibilities here more closely. The simplest possibility is to use **multiple signatures** on each SNIP, the way we do today for consensuses. These signatures should be made using medium-term Ed25519 keys from the authorities. At a cost of 64 bytes per signature, at 9 authorities, we would need 576 bytes for each SNIP. These signatures could be batch-verified to save time at the client side. Since generating a signature takes around 20 usec on my mediocre laptop, authorities should be able to generate this many signatures fairly easily. Another possibility is to use a **threshold signature** on each SNIP, so that the authorities collaboratively generate a short signature that the clients can verify. There are multiple threshold signature schemes that we could consider here, though I haven't yet found one that looks perfect. Another possibility is to use organize the SNIPs in a **merkle tree with a signed root**. For this design, clients could download the signed root periodically, and receive the hash-path from the signed root to the SNIP. This design might help with certificate-transparency-style designs, and it would be necessary if we ever want to move to a postquantum signature algorithm that requires large signatures. Another possibility (due to a conversation among Chelsea Komlo, Sajin Sasy, and Ian Goldberg), is to *use SNARKs*. (Why not? All the cool kids are doing it!) For this, we'd have the clients download a signed hash of the ENDIVE periodically, and have the authorities generate a SNARK for each SNIP, proving its presence in that document. 3.3. How can we detect authority misbehavior? We might want to take countermeasures against the possibility that a quorum of corrupt or compromised authorities give some relays a different set of SNIPs than they give other relays. If we incorporate a merkle tree or a hash chain in the design, we can use mechanisms similar to certificate transparency to ensure that the authorities have a consistent log of all the entries that they have ever handed out. 3.4. How many types of weighted node selection are there, and how do we handle them? Right now, there are multiple weights that we use in Tor: * Weight for exit * Weight for guard * Weight for middle node We also filter nodes for several properties, such as flags they have. To reproduce this behavior, we should enumerate the various weights and filters that we use, and (if there are not too many) create a separate index for each. For example, the Guard index would weight every node for selection as guard, assigning 0 weight to non-Guard nodes. The Exit index would weight every node for selection as an exit, assigning 0 weight to non-Exit nodes. When choosing a relay, the client would have to specify which index to use. We could either have a separate (labeled) set of SNIPs entries for each index, or we could have each SNIP have a separate (labeled) index range for each index. REGRESSION: the client's choice of which index to use would leak the next router's position and purpose in the circuit. This information is something that we believe relays can infer now, but it's not a desired feature that they can. 3.5. Does this design break onion service introduce handshakes? In rend-spec-v3.txt section 3.3.2, we specify a variant of ntor for use in INTRODUCE2 handshakes. It allows the client to send encrypted data as part of its initial ntor handshake, but requires the client to know the onion service's onion key before it sends its initial handshake. That won't be a problem for us here, though: we still require clients to fetch onion service descriptors before contacting a onion service. 3.6. How does the onion service directory work here? The onion service directory is implemented as a hash ring, where each relay's position in the hash ring is decided by a hash of its identity, the current date, and a shared random value that the authorities compute each day. To implement this hash ring using walking onions, we would need to have an extra index based not on bandwidth, but on position in the hash ring. Then onion services and clients could build a circuit, then extend it one more hop specifying their desired index in the hash ring. We could either have a command to retrieve a trio of hashring-based routing entries by index, or to retrieve (or connect to?) the n'th item after a given hashring entry. 3.7. How can clients choose guard nodes? We can reuse the fallback directories here. A newly bootstrapping client would connect to a fallback directory, then build a three-hop circuit, and finally extend the three-hop circuit by indexing to a random guard node. The random guard node's SNIP would contain the information that the client needs to build real circuits through that guard in the future. Because the client would be building a three-hop circuit, the fallback directory would not learn the client's guards. (Note that even if the extend attempt fails, we should still pick the node as a possible guard based on its router entry, so that other nodes can't veto our choice of guards.) 3.8. Does the walking onions design preclude postquantum circuit handshakes? Not at all! Both proposal 263 (ntru) and proposal 270 (newhope) work by having the client generate an ephemeral key as part of its initial handshake. The client does not need to know the relay's onion key to do this, so we can still integrate those proposals with this one. 3.9. Does the walking onions design stop us from changing the network topology? For Tor to continue to scale, we will someday need to accept that not every relay can be simultaneously connected to every other relay. Therefore, we will need to move from our current clique topology assumption to some other topology. There are also proposals to change node selection rules to generate routes providing better performance, or improved resistance to local adversaries. We can, I think, implement this kind of proposal by changing the way that ENDIVEs are generated. Instead giving every relay the same ENDIVE, the authorities would generate different ENDIVEs for different relays, depending on the probability distribution of which relay should be chosen after which in the network topology. In the extreme case, this would produce O(n) ENDIVEs and O(n^2) SNIPs. In practice, I hope that we could do better by having the network topology be non-clique, and by having many relays share the same distribution of successors. 3.10. How can clients handle exit policies? This is an unsolved challenge. If the client tells the middle relay its target port, it leaks information inappropriately. One possibility is to try to gather exit policies into common categories, such as "most ports supported" and "most common ports supported". Another (inefficient) possibility is for clients to keep trying exits until they find one that works. Another (inefficient) possibility is to require that clients who use unusual ports fall back to the old mechanism for route selection. 3.11. Can this approach support families? This is an unsolved challenge. One (inefficient) possibility is for clients to generate circuits and discard those that use multiple relays in the same family. One (not quite compatible) possibility is for the authorities to sort the ENDIVE so that relays in the same family are adjacent to one another. The index-bounds part of each SNIP would also have to include the bounds of the family. This approach is not quite compatible with the status quo, because it prevents relays from belonging to more than one family. One interesting possibility (due to Chelsea Komlo, Sajin Sasy, and Ian Goldberg) is for the middle node to take responsibility for family enforcement. In this design, the client might offer the middle node multiple options for the next relay's index, and the middle node would choose the first such relay that is neither in its family nor its predecessor's family. We'd need to look for a way to make sure that the middle node wasn't biasing the path selection. (TODO: come up with more ideas here.) 3.12. Can walking onions support IP-based and country-based restrictions? This is an unsolved challenge. If the user's restrictions do not exclude most paths, one (inefficient) possibility is for the user to generate paths until they generate one that they like. This idea becomes inefficient if the user is excluding most paths. Another (inefficient and fingerprintable) possibility is to require that clients who use complex path restrictions fall back to the old mechanism for route selection. (TODO: come up with better ideas here.) 3.13. What scaling problems have we not solved with this design? The walking onions design doesn't solve (on its own) the problem that the authorities need to know about every relay, and arrange to have every relay tested. The walking onions design doesn't solve (on its own) the problem that relays need to have a list of all the relays. (But see section 3.9 above.) 3.14. Should we still have clients download a consensus when they're using walking onions? There are some fields in the current consensus directory documents that the clients will still need, like the list of supported protocols and network parameters. A client that uses walking onions should download a new flavor of consensus document that contains only these fields, and does not list any relays. In some signature schemes, this consensus would contain a digest of the ENDIVE -- see 3.2 above. (Note that this document would be a "consensus document" but not a "consensus directory", since it doesn't list any relays.) 4. Putting it all together [This is the section where, in a later version of this proposal, I would specify the exact behavior and data formats to be used here. Right now, I'd say we're too early in the design phase.] A.1. Acknowledgments Thanks to Peter Palfrader for his original design in proposal 141, and to the designers of PIR-Tor, both of which inspired aspects of this Walking Onions design. Thanks to Chelsea Komlo, Sajin Sasy, and Ian Goldberg for feedback on an earlier version of this design. Thanks to David Goulet, Teor, and George Kadianakis for commentary on earlier versions of this draft. A.2. Additional ideas Teor notes that there are ways to try to get this idea to apply to one-pass circuit construction, something like the old onion design. We might be able to derive indices and keys from the same seeds, even. I don't see a way to do this without losing forward secrecy, but it might be worth looking at harder.

8 9

Proposal 299: Preferring IPv4 or IPv6 based on IP Version Failure Count
by Neel Chauhan 08 Feb '19

08 Feb '19

Hi tor-dev@ mailing list, First off, thank you to Nick for making this an official proposal and thank you again for marking it as open. I really appreciate this. Also, thank you teor for aiding me on my first proposal. My proposal is available on torspec here: https://gitweb.torproject.org/torspec.git/tree/proposals/299-ip-failure-cou… Now that my proposal "Preferring IPv4 or IPv6 based on IP Version Failure Count" is Open, I would really appreciate your opinions on this. Is it good, bad? Could it have any improvements? Best, Neel Chauhan === https://www.neelc.org

2 2

anti-censorship weekly meeting
by Gaba 07 Feb '19

07 Feb '19

Hi! Sending a reminder that we are having our weekly meeting for the anti-censorship work on Thursday 20:00 UTC on #tor-meeting at OFTC. The meeting pad is here: https://pad.riseup.net/p/tor-censorship-2019-keep cheers, gaba -- Project Manager - Network, Metrics and Anti-censorship Teams

2 1

The Tor project as a GSoC voucher for Whonix?
by iry 06 Feb '19

06 Feb '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear Tor Developers, Whonix is applying to be a Google Summer of Code organization this year. I am writing on behalf of Whonix to ask if the Tor project could be a voucher for Whonix. Specifically, in the application form, it asks: > If you are a new organization to GSoC, is there a Google employee > or previously participating organization who will vouch for you? If > so, please enter their name, contact email, and relationship to > your organization. Whonix community would be really appreciated if Tor can be our voucher this year. And please feel free to contact me to provide the information described above anytime before the deadline (February 6, 2019 at 20:00 UTC). Thank you very much! Cheers, iry -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEzKSpZKlpRovTotu+oUtNvG3N1TwFAlxY0EMACgkQoUtNvG3N 1TwY/A//SawazcU4EosRFRkF8YJSz3LsRor820uF+X/QovEi5J8EJGaXBgO+Dp+Q Ryi/LzmdGwIWfmWJKk+kWpzfIROYkmNWS6xzz+iwZEYvxvJ2QH5twlAWKDWSwFHm kz7/6AhWnoq+GnsBF+Eg0jNcxSQGLum89Ul4Y3kll4PYriqpDxzQblYt7qzffJJu UJdh9Y5SkSRyX0HThuRgMtCs1l9z7BEY0tkLbUm1pRcU8KuomTy4f1L45T49h7ub rfDc4AOBcA8wtX3CF/1oR0AmRo5YvwD9rMNsk4f+bHphdn07iOcwF5kGi6TxA8Va fLUflN0cIPnk62RmQPebkHSjcyWi74z4rxe2j7trmiDyN2DI3D7wLxNQPYRzO5/H 4YodMAgUkhNluDmJ0Hewq6e3q9js5/6ks1vTGbJjzTW+le2+MOiSiJeZgQYfdF1d Fu7Yf3h6HmIs9zg9zv9qf7CUSizBQVqGqnSUVVyMSsSE5xtX0Enri15PodkMac5C 87m5JDJIuf6HdsCiJ+cXQsCOoTCVz1rFxUMmH3URIOJQX6POZlYjZ4yir1TVc1Uj OkjvsUO89YbnmBpnTJe/0KGS+OjXI+NE3iQfV5d6hIoruqVuIMzL6/O/1Q4onviu oFiCp/ilBtDm8lRlXAbKAIKibYPSAPhoO4xN9jI1NIPoWouwusk= =xX5B -----END PGP SIGNATURE-----

3 5

Release: obfs4proxy-0.0.9
by Yawning Angel 05 Feb '19

05 Feb '19

Hello all, I just tagged obfs4proxy-0.0.9. The main features of this release are primarily related to improving the behavior of the `meek_lite` transport. Since some of the changes are major, I will expand on them separately from the brief summary given in the ChangeLog. * A forked version[0] of https://github.com/refraction-networking/utls is now used to mask the TLS signature. This results in a ClientHello that should resemble modern versions of Firefox by default. While the utls profile is named `HelloFirefox_63`, a cursory examination leads me to believe that there are no differences in FF 65. The bridge line option `utls=<fingerprint>` will allow specifying the behavior, with (case-insenstive) string representations of the utls fingerprint names. `none` will revert to the previous behavior. Not all fingerprints were tested and or are guaranteed to work. Development was primarily done with `HelloChrome_70, `HelloFirefox_63`, and `HelloChrome_71` (experimental). While I can not vouch for the mimicry accuracy of every single profile, all of the profiles that attempt to mimic browsers should function fairly well[1], though this partially depends on the the configuration of the host doing the fronting. * meek_lite now has HPKP[2] style public key pins for all of the Microsoft CA certs that are used to sign Azure leaf certificates. This is only enabled when `utls` is being used, because I'm lazy. If Microsoft happens to change their CA certificates prior to the next release, 2024-05-20, or you are ok with being actively man-in-the- middled for some reason, adding `disableHPKP=true` to the bridge line will disable certificate pin validation. HPKP headers in HTTP responses are ignored, only the static pin list is consulted. * Due to a shift in my philosophy, portions of the new code are released under the GNU General Public License v3. Exceptions to the viral nature of the license will be considered on a case-by-case basis. Contact me for more details. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.9… https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.9… Changes in version 0.0.9 - 2019-02-05: - Various meek_lite code cleanups and bug fixes. - Bug 29077: uTLS for ClientHello camouflage (meek_lite). - More fixes to HTTP Basic auth. - (meek_lite) Pin the certificate chain public keys for the default Tor Browser Azure bridge (meek_lite). Regards, -- Yawning Angel [0]: obfs4proxy WILL NOT build with the upstream version of the library, and the Firefox fingerprint will not function with Azure using the upstream version. [1]: For "I can watch Eluveitie music videos on youtube over it" definitions of "fairly well". [2]: Yes, the HPKP spec is rather dead in the wild with a lot of people giving up on it. It is my opinion that in this context having such a mechanism makes sense.

1 0

New Proposal: Preferring IPv4 or IPv6 based on IP Version Failure Count
by Neel Chauhan 29 Jan '19

29 Jan '19

Hi tor-dev@ mailing list, I have been working on Bug #27491 (https://trac.torproject.org/projects/tor/ticket/27491) and have been asked to write a proposal. My proposal is attached to this email as a text file. I would really appreciate your comments on this proposal (is it good, bad, any problems with it?). Thank You, Neel Chahan

4 6

Building meek-server with Go 1.11.5
by Matthew Finkel 27 Jan '19

27 Jan '19

Attached is a script for building meek-server. I used this for completing #29171. The newest version of Go is only available in Sid and Buster[0], so this script creates a Buster environment and installs the dependencies. The script assumes debootstrap and sudo are installed (and you have necessary privilege). As of today, a Debian Buster system should create a reproducible binary with a SHA-256 digest 6e242798f861308083e54bc0ca3989a03b0818475e9b6df4589ced10c7e3aadc (confirmed over multi-path builds). This is simply an FYI, in case anyone else want so to use it. - Matt [0] https://security-tracker.debian.org/tracker/source-package/golang-1.11

1 0

using obfs4 to tunnel to a SOCKS proxy server
by Hans-Christoph Steiner 24 Jan '19

24 Jan '19

Hey all, Hopefully this is a valid place to ask about PTs technical details. So n8fr8, uniqx (Michael Pöhn), and I are working to make an easily reproducible obfs4 client and server setup with ansible scripts uniqx got the setup working with obfs4 connecting to a port on the server side, like a webserver. Weŕe trying to figure out a way to make this obfs4 setup to behave like an SSH port forward, but weŕe banging our heads against the concept. For example, could the obfs4 server side provide a generic SOCKS proxy? Hereś the use case: wikimedia foundation wants to run their own PTs built into their own client but it needs to support multiple domains, e.g. en.wikipedia.org and commons.wikimedia.org. So we would like to have a generic SOCKS proxy for the client. Then server side, the SOCKS proxy only allows connections to a whitelist of wikimedia servers. Here are uniqxś PT projects: https://gitlab.com/uniqx/pt-obfs4proxy-minimal-demo https://gitlab.com/uniqx/pt-socks5-over-obfs4proxy https://gitlab.com/uniqx/pt-obfs4proxy-tcp-bridge https://gitlab.com/uniqx/pt-tor-obfs4-bridge-test-vm .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556

3 4

anti-censorship weekly meeting notes
by Gaba 24 Jan '19

24 Jan '19

Hi! We had the weekly meeting today! Our next meeting will be in two weeks on February 7th 20:00 UTC You can find the logs here: http://meetbot.debian.net/tor-meeting/2019/tor-meeting.2019-01-24-20.04.html And the contents of the pad: ANTI-CENSORSHIP work meeting pad -------------------------------- Next meeting: Thursday February 7th 20:00 UTC Weekly meetings every Thursday 20:00 UTC on #tor-meeting at OFTC (channel is logged while meetings are in progress). == Goal of this meeting == Weekly checkin about the status of anti-censorship work at Tor. Coordinate collaboration between people/teams on anti-censorship. == Links to Useful documents == Anti-censorship Roadmap: https://storm.torproject.org/shared/KXkqlNP8ouNks_ey5khZKUSbNj9ZoidXmEp80OD… Snowflake Roadmap: https://storm.torproject.org/shared/OdNtwrtRrqklh76l4PfcngBbQFDbjv_jRroj0We… Gettor Roadmap: https://storm.torproject.org/shared/rhsSl_3Pb253HPqoCdFiAdmXQ57NUG_BLvBCxqF… Bridgedb Roadmap: https://storm.torproject.org/shared/O4XpgyW_q6CAtPPO_nd_Qc16Up-jXqdJLG8gXZY… Roger's thoughts on anti-censorship's priorities: https://storm.torproject.org/shared/kU83M2pQehsnQZPzR_mwmYslAijqKgYNOEak57T… Komlo's thoughts on anti-censorship's plan: https://pad.riseup.net/p/CensorshipTeam-Planning-keep Dfcr's thoughts on anti-censorship's priorities (Snowflake only): https://share.riseup.net/#sU0_Jv7OXz8dDK5DHqDVAw ------------------------------- ---- 24th January 2019 ---- ------------------------------- == Announcements == Snowflake extensions: needs developer, let's check who/how in the browser team can do it (antonela, pili, gabA) <-- still working on this Gettor: meet outside weekly anti-censorship meeting to define scope (antonela, gaba, hiro) <-- still working on this == Discussion == Snowflake == Actions == == Updates == FORMAT! Name: Last week: - What you worked on last week a This week: - What you are planning to work on next week (related to anti-censorship work). Help with: - Something you may need help with. Gaba: This week (01/24): preparation for roadmap exercise with network team ahf: Last week: - Documenting current Snowflake architecture and identify problems related to scalability and usability (both for developers and users). (#28848) - Documenting basic WebRTC usage to allow other developers to quickly join in on it. (#28048) [<-- wrong ticket number? 28048 is "Metrics: Allow to search for relays per continent"] - Identifying bug where Snowflake proxy becomes unresponsive in a smaller environment. (possibly #25429?) This week (01/24): - Was out sick friday/monday, didn't do much. - Preparing for network team meeting in brussels where I hope to help the new hire for the anti-censorship team with things related to this: - A talk about Snowflake that will hopefully make everyone be able to look at the code quickly. - Email to Kat about some scalability concerns that I think is worth having in mind about Snowflake: Numbers of bridges, etc. kat5: Working on: - report 2 - private bridge guide for NGOs (hold off until we figure out a strategy for making set-up easy) anto: Working on: - Snowflake Web Extension UI - https://trac.torproject.org/projects/tor/ticket/23888 - Put together a PRD for Gettor, needs more info and review - https://docs.google.com/document/d/18R_tUnqfFkn7d93w0pEbBOLxB62KAWHbUGd5MPK… Help with - snowflake extension: in need of a developer pili (offline): working on: - gettor - agreed on next steps to deploy refactored code with ilv and hiro - still need to define project scope with gaba, antonela and hiro help with: - Browser team can't commit anyone to work on snowflake web extension - can we not just: a) wait for integration into cupcake (see https://github.com/glamrock/cupcake/issues/24) - we can help them with this also b) wait for anti-censorship developer - we need to also think about who is going to maintain this webextension dcf: Last week: - minor UX improvement for Snowflake proxy (#25722) - antonela has more ambitious changes in #27385 - monkeying with uTLS in meek-client (#29077) - meek and snowflake sysadmin This week: - more uTLS in meek-client, restore proxy support - more sysadmin (#29171, #29172) Samdney: Working on: - Will also have a look at the WebExtension ticket #23888 :) - Looking for something where they can help!!! - If you have anything in the direction of "research" or "investigation" in something, then I'm your guy! :) (- I'm working on a research project about censor <-> classical attacker in game theory. That's maybe later, when I have results :), interesting for UX/dev stuff.) _hc/eighthave: uniqx and I have been working on ways to integrate PTs into apps easily. we have a working client/server automation setup based in Python. We also were trying to do a more generic proxy, https://lists.torproject.org/pipermail/tor-dev/2019-January/013637.html n8fr8 is working on getting obfs4 into our Android Pluggable Transports library. he's having trouble getting it to connect to our server automation In Feb, I'll be working on figuring out a good URL scheme for bridge configuraton - #15035 OTF accepted our Concept Note with Stephen Farrell for working on ESNI and ensuring circumvention is included. We are submitting the proposal now, chances look good!

1 0

RFC: Using `utls` in meek_lite.
by Yawning Angel 24 Jan '19

24 Jan '19

Hello, I just pushed a change to obfs4proxy master to use `utls` to mask the ClientHello signature (currently Chrome 70.x). https://gitlab.com/yawning/obfs4/commit/4d453dab2120082b00bf6e63ab4aaeeda6b… I understand that this is being worked on for the original meek (see: https://bugs.torproject.org/29077) but I felt inspired and it was relatively easy to get something working. Caveats: * This is only lightly tested, and may be doing something wrong or distinct. It seems to work well enough to watch videos over it. YMMV. * Azure uses HTTP 2. Not really a problem. * `utls.HelloFirefox_Auto` will fail to handshake with Azure due to an incompatible group being negotiated. * `utls.HelloChrome_Auto` ironically fails to handshake with `google.com` in a standalone test case for me. * `utls.HelloIOS_Auto` seems to work in all cases, so I may switch to that before I tag. Questions, comments, feedback appreciated, -- Yawning Angel

2 7

Modifying Path Selection based on geography
by sarpedon montecarlo 22 Jan '19

22 Jan '19

Hello there. I recently started to do some modifications on tor path selection by using stem, torflow/op-addon and txtorconn. but as long as i enable __LeaveStreamsUnattached option, tor will not function properly. so i decided to hack the source for this feature i seek: custom country for each position: entry:{{entry country-code}} middle:{{middle country-code}} exit:{{country-code}} i really appreciate you guys give me some hint, that which part of the source i must start to hack? i have dived into circuitbuild.c and some other core/or modules but i am confused where to start. thanks in advance.

3 4

Release: obfs4proxy-0.0.8
by Yawning Angel 20 Jan '19

20 Jan '19

Hello all, I just tagged obfs4proxy-0.0.8. This includes a few minor bugfixes in an official tagged release, and changes the primary upstream repo to one hosted on gitlab. Moving forward issues and patch merge requests should be filed on the gitlab issue tracker. While I will attempt to examine other existing locations for such things, response may (will) be delayed. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.8… https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.8… Changes in version 0.0.8 - 2019-01-20: - Bug 24793: Send the correct authorization HTTP header for basic auth. - (meek_lite) Explicitly set Content-Length to zero when there is no data to send. - Added optional support for building as a Go 1.11 module. Patch by mvdan. - Change the canonical upstream repo location to gitlab. Regards, -- Yawning Angel

1 0

Reviewer for Bug #27491: Prefer IPv4 or IPv6 based on the number of failures
by Neel Chauhan 18 Jan '19

18 Jan '19

Hi tor-dev@ mailing list, I noticed the assigned reviewer for my bug/patch #27491 (https://trac.torproject.org/projects/tor/ticket/27491 (https://trac.torproject.org/projects/tor/ticket/27491)) mikeperry, has not yet reviewed my bug since he was assigned to my bug/patch back in December. I understand that not able to review bugs during the holiday season (for obvious reasons), but would someone, either mikeperry or another Tor developer be able to review this? I am aware that there is a code freeze for 0.4.0 and this (probably) won't get merged until at least February 15th, but I would really appreciate a reviewer. Thank You, Neel Chauhan === https://www.neelc.org/

2 1

anti-censorship weekly meeting notes
by Gaba 18 Jan '19

18 Jan '19

Hi! We had the weekly meeting today! You can find the logs here: http://meetbot.debian.net/tor-meeting/2019/tor-meeting.2019-01-17-19.59.html And the contents of the pad: ANTI-CENSORSHIP work meeting pad -------------------------------- Next meeting: Thursday January 24th 8pm UTC Weekly meetings every Thursday 8pm UTC on #tor-meeting at OFTC (channel is logged while meetings are in progress). == Goal of this meeting == Weekly checkin about the status of anti-censorship work at Tor. Coordinate collaboration between people/teams on anti-censorship. == Links to Useful documents == Anti-censorship Roadmap: https://storm.torproject.org/shared/KXkqlNP8ouNks_ey5khZKUSbNj9ZoidXmEp80OD… Snowflake Roadmap: https://storm.torproject.org/shared/OdNtwrtRrqklh76l4PfcngBbQFDbjv_jRroj0We… Gettor Roadmap: https://storm.torproject.org/shared/rhsSl_3Pb253HPqoCdFiAdmXQ57NUG_BLvBCxqF… Bridgedb Roadmap: https://storm.torproject.org/shared/O4XpgyW_q6CAtPPO_nd_Qc16Up-jXqdJLG8gXZY… ------------------------------- ---- 17th January 2019 ---- ------------------------------- == Announcements == new hire for anti-censorship team starting at the end of the month == Discussion == Report on roadmap for anti-censorship at Tor Network Team roadmap for s19 snowflake and snowflake blockers for deployment (already in january) gettor review things that may go into the roadmap while in brussels in february bridgesdb other PTs (marionette setup) snowflake webextension Metrics Team roadmap for s19 can collaborate with other teams after March, specifically bridgedb Browser Team roadmap for s19 Snowflake integration into Tor Browser build (#28672, #25483) Marionette once we have a long running bridge - network team dependency #28015 Brainstorm improved ux for orgs that want to give bridges to their people UX Team roadmap for s19 Gettor PRD https://docs.google.com/document/d/18R_tUnqfFkn7d93w0pEbBOLxB62KAWHbUGd5MPK… <--- meet outside weekly anti-censorship meeting to define Snowflake extension : needs a developer to work on this. #28015 Brainstorm improved ux for orgs that want to give bridges to their people Community Team roadmap for s19 Fitting into existing outreach work? possible #28526? Team dependencies Deploy marionette #26920 Bridges #28015 Gettor Anything else? == Actions == Snowflake extensions: needs developer, let's check who/how in the browser team can do it (antonela, pili, gabA) Gettor: meet outside weekly anti-censorship meeting to define scope (antonela, gaba, hiro) == Updates == FORMAT! Name: Working on: - What you worked on last week and what you are planning to work on next week (related to anti-censorship work). Help with: - Something you may need help with. Gaba: Working on: kicking off collaboration work on the roadmap hiring process for anti-censorship team ahf: Working on: - Documenting current Snowflake architecture and identify problems related to scalability and usability (both for developers and users). (#28848) - Documenting basic WebRTC usage to allow other developers to quickly join in on it. (#28048) [<-- wrong ticket number? 28048 is "Metrics: Allow to search for relays per continent"] - Identifying bug where Snowflake proxy becomes unresponsive in a smaller environment. (possibly #25429?) kat5: Working on: - report 2 - private bridge guide for NGOs anto: Working on: - Snowflake Web Extension UI - https://trac.torproject.org/projects/tor/ticket/23888 - Put together a PRD for Gettor, needs more info and review - https://docs.google.com/document/d/18R_tUnqfFkn7d93w0pEbBOLxB62KAWHbUGd5MPK… Help with - snowflake extension: in need of a developer Samdney: Working on: - Will also have a look at the WebExtension ticket #23888 :) - Looking for something where they can help!!! - If you have anything in the direction of "research" or "investigation" in something, then I'm your guy! :) (- I'm working on a research project about censor <-> classical attacker in game theory. That's maybe later, when I have results :), interesting for UX/dev stuff.)

1 0

anti-censorship weekly checkin
by Gaba 17 Jan '19

17 Jan '19

Hi!! We are going to start doing weekly meetings about anti-censorship work at Tor. We still do not have a team specifically to work on anti-censorship (soon we will have it) BUT we have different teams working on snowflake, gettor and soon bridgedb as well Kat writing a report on what works needs to be done. If you are doing any work related to this and/or are interested in this work please join. Weekly meetings will be every Thursday 8pm UTC on #tor-meeting at OFTC (channel is logged while meetings are in progress). Next meeting Thursday January 17th 8pm UTC on #tor-meeting at OFTC cheers, gaba

1 1

txtorcon 19.0.0
by meejah 16 Jan '19

16 Jan '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm happy to announce txtorcon 19.0.0, containing the following changes: * add TorControlProtocol.when_disconnected (will replace .on_disconnect) * add detach= kwarg to Tor.create_onion_service * add purpose= kwarg to TorState.build_circuit You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/19.0.0 https://github.com/meejah/txtorcon/releases/tag/v19.0.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-19.0.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-19.0.0.tar.gz.asc Or via a "version 3" service: http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check 3731b740653e3f551412744f1fcd7fa6f04aa9fa37c90dc6c9152e619886bf3b txtorcon-19.0.0.tar.gz 196b7b5726e3c69a602071295368da9205c0cd1e26aba37536d3b8fb3b08ac9d txtorcon-19.0.0-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCAAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAlw+vRERHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaacquQgAwJwyhfEhnH2DK9Zqy6pG6oFQzhHUJFgA BehabihiHzJmiUpdVPtZwJ8KkkFbkvkA4AtHy2yF7tP1kCO2k1684IMGtgXOeVC2 hRJpqVqxZlXkOehUmQ87nUTJLYMbVabI5DxIUM9PltvJJj65fIhs0Daq8Kkj5jQT vKgsLo1WNmUJ2JwiO+JYLd3Aet2NIxXl52WA+GyPYFEm5TwHNDL2vCYyT21a8aCB VV4btprjfUd5mb+jFXBvf6cxHrWNFLFMLvoJZruQKVSr0C5AV+7zLWNtanPdSAf6 VxKUpDAZf23iNq4yjDwWgUg8W/pNwO2bZCJB9xQJN7IyRgdd+ubDyQ== =aXJK -----END PGP SIGNATURE-----

1 0

Upcoming Network Team Meetings
by teor 15 Jan '19

15 Jan '19

Hi, The network team has weekly meetings in #tor-meeting on irc.oftc.net. Our next meeting is on Tuesday 22 January at 1800 UTC, because Monday is a US public holiday. We won't have a meeting on 28 January. Most of the team will be at a face-to-face meeting. Our first meeting in February is just after FOSDEM, we'll get back to you with a date. T -- teor ----------------------------------------------------------------------

1 0

Daemon
by marziyeh latifi 10 Jan '19

10 Jan '19

Hello I have some question about daemon: 1-what is the Tor daemon? 2-What is the relationship between oom killer algorithm and daemon? 3-how can I calculate memory usage of deamon by algorithm? I'm looking forward to hearing from you! thanks! Marziyeh

3 2

<unistd.h> in buffers_net.c
by Gisle Vanem 10 Jan '19

10 Jan '19

Some recent change has added a: #include <unistd.h> which fails for MSVC (it doesn't have it). Since I fail to find any way to comment on Trac or Gitweb, I give notice here. Patching into: --- a/src/lib/net/buffers_net.c 2019-01-02 18:57:42 +++ b/src/lib/net/buffers_net.c 2019-01-03 03:16:32 @@ -21,7 +21,10 @@ #endif #include <stdlib.h> + +#ifndef _MSC_VER #include <unistd.h> +#endif #ifdef PARANOIA ---------------- works fine. -- --gv

2 1

Multi-threading throughout
by Todd Hubers 09 Jan '19

09 Jan '19

There are early plans to distribute crypto operations across multiple cores [https://trac.torproject.org/projects/tor/ticket/1749] but there might be a better way. (I registered, but I couldn't find a way to annotate the ticket, so I'm emailing for now) The ticket states the reason being to saturate the bandwidth available (by using all the cores as efficiently as possible). I don't understand why a relay needs to have a "main thread". Network traffic arrives as an async operation and can be sent back out asynchronously. So a final strategy shouldn't have a central thread. The main thread might still be needed for startup, runtime adjustment, and system upkeep, but not for the core network-crypto processing; that should never need to touch the main thread. The current proposal speaks about multi-threading crypto operations, let's call that "A) Speed - Speeding up processing of a single cell". Instead, I propose "B) Concurrency - Restructuring so multiple cells can be processed concurrently". A cell of data should arrive via IO-Completion thread on a random CPU core, have crypto transformation applied on the same one core, then be dispatched onward out via the network. This seems to be quite a simple approach where I would think crypto code can remain the same "single-threaded" implementation. Approach [A] will have diminishing returns as the number of cores increases. You can only break up a cell unit of work so much until you're encrypting one byte per cpu core. However, with approach [B], if you have millions of CPU cores (as an extreme) you can be processing millions of cells concurrently. Therefore, I believe approach [B] would be more scalable. What do you think? Regards, -- -- Todd Hubers

2 3

Network team meeting Tuesday at 2300 UTC
by Gaba 04 Jan '19

04 Jan '19

Hi! The first network team meeting of the year is on Tuesday January 8th at 2300 UTC. The meeting will be at #tor-meeting on OFTC. Agenda and updates for weekly meetings this year are in: https://pad.riseup.net/p/tor-netteam-2019.1-keep cheers, gaba

1 0