- tor-dev - lists.torproject.org

Arti report 7: September 30 through October 13
by Nick Mathewson 14 Oct '21

14 Oct '21

# Arti Report 7: September 30 through October 13 ## Guards are working! Finally, at long last, we've got Guard nodes working in Arti! When we first made our roadmap, we set our first milestone as "Arti has all the features necessary for basic anonymity." Now that Guards are implemented, all of those features are done! Does this mean that Arti is now production-ready for anonymous use? No, not yet. Just because we no longer have _missing_ privacy features doesn't mean that those privacy features are actually implemented correctly. We'll need a lot more testing, debugging, and experimentation. Also, it's very possible we've forgotten something. We'll need careful auditing to be sure. ### Interesting guard issues There are more issues to fix and features to add to the guard implementation down the road. For a current list, have a look at [this comment](https://gitlab.torproject.org/tpo/core/arti/-/issues/58#note_27549…, which lists them. ## What's next Over the next couple of weeks, we'll be working on smaller issues, bugfixes, and miscellaneous cleanups for an upcoming "0.0.1" release, targeting November 1. You can see our latest progress [here]((https://gitlab.torproject.org/tpo/core/arti/-/milestones/6). ## Thanks! Thanks to Jani Monoses for progress towards a WASM port, and Trinity Pointard for updates to dependencies.

1 0

IANA well-known URI suffix registration for tor-relay-fingerprints file
by nusenu 10 Oct '21

10 Oct '21

Hi, to reduce the risk of certain kinds of attacks I'm aiming to submit a short spec (like [1]) in accordance with RFC8615 https://tools.ietf.org/html/rfc8615#section-3.1 for the registration of of a suffix for the verifyurl from https://github.com/nusenu/ContactInfo-Information-Sharing-Specification#ver… The name I have in mind is: tor-relay-fingerprints The file contains comments (lines starting with #) and relay fingerprints. https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml Let me know if you have any feedback on this and whether you have any opinion on whether you (The Torproject) wants to be the change controller. The only question that came up was: Will there be two types of relay fingerprints in the future (Ed25519)? thanks, nusenu -- https://mastodon.social/@nusenu [1] https://keybase.io/docs/keybase_well_known

5 22

tor Prometheus Metrics Documentation
by nusenu 10 Oct '21

10 Oct '21

Hi, since Neel is working on unix socket support [1] for MetricsPort I'm preparing to add support for it to relayor. I don't like to add additional attack surface to a relay but since tor does not support TLS and basic auth on the MetricsPort I'll likely install nginx that takes care of TLS and authentication. If you have any opinion on that I'd also like to hear it. It would be nice to have a documentation for all tor prometheus metrics in the man page or on a website, some information can be found at [3] but not all. Is there already a complete documentation for tor prometheus metrics data? Here is an example of how other projects have documented their metrics [5]. I don't know if it is too late for that but it would be great to use the well known IANA RCODE [4] naming for the DNS return codes where possible instead of the custom naming. examples (just guessing): tor_relay_exit_dns_error_total{... reason="format"} -> FormErr? tor_relay_exit_dns_error_total{... reason="notexist"} -> NXDomain? kind regards, nusenu [1] https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/453 [3] https://support.torproject.org/relay-operators/relay-bridge-overloaded/ [4] https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-pa… [5] https://doc.powerdns.com/recursor/metrics.html#metricnames related feature request: [2] https://gitlab.torproject.org/tpo/core/tor/-/issues/40194 -- https://nusenu.github.io

1 0

ed25519_master_id_public_key -> ed25519 id
by nusenu 10 Oct '21

10 Oct '21

Hi, given a relay's ed25519_master_id_public_key file, is there a simple way to generate the 43 chars long ed25519 identity string (also found in fingerprint-ed25519)? thanks, nusenu -- https://nusenu.github.io

2 3

Re: [tor-dev] Proposal 335: An authority-only design for MiddleOnly
by ezhigp＠Safe-mail.net 08 Oct '21

08 Oct '21

> ``` > Filename: 335-middle-only-redux.md > Title: An authority-only design for MiddleOnly > Author: Nick Mathewson > Created: 2021-10-08 > Status: Open > ... > > These flags SHOULD be set in a vote whenever `MiddleOnly` is > present, and only when the authority is configured to vote on the > `BadExit` flag. > > * `BadExit` > > These flags SHOULD be cleared in a vote whenever `MiddleOnly` is > present. > > * `Exit` I believe that BadExit is supposed to be given together with Exit, to mark that technically it's possible to exit from this relay, but it is not recommended unless you know what you do. > * `Guard` > * `HSDir` > * `V2Dir` It looks like we don't fear such a relay at Intro? Or it is a sign that this proposal is only a set of quick actions before #334?

1 0

v2 Onions, IPv6 BiDir P2P Capability Regression... [re: Relays running unsupported EOL ver]
by grarpamp 07 Oct '21

07 Oct '21

On that, and regardless of what TPO Inc says re... tor is a bit decentralized, and freely licensed, as such... DirAuths, HSDirs, Relays are all free to choose to continue signing over and running older versions in order to support the community of tor clients that are happily using useful features that the Tor Project on its high horse demands with its blanket fiat fist and refusing to consider and support users... to remove from such users, herein as noted before, v2 onions and simple OnionCat IPv6 /48+80 UDP transport P2P E2E BiDir addressing and thus all current IPv6 capable apps incl VOIP Bittorrent comms status chat game coins etc and future apps that needing such tech to operate across onionland. That's bad, and a big regression in service, both active now, and preventing potential development on interesting new uses and applications in the future. These users, these features, apps, and their recognized tradeoffs, their free choices made therein, are of merit and import. And Tor Project is choosing to censor and ban v2 and them without regard. Perhaps some v2 users will likewise email all the relays seeking not their censorship, but instead their support. But perhaps due to any needs they may have to remain unknown they may not be able to voice out to lists etc, as such the surfaceweb cannot make dis-use assumptions and must indeed hold v2 in their stead for them. Kudos to those distributed DirAuths, HSDirs, and Relays who refuse to comply with Tor Project Inc demands to crush all v2 onion users and their legitimate use cases. The better path is for TPO to either recognize and continue, or to modularize v2 onion support out to community stewardship such that the features that it provides may continue until a future vN or a seamless scalable externally attached solution for the same features and uses is found. And to make v3 the default choice "advertised" in docs and configs, with v2 a lesser noted option yet for just providing above capabilities. Tor Project still doesn't have a version feature matrix table, nor an honest open balanced and free to all authors wiki education page detailing use case and tradeoff notes for users about the v2+OnionCat vs v3 tech capabilities, thereby allowing tor users to freely make educated choices therein on their own. Instead it has a bricked up and censored prop blog and lists. Like TPO's censorship, that's unfair, unwarranted, questionable, and needs to end. ps: Yes, upgrade, if merely behind on versions sake, lots of good fixes, improvements, performance, features, security, etc come with those. But when it comes to a big and permanent regression of overall network capability issue such as this, that's different, and needs consideration beyond the vague handwavy universal whitewash "reason" being uttered by TPO such as "v2 insecure"... which is false re educated tradeoffs and uses that users are free to evaluate and choose on their own. In fact, users are in better more intelligent aware position having learned a bit of something and made that themselves. Users are also free to eval by bring forward to today sense of the NSA's 10+ year old slides that noted "Tor Stinks". What conditions, designs, capabilities, etc have changed since then. Cheers all. On 10/5/21, Georg Koppen <gk(a)torproject.org> wrote: > Relays running unsupported Tor versions is a problem we have never > really dealt with in a systematic way in the way. Some of you might > recall that we (with the help of volunteers) tried back in 2019/2020 to > get operators, running an unsupported Tor version, to upgrade[1] but > then we dropped the ball. Alas. > > We just started that process again by contacting every relay operator > running an outdated Tor version (any version not 0.3.5.x or 0.4.5.x or > 0.4.6.x or 0.4.7.x) by email where possible. Additionally, we created a > wiki page outlining the current process and things we still need to > figure out.[2] On that page we plan to make statistics related to the > EOL relay removal available as well, including the final list of relays > we'll reject. Thus, stay tuned. Feedback, as always, is very much welcome! > > We plan to keep this topic on our radar this time while refining the > process as we go. Meanwhile, if you are running a relay with an > unsupported Tor version, please upgrade for the sake of our users' safety. > > If you need help, join us on #tor-relays or #tor-relays:matrix.org if > you use Element. > > [1] https://blog.torproject.org/removing-end-life-relays-network > [2] https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Relay-EOL-pol…

1 0

Updated Proposal 324: RTT-based Congestion Control for Tor
by Mike Perry 06 Oct '21

06 Oct '21

As a heads up, I have updated Proposal 324: RTT-based Congestion Control for Tor - https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/324-rt… The updated version has a new congestion control algorithm, detailed specifics on how to accurately measure RTT and BDP, and descriptions of algorithm parameter values and tuning experiments, among other improvements. A C implementation of these algorithms has been merged to tor.git orgin/main. They live in src/core/or/congestion_control_*.[ch]. These algorithms are not enabled yet; we still need to implement flow control and negotiation, as well as do shadow experimentation to determine good candidate parameter values to further tune on live. Here is a full changelog since the proposal was last published to tor-dev: - Correct algorithms to update once per congestion window - Add orconn blocking and edge connection checks as signals - Specify BDP estimators based on onion service testing and eval. - Specify a pure BDP tracking congestion control algorithm (TOR_NOLA) - Update consensus parameters with tuning notes - Document what we learned so far in live onion service experimentation - Mention that we need to test intermittent downloads in Shadow/live - Describe clock jump and stall detection during RTT measurement - Mention if we calculate package window, it can become negative - Break off the backwards ECN idea into a future idea draft: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/ideas/… - Update old trac URLs - Add Acknowledgements Review and comments are welcome! -- Mike Perry

1 1

(Short) Arti Report 6: September 15 through September 30
by Nick Mathewson 01 Oct '21

01 Oct '21

# Arti Report 6: September 15 through September 30 ## Activities since our last report Hello! Lots of code since last time, but not so much to say about it. I'm chugging ahead on the Guard nodes implementation, but it isn't done yet. Most of the code is there, but I need to write tests, chase down a few spec issues, fix a couple of things that "don't feel right", and integrate it all with tor-circmgr. You can track progress on the guard implementation at <https://gitlab.torproject.org/tpo/core/arti/-/issues/58>. ## Thanks! Thanks to Jani Monoses for refactoring, Daniel Eades for cleanup, and Trinity Pointard for OSX reproducible builds and integration testing (!).

1 0

Re: [tor-dev] Proposal 334: A flag to mark Relays as middle-only
by ezhigp＠Safe-mail.net 18 Sep '21

18 Sep '21

-------- Original Message -------- From: Neel Chauhan <neel(a)neelc.org> Apparently from: tor-dev-bounces(a)lists.torproject.org To: tor-dev(a)lists.torproject.org Subject: Re: [tor-dev] Proposal 334: A flag to mark Relays as middle-only Date: Fri, 17 Sep 2021 16:09:43 -0700 > Hi nusenu (and tor-dev@), > > On 2021-09-17 16:02, nusenu wrote: > > it would be great if you could open a MR for the proposal so we can > > always see the latest version and changes > > there. > > (Over time it became unclear what comments have already been addressed > > in the text an which didn't.) > > Done: https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/46 Line 102> single directory authority servre [3]. Typo here. > > > kind regards, > > nusenu > > -Neel > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

1 0

Proposal 332: Ntor protocol with extra data, version 3.
by Nick Mathewson 18 Sep '21

18 Sep '21

``` Filename: 332-ntor-v3-with-extra-data.md Title: Ntor protocol with extra data, version 3. Author: Nick Mathewson Created: 12 July 2021 Status: Open ``` # Overview The ntor handshake is our current protocol for circuit establishment. So far we have two variants of the ntor handshake in use: the "ntor v1" that we use for everyday circuit extension (see `tor-spec.txt`) and the "hs-ntor" that we use for v3 onion service handshake (see `rend-spec-v3.txt`). This document defines a third version of ntor, adapting the improvements from hs-ntor for use in regular circuit establishment. These improvements include: * Support for sending additional encrypted and authenticated protocol-setup handshake data as part of the ntor handshake. (The information sent from the client to the relay does not receive forward secrecy.) * Support for using an external shared secret that both parties must know in order to complete the handshake. (In the HS handshake, this is the subcredential. We don't use it for circuit extension, but in theory we could.) * Providing a single specification that can, in the future, be used both for circuit extension _and_ HS introduction. # The improved protocol: an abstract view Given a client "C" that wants to construct a circuit to a relay "S": The client knows: * B: a public "onion key" for S * ID: an identity for S, represented as a fixed-length byte string. * CM: a message that it wants to send to S as part of the handshake. * An optional "verification" string. The relay knows: * A set of [(b,B)...] "onion key" keypairs. One of them is "current", the others are outdated, but still valid. * ID: Its own identity. * A function for computing a server message SM, based on a given client message. * An optional "verification" string. This must match the "verification" string from the client. Both parties have a strong source of randomness. Given this information, the client computes a "client handshake" and sends it to the relay. The relay then uses its information plus the client handshake to see if the incoming message is valid; if it is, then it computes a "server handshake" to send in reply. The client processes the server handshake, and either succeeds or fails. At this point, the client and the relay both have access to: * CM (the message the client sent) * SM (the message the relay sent) * KS (a shared byte stream of arbitrary length, used to compute keys to be used elsewhere in the protocol). Additionally, the client knows that CM was sent _only_ to the relay whose public onion key is B, and that KS is shared _only_ with that relay. The relay does not know which client participated in the handshake, but it does know that CM came from the same client that generated the key X, and that SM and KS were shared _only_ with that client. Both parties know that CM, SM, and KS were shared correctly, or not at all. Both parties know that they used the same verification string; if they did not, they do not learn what the verification string was. (This feature is required for HS handshakes.) # The handshake in detail ## Notation We use the following notation: * `|` -- concatenation * `"..."` -- a byte string, with no terminating NUL. * `ENCAP(s)` -- an encapsulation function. We define this as `htonll(len(s)) | s`. (Note that `len(ENCAP(s)) = len(s) + 8`). * `PARTITION(s, n1, n2, n3, ...)` -- a function that partitions a bytestring `s` into chunks of length `n1`, `n2`, `n3`, and so on. Extra data is put into a final chunk. If `s` is not long enough, the function fails. We require the following crypto operations: * `KDF(s,t)` -- a tweakable key derivation function, returning a keystream of arbitrary length. * `H(s,t)` -- a tweakable hash function of output length `DIGEST_LEN`. * `MAC(k, msg, t)` -- a tweakable message-authentication-code function, of output length `MAC_LEN`. * `EXP(pk,sk)` -- our Diffie Hellman group operation, taking a public key of length `PUB_KEY_LEN`. * `KEYGEN()` -- our Diffie-Hellman keypair generation algorithm, returning a (secret-key,public-key) pair. * `ENC(k, m)` -- a stream cipher with key of length `ENC_KEY_LEN`. `DEC(k, m)` is its inverse. Parameters: * `PROTOID` -- a short protocol identifier * `t_*` -- a set of "tweak" strings, used to derive distinct hashes from a single hash function. * `ID_LEN` -- the length of an identity key that uniquely identifies a relay. Given our cryptographic operations and a set of tweak strings, we define: ``` H_foo(s) = H(s, t_foo) MAC_foo(k, msg) = MAC(k, msg, t_foo) KDF_foo(s) = KDF(s, t_foo) ``` See Appendix A.1 below for a set of instantiations for these operations and constants. ## Client operation, phase 1 The client knows: B, ID -- the onion key and ID of the relay it wants to use. CM -- the message that it wants to send as part of its handshake. VER -- a verification string. First, the client generates a single-use keypair: x,X = KEYGEN() and computes: Bx = EXP(B,x) secret_input_phase1 = Bx | ID | X | B | PROTOID | ENCAP(VER) phase1_keys = KDF_msgkdf(secret_input_phase1) (ENC_K1, MAC_K1) = PARTITION(phase1_keys, ENC_KEY_LEN, MAC_KEY_LEN) encrypted_msg = ENC(ENC_K1, CM) msg_mac = MAC_msgmac(MAC_K1, ID | B | X | encrypted_msg) and sends: NODEID ID [ID_LEN bytes] KEYID B [PUB_KEY_LEN bytes] CLIENT_PK X [PUB_KEY_LEN bytes] MSG encrypted_msg [len(CM) bytes] MAC msg_mac [last MAC_LEN bytes of message] The client remembers x, X, B, ID, Bx, and msg_mac. ## Server operation The relay checks whether NODEID is as expected, and looks up the (b,B) keypair corresponding to KEYID. If the keypair is missing or the NODEID is wrong, the handshake fails. Now the relay uses `X=CLIENT_PK` to compute: Xb = EXP(X,b) secret_input_phase1 = Xb | ID | X | B | PROTOID | ENCAP(VER) phase1_keys = KDF_msgkdf(secret_input_phase1) (ENC_K1, MAC_K1) = PARTITION(phase1_keys, ENC_KEY_LEN, MAC_KEY_LEN) expected_mac = MAC_msgmac(MAC_K1, ID | B | X | MSG) If `expected_mac` is not `MAC`, the handshake fails. Otherwise the relay computes `CM` as: CM = DEC(MSG, ENC_K1) The relay then checks whether `CM` is well-formed, and in response composes `SM`, the reply that it wants to send as part of the handshake. It then generates a new ephemeral keypair: y,Y = KEYGEN() and computes the rest of the handshake: Xy = EXP(X,y) secret_input = Xy | Xb | ID | B | X | Y | PROTOID | ENCAP(VER) ntor_key_seed = H_key_seed(secret_input) verify = H_verify(secret_input) RAW_KEYSTREAM = KDF_final(ntor_key_seed) (ENC_KEY, KEYSTREAM) = PARTITION(RAW_KEYSTREAM, ENC_KEY_LKEN, ...) encrypted_msg = ENC(ENC_KEY, SM) auth_input = verify | ID | B | Y | X | MAC | ENCAP(encrypted_msg) | PROTOID | "Server" AUTH = H_auth(auth_input) The relay then sends: Y Y [PUB_KEY_LEN bytes] AUTH AUTH [DIGEST_LEN bytes] MSG encrypted_msg [len(SM) bytes, up to end of the message] The relay uses KEYSTREAM to generate the shared secrets for the newly created circuit. ## Client operation, phase 2 The client computes: Yx = EXP(Y, x) secret_input = Yx | Bx | ID | B | X | Y | PROTOID | ENCAP(VER) ntor_key_seed = H_key_seed(secret_input) verify = H_verify(secret_input) auth_input = verify | ID | B | Y | X | MAC | ENCAP(MSG) | PROTOID | "Server" AUTH_expected = H_auth(auth_input) If AUTH_expected is equal to AUTH, then the handshake has succeeded. The client can then calculate: RAW_KEYSTREAM = KDF_final(ntor_key_seed) (ENC_KEY, KEYSTREAM) = PARTITION(RAW_KEYSTREAM, ENC_KEY_LKEN, ...) SM = DEC(ENC_KEY, MSG) SM is the message from the relay, and the client uses KEYSTREAM to generate the shared secrets for the newly created circuit. # Security notes Whenever comparing bytestrings, implementations SHOULD use constant-time comparison function to avoid side-channel attacks. To avoid small-subgroup attacks against the Diffie-Hellman function, implementations SHOULD either: * Make sure that all incoming group members are in fact in the DH group. * Validate all outputs from the EXP function to make sure that they are not degenerate. # Notes on usage We don't specify what should actually be done with the resulting keystreams; that depends on the usage for which this handshake is employed. Typically, they'll be divided up into a series of tags and symmetric keys. The keystreams generated here are (conceptually) unlimited. In practice, the usage will determine the amount of key material actually needed: that's the amount that clients and relays will actually generate. The PROTOID parameter should be changed not only if the cryptographic operations change here, but also if the usage changes at all, or if the meaning of any parameters changes. (For example, if the encoding of CM and SM changed, or if ID were a different length or represented a different type of key, then we should start using a new PROTOID.) # A.1 Instantiation Here are a set of functions based on SHA3, SHAKE128, Curve25519, and AES256: ``` H(s, t) = SHA3_256(ENCAP(t) | s) MAC(k, msg, t) = SHA3_256(ENCAP(t) | ENCAP(k) | s) KDF(s, t) = SHAKE_128(ENCAP(t) | s) ENC(k, m) = AES_256_CTR(k, m) EXP(pk,sk), KEYGEN: defined as in curve25519 DIGEST_LEN = MAC_LEN = ENC_KEY_LEN = PUB_KEY_LEN = 32 ID_LEN = 32 (representing an ed25519 identity key) ``` Notes on selected operations: SHA3 can be pretty slow, and AES256 is likely overkill. I'm choosing them anyway because they are what we use in hs-ntor, and in my preliminary experiments they don't account for even 1% of the time spent on this handshake. ``` t_msgkdf = PROTOID | ":kdf_phase1" t_msgmac = PROTOID | ":msg_mac" t_key_seed = PROTOID | ":key_seed" t_verify = PROTOID | ":verify" t_final = PROTOID | ":kdf_final" t_auth = PROTOID | ":auth_final" ``` # A.2 Encoding for use with Tor circuit extension Here we give a concrete instantiation of ntor-v3 for use with circuit extension in Tor, and the parameters in A.1 above. If in use, this is a new CREATE2 type. Clients should not use it unless the relay advertises support by including an appropriate version of the `Relay=X` subprotocol in its protocols list. When the encoding and methods of this section, along with the instantiations from the previous section, are in use, we specify: PROTOID = "ntor3-curve25519-sha3_256-1" The key material is extracted as follows, unless modified by the handshake (see below). See tor-spec.txt for more info on the specific values: Df Digest authentication, forwards [20 bytes] Db Digest authentication, backwards [20 bytes] Kf Encryption key, forwards [16 bytes] Kb Encryption key, backwards [16 bytes] KH Onion service nonce [20 bytes] We use the following meta-encoding for the contents of client and server messages. [Any number of times]: TYPE [one byte] LEN [one byte] BODY [LEN bytes] We do not specify specific TYPE semantics here; we leave those for other proposals. All parties MUST reject messages that are not well-formed per the rules above. To avoid partitioning, clients MUST reject messages with TYPEs that they do not recognize. (Therefore, whenever we specify a new server message TYPE, we must say that it can only be included if the client signals that it understands it.) # A.3 How much space is available? We start with a 498-byte payload in each relay cell. The header of the EXTEND2 cell, including link specifiers and other headers, comes to 89 bytes. The client handshake requires 128 bytes (excluding CM). That leaves 281 bytes, "which should be plenty". # X.1 Negotiating proposal-324 circuit windows (We should move this section into prop324 when this proposal is finished.) We define a type value, CIRCWINDOW_INC. We define a triplet of consensus parameters: `circwindow_inc_min`, `cincwindow_inc_max`, and `circwindow_inc_dflt`. These all have range (1,65535). When the authority operators want to experiment with different values for `circwindow_inc_dflt`, they set `circwindow_inc_min` and `circwindow_inc_max` to the range in which they want to experiment, making sure that the existing `circwindow_inc_dflt` is within that range. vWhen a client sees that a relay supports the ntor3 handshake type (subprotocol `Relay=X`), and also supports the flow control algorithms of proposal 324 (subprotocol `FlowCtrl=X`), then the client sends a message, with type `CIRCWINDOW_INC`, containing a two-byte integer equal to `circwindow_inc_dflt`. The relay rejects the message if the value given is outside of the [`circwindow_inc_min`, `circwindow_inc_max`] range. Otherwise, it accepts it, and replies with the same message that the client sent.

4 7

Proposal 334: A flag to mark Relays as middle-only
by Neel Chauhan 17 Sep '21

17 Sep '21

Hi, As asked in the torspec MR [1] (42) for ticket [2] (40448), I propose a MiddleOnly dirauth flag for relays. The proposal, #334, is attached to this email, and is titled "A dirauth flag to mark Relays as Middle-only". Please comment and review it. Best, Neel Chauhan === Links: [1] - https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/42 [2] - https://gitlab.torproject.org/tpo/core/tor/-/issues/40448

7 19

Proposal 334: A flag to mark Relays as middle-only
by Tor Relays 16 Sep '21

16 Sep '21

David Goulet: > However, I'm not sure we should always let 1 authority dictate that flag > regardless of what the others think. > > I think we need to enforce majority here and not have one > single authority dictate it. > > Thoughts? > +1 I can compromise one authority and can MiddleOnly the whole Tor network.

2 1

Arti report 5: August 18 through September 15
by Nick Mathewson 15 Sep '21

15 Sep '21

# Arti Report 5: August 4 through September 15 ## Activities since our last report I'm back, with updates from the last month! We've spent a lot of time over the last on cleaning up technical debt issues in our code that had accumulated as I wrote it. There are more tests and warnings enabled than before, and we've changed some new internal APIs to make them unable to panic. We're also using the [`derive_builder`][derive_builder] tool to throw out a bunch of boilerplate code. When I wrote last month, I'd just finished up the implementation for circuit build timeout inference. As followup work to that, I worked with Mike Perry to collect all of the missing specification issues that I'd found while cloning that feature, and [roll them back][torspec-mr-40] into our `path-spec.txt` document. Mike'sw found a couple of mistakes in my implementation that I was able to resolve—fortunately, by removing code from the Arti timeout inference code. ## Getting a head start on API design API design will be the focus of our 0.1.0 release, but we still want to get it "as right as we can" in the upcoming 0.0.1 version. With that in mind, we've started enumerating the various kinds of programs and environments that we need to support down the road, and [working on a list of example programs][ticket-164] that we might be able to ship with Arti. (My own experience so far is that writing example code is just about the best way to find API deficiencies.) ## Uplifting new features from C Tor For our work on congestion control, we're getting a new [circuit extension handshake][prop332]. Going forward, as we add features to C Tor, we're going to try to add them to Arti at around the same time. With that in mind, we have the new handshake implemented (but not enabled): we used its implementation to validate our specifications double-check our test vectors. ## Towards guard support Our largest remaining priority for Arti 0.0.1 is full support for [guard nodes][guard-spec]. (In Tor, a "guard node" is a relay that a client decides to use as the first hop for all of its circuits for a long time. Using guard nodes improves resistance against many kinds of attacks based on hostile relays.) We've started laying the groundwork here: we now have support for all of the guard-related consensus parameters, and we've reworked our relay selection code to allow picking multiple weighted random items without replacement. We've also added some previously unneeded lookup-by-ID features to network directory code. (Fun fact: the Tor implementation of mapping IDs to relays has been historically ugly, since we don't really know a relay's ed25519 identity until we have a microdescriptor for it. In C, this has led to a reasonably messy pile of dangling pointer bugs…which Rust won't even let us write! Also, we've made better design choices in Arti about our directory objects, so we don't have do support all of the strange mutability that our C code had to try to handle.) We're now in the midst of coding up a guard implementation. The tricky part here is that our guard logic affects circuit building selection (since circuit paths must begin with a guard), but circuit construction affects guard selection. We're experimenting with different designs to try to keep the complexity here under control. # Thanks to awesome volunteers! Thanks to Jani Monoses for migrating Arti to the tracing crate and adding journald support; to Robin Leander Schröder for cleaning up some of our `unwrap_or()` code; to S0AndS0 for work enabling the `unwrap_used` Clippy lint; to Daniel Eades for work cleaning up Clippy lints in our test modules, and to Trinity Pointard for work on stream isolation and reproducible builds! [ticket-164]: https://gitlab.torproject.org/tpo/core/arti/-/issues/164 [prop-332]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/332-nt… [derive_builder]: https://crates.io/crates/derive_builder [torspec-mr-40]: https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/40 [guard-spec]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/guard-spec.txt

1 0

Proposal 334: A flag to mark Relays as middle-only
by ezhigp＠Safe-mail.net 14 Sep '21

14 Sep '21

Neel Chauman wrote at Sun Sep 12 19:17:37 UTC 2021: >my updated proposal >says that if one dirauth gives a relay the MiddleOnly flag, then it's >set for that relay. This is to prevent harm while all (or the majority >of) dirauths give the relay that flag. Imagine one hostile dirauth that votes for this flag on every relay it cannot control. Guessing the result is left as an exercise to the reader :). (Spoiler: IIUC, this will result in using only attacker-controlled relays as entries and exits, resulting in both-ends control of all external and hidserv circuits).

1 0

No arti report this week.
by Nick Mathewson 01 Sep '21

01 Sep '21

Hi! Usually I do Arti reports every other Wednesday, but this week I'm on vacation. I'll send the next report on September 15, so that the reports can be offset from the Arti meetings. cheers, -- Nick

1 0

Next public Arti meeting happening on September 8th at 1500 UTC
by Gaba 26 Aug '21

26 Aug '21

Hi! We are canceling the meeting on September 1st. Our next meeting will be on September 8th (and then every 2 weeks). Meeting's room: https://tor.meet.coop/gab-sis-ldw-xad Meeting notes in: http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/art… Recording of previous meetings: https://www.youtube.com/playlist?list=PLwyU2dZ3LJErozq7cTtImuWkSn_34pEpq Agenda - status of Arti development and planning - user stories for Arti API https://pad.riseup.net/p/MUjnic0eRT0WrDW7M-us cheers gaba -- pronouns she/her/they GPG Fingerprint EE3F DF5C AD91 643C 21BE 8370 180D B06C 59CA BD19

1 0

Arti report 4: August 4 through August 18
by Nick Mathewson 18 Aug '21

18 Aug '21

# Arti Report 3: August 4 through August 18 At last we're done with circuit timeout inference! See the last weeks update for an overview of what this was, and why it was hard. As of last Friday, we've finally got an Arti implementation that builds testing circuits as appropriate, infers reasonable timeouts, and remembers those timeouts across runs. As a side-benefit to this work, we've found a number of points where we need to clarify the Tor specification to be more precise about correct behavior for a Tor client. (For example, how to break ties when deciding on the most populous histogram bins.) I'm taking some time to circle back and fix those in the Tor specs. Here is the first recorded persistent state from an Arti implementation, lightly reformatted: version = 1 histogram = [[415, 1], [495, 2], [515, 1], [535, 1], [545, 1], [555, 1], [625, 1], [655, 1], [665, 1], [785, 1], [835, 1], [865, 2], [885, 3], [955, 1], [965, 1], [975, 2], [985, 1], [1005, 2], [1025, 1], [1035, 2], [1055, 3], [1065, 1], [1075, 1], [1085, 2], [1095, 1], [1115, 2], [1135, 2], [1145, 2], [1175, 1], [1185, 1], [1195, 2], [1205, 3], [1215, 1], [1235, 2], [1245, 6], [1255, 1], [1265, 2], [1285, 2], [1295, 3], [1305, 1], [1315, 1], [1355, 2], [1375, 2], [1385, 2], [1405, 2], [1435, 1], [1455, 1], [1465, 1], [1495, 1], [1505, 1], [1525, 1], [1535, 1], [1555, 1], [1565, 1], [1605, 1], [1625, 1], [1665, 1], [1765, 1], [1785, 1], [1825, 1], [1965, 1], [2165, 1], [2495, 1], [3025, 1], [3855, 1], [4265, 1], [4795, 1], [4935, 1], [5435, 1], [6825, 1]] current_timeout = 1592 abandoned_circs = 0 successful_circs = 20 ## Other work We've continued to review and merge volunteer patches. Thanks, everybody! In response to a patch documenting a number of possible panics, I've taken a pass through the code to reduce the number of functions that could panic. I've also been spending some time improving test coverage: while doing so, I found an incorrect behavior when checking whether two IPv6 addresses were on the same network. (Tests are great and need to be everywhere, apparently.) ## Coming up Our current priorities are: * Starting API design work. So far we've been feeling our way forward, and it's time to get more systematic. * Improving our APIs and internal functionality for stream isolation, to support a variety of usecases more like what can be done with current Tor. * Kicking off the work on a Guard implementation. This is the last key feature we need for a basic level of privacy. * Lots more interviewing job candidates. Let's see how far we get in the next two weeks!

1 0

txtorcon 21.1.0
by meejah 16 Aug '21

16 Aug '21

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I'm pleased to announce txtorcon 21.1.0. This fixes some incorrectly-skipped tests in 21.0.0 * Fix some incorrect unit-test skipping logic (thanks Jean-Paul Calderone) https://github.com/meejah/txtorcon/issues/354 and https://github.com/meejah/txtorcon/issues/352 * Fix broken tests revealed by previous fixes (thanks Jean-Paul Calderone) https://github.com/meejah/txtorcon/issues/356 You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/21.1.0 https://github.com/meejah/txtorcon/releases/tag/v21.1.0 Releases are also available from the hidden 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 aebf0b9ec6c69a029f6b61fd534e785692e28fdcd2fd003ce3cc132b9393b7d6 dist/txtorcon-21.1.0.tar.gz bcc54299e5119d6a9ace889bbefc1ff93108a204824b738e9c77bdb71f61661f dist/txtorcon-21.1.0-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCgAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAmEa1UoRHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaad3/gf/S0mneFfvY0CdqR3DyIOgjX29lIotkDzf 1SeTnLdSU2SYXj89d8TnCUONkQiFZvruGcQufASA+mbIFKC+2KwZ7BVJLlYJ9MGu Cyjt+1jr2xXGmAEVqLcDwCZM7v4BknD/W2jxZqLx3CjDuU3U1abjcJUBlt2Pq/uA B5wWK6PAxIE1rksGtk+ftMf+jMIRwTb5hNj9HynDuGzW3MFbmanyQh2eBfQPlrve 1FqmQUEaOKMM6S34mvExRIjB5/q1SNs8+zX9oAR5wrLh3NVCsiVyXtVOvU949sLy HKVm9nHzgemRrj/nsKetLahM5MYpRYFMhZVYTK+nyotK+I5tRfrXGQ== =e+mc -----END PGP SIGNATURE-----

1 0

This week's arti meeting rescheduled: 18 August, 1600 UTC
by Nick Mathewson 16 Aug '21

16 Aug '21

Hi! Because of a scheduling conflict, our biweekly Arti meeting is rescheduled (for this Wednesday only). The time this week will be at 18 August, 1600 UTC, at https://tor.meet.coop/gab-sis-ldw-xad . This week we'll be brainstorming API ideas, use cases, and user stories. Don't worry if you can't make it: we record our meetings and put them online on Tor's youtube channel. (And this won't be your last chance to influence the API; it's just an initial brainstorming session.) cheers, -- Nick

1 0

GSoC 2021 - Alexa Top Sites Captcha and Tor Block Monitoring #Update
by Apratim Ranjan Chakrabarty 09 Aug '21

09 Aug '21

Hi, Since my previous updates I've come up with a near working system that fetches data from different browsers via a control node and exit relays, and analyzes the different results, and further renders and plots the data into the localhost of the system. Areas where work is pending: + The Captcha Monitor is working and producing data-points, provided "captchamonitor-tor-container" works correctly. As of now I do have data but not much. Can check here:[0].The fault in container is that it turns unhealthy and therby the application doesn't work, as it depends upon the "captchamonitor-tor-container". Tickets regarding this are: [1],[2]. So this will be one of my tasks to complete as more the data, more will the cases to look for and access the working. + Create more graphs which would provide more insights and data to the users[3]. + Reviews from the Community: For the dashboard [0], I'll add the search bar which as of now is disabled. Further on clicking the individual Relay it redirects to the detailed page based on relay. As of now there are a lot of directions where it could be improved, one possible example could be the UI of the website. This is a field I would require some help from the community for ideas on improving it. That being said, I'm maintaining more on to-dos and resources here: [4]. Again,feel free to add more resources and discussions here as to what you feel could be added or removed and help a better working for the system. Thanks, Apratim References: [0]: http://20.85.221.64:5000/dashboard.html [1]: https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/issues/95 [2]: https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/issues/99 [3]: https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/issues/88 [4]: https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/issues/96

1 0

Arti Report 3: July 21 through August 4
by Nick Mathewson 05 Aug '21

05 Aug '21

Still quiet here for the last couple of weeks. I've been moving ahead on circuit timeout inference, and reviewing _lots_ of volunteer-submitted code (and job applications). The quiet part is coming to an end: Two of the engineers who have been on vacation or leave are back, and we're all trying to ramp up. We're also hoping to be scheduling interviews with prospective co-workers soon, so that's taking up some of our time.. but once it's done, it should accelerate our pace a bit. ## Circuit timeout inference logic I had hoped to be done with this by now, but it turns out that this code touches on several key architectural issues that we'll want to make sure we get right in the future. I'll touch on them a bit here. ### Persistent state The Tor protocol requires clients to keep persistent state across invocations in order to achieve good performance and privacy. Two notable cases of this are in the circuit management code: client need to remember circuit timeout data, and need to remember guard selection data. The C Tor client records these items in the same ad-hoc format used by Tor's configuration code. But for Rust, using serde seems like a better fit. I want to maintain the feature that Arti has now where you can run multiple processes with the same state directory. That could get tricky in the long run, but I think it's a design feature we need if we're going to keep Arti flexible enough for general use. My first implementation here is going to be bare-bones, but I'm trying to design it to grow and get replaced down the line. ### Inter-module event notification Frequently one module needs to notify another when some event occurs. In the circuit-timeout case, we need to notify the circuit manager whenever the network parameters have changed. We don't want to have the circuit manager probing the directory manager, since that's a higher-level module. And we don't want it probing the `NetDir` object it gets whenever it's time to build a circuit, since that would be a weird side-effect. The best I've been able to come up with for now is to allow the directory manager to expose a `Stream` of events for directory changes, and to have the `TorClient` object use events from that stream to alert the circuit manager to possibly changed network parameters. I think this should scale to other kinds of inter-module events in the future, though I do have a slight concern that it makes `TorClient` harder to reproduce with lower-level crates than it would be otherwise. (There's probably no avoiding that at this stage, though.) ### Non-user-initiated background tasks The circuit timeout code sometimes needs to build testing circuits in order to gather data, and the guard code does too. If we code this in a sloppy way, we'll wind up with three separate systems that all build circuits for different reasons at different times. With any luck, we can summarize the triggers from all of these circuit types into a single system. ## Coming up We've been working on refinements to the API in `arti-tor-client` to try to simplify the API as much as possible while still exposing the full back-end functionality. Everybody should expect a lot of unstability here. I am still hoping very much that the next time I write one of these reports, we'll be done with circuit timeout inference, and I can talk about API work and early progress on guards! :)

1 0

A proposal to phase out CAPTCHAs for BridgeDB
by Cecylia Bocovich 02 Aug '21

02 Aug '21

Hi everyone, We've been working on improving the usability of BridgeDB lately, and our CAPTCHAs have been a constant thorny problem. They are not accessible for blind users [0]. We've gotten many complaints over the years that they are hard to use [1], I'm sure Gus and the community team members can vent about the impact they've had on users. We even have some evidence that bots have been able to enumerate our CAPTCHAs just fine [2]. There are other anti-enumeration defences on BridgeDB that are perhaps more useful including: - partitioning bridges into buckets based on IP subnet: A user who requests bridges from a single IP address or multiple IP addresses from the same subnet won't be able to see every bridge. - time-locking access to bridges: The set of bridges that BridgeDB distributes to users during a single time period is locked to a small number. Repeated requests for bridges during that time period will return the same 3 bridges to the user. We haven't done a lot of experimenting with tuning these parameters to slow bridge enumeration attempts. For the most part, on the country level, censors that are willing to put the effort into blocking BridgeDB bridges seem to be pretty effective at it regardless of CAPTCHAs. The GFW blocked all of the new bridges from our 2019 bridge campaign in less than a month [3]. There was a recent case of censorship in Belarus where state censors blocked all of BridgeDB's email distributed bridges, but weren't able to enumerate bridges distributed over Moat or HTTPS [4]. It's possible that that CAPTCHAs were the reason behind this, but it's hard to know for sure. I would like to propose that we remove the CAPTCHAs from BridgeDB entirely, but I'd like to know whether there is research out there *specifically that fits with the anti-censorship context* showing that these CAPTCHAs are actually doing useful work to prevent Bridge enumeration. But, even if the CAPTCHAs are preventing a small number of censors from enumerating more bridges, is the usability impact worth what marginal benefit we get from it? Options for how to move forward: Option 1: Just remove the CAPTCHAs already! We're tired of waiting and just want our bridges. Option 2: Do some science? We could make a new distribution bucket in BridgeDB that distributes bridges through Moat without a CAPTCHA and have new versions of Tor Browser pull from this bucket. We can watch and perform measurements in places we know enumeration attempts have occurred in the past and see whether these bridges are enumerated more quickly and more completely than the old-school Moat bucket. Option 3: Keep doing what we're doing but try to make the CAPTCHAs more usable. This is the work we've had planned, but will only get us so far. Endpoint enumeration is a tricky topic and we do have some other alternatives in the pipeline. Conjure is more of a "blocking resistance through collateral damage" approach that's somewhat similar to domain fronting [5]. We've been looking at and hope to do more work in the future on reputation-based bridge distribution [6]. I see these as more promising than CAPTCHAs in the long run, and CAPTCHA-less BridgeDB bridges seem to still fill a need that built-in bridges and private bridges don't fill. I'd appreciate any thoughts, comments, or experiences others have! Cecylia [0] https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/10831 [1] https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/24607 [2] https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/32117 [3] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfs… [4] https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/blo… [5] https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/9 [6] https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31873

4 3

Scalability or Onionbalance for v3 ephemeral/ADD_ONION services
by Chad Retz 26 Jul '21

26 Jul '21

A quick glance at the code shows that ADD_ONION (i.e. "ephemeral" onion services) doesn't support setting an Onionbalance frontend/master onion address (specifically https://gitlab.torproject.org/tpo/core/tor/-/issues/32709 doesn't seem to have a control-side analogue). Would a feature request for adding a `*(SP "OnionbalanceMasterKey=" OBKey)` (or "OBMasterKey" or whatever) to ADD_ONION be reasonable? If so, just add in Gitlab? Also curious alternative scalability and load balancing options for ephemeral v3 onion services. I have read https://www.benthamsgaze.org/wp-content/uploads/2015/11/sucu-torscaling.pdf but unsure if anything more recent has been written. Beyond that and Onionbalance, any other interesting approaches I could employ (assuming I can dev anything from a control port pov, but am wanting to work w/ an unmodified Tor binary)? Thanks, Chad

3 5

A series of questions about Tor (m1 support, forward secrecy, v3 auth)
by Holmes Wilson 26 Jul '21

26 Jul '21

Hi everyone, A few disjointed questions that have come up recently in our work with Tor: 1. PERFORMANCE ON M1 / ARM64 We just got a report from a user that the tor binary for Mac was using much more CPU on Apple Silicon / M1 than it used on Intel. Has anyone scene anything like this? Is there an arm64 build of tor binary for Mac, existing or in the works? (Related: do Tor developers have a few M1 Macs to test on? We could probably donate one if not!) 2. FORWARD SECRECY Is there a good source for documentation on how forward secrecy works in Tor, and on what security guarantees it provides? Googling finds things like this reddit post (https://www.reddit.com/r/TOR/comments/cryrjx/does_tor_use_pfs/) but I can’t find any detailed information about it, what threat models it fits, etc. One specific question is, if two users are communicating by sending messages over a connection to an onion service (like ricochet) and an attacker surveils their internet traffic and compromises their devices at a later date, will the attacker be able to recover the clear text of their conversation? When are keys for a given connection destroyed? Does it happen continuously throughout the course of a Tor connection? Or on the creation of a new circuit? Or what? 3. V3 AUTH AND DOS ATTACKS Does v3 onion authentication protect against DOS attacks? That is, can someone who is not authorized to connect to an onion address with authentication enabled still cause problems for that onion address? Can they connect to it at all, in the sense of being able to send data to the tor client at that onion address? Or does the Tor network itself prevent this connection from even happening? A related question is, if we’re looking to deny connections to an onion address to any unauthorized users, and we’re considering turning off onion authentication and implementing some standard authentication scheme that seems fairly well-supported at the web server layer, is there any security-related reason why we would be better off using Tor’s own authentication instead? Using our own authentication scheme will be a bit easier to control, rather than having to send commands to Tor (and possibly restart it for removing users?) but I’m wondering if there are security properties we lose by doing that. Thanks! Also, apologies if any of these questions aren’t clear or well-formed! Holmes

4 4

The Tor Project hiring software engineers
by Gaba 22 Jul '21

22 Jul '21

Hi! We have a few positions open right now. Please apply or share it in your networks! Rust developers for the network team (to work on Arti): http://torproject.org/about/jobs/rust-dev/index.html Anti-censorship engineer to work mostly in Go and with focus on China: http://torproject.org/about/jobs/software-developer-anticensorship-2/index.… C++ and Javascript developer to work with our applications team (the one maintaining Tor Browser): http://torproject.org/about/jobs/software-engineer-applications-team/ Thanks! -- pronouns she/her/they GPG Fingerprint EE3F DF5C AD91 643C 21BE 8370 180D B06C 59CA BD19

1 0