- tor-dev - lists.torproject.org

[prop305] Introduction Point Behavior
by David Goulet 20 Aug '19

20 Aug '19

Greetings, This is part of the many discussions about proposal 305 which is the ESTABLISH_INTRO DoS defenses cell extension. Implementation is close to done and under review in ticket #30924. However, there is one part that is yet to be cleared out. asn and I thought it would be better to bring it to tor-dev@ to get a more informed decision. As a reminder, the service operator will be able set torrc options that are the DoS defenses parameters. Those values are validated (bound check) and then sent to an introduction point, supporting the extension (protover HSIntro=5), in the ESTABLISH_INTRO cell. The intro point then gets them and apply them only to that specific circuit. If no cell extension is seen, the intro point will honor the consensus parameters for these DoS defenses. What we want to discuss is what happened when the introduction points receives bad values. What does it do with the circuit? Below is the list of possible bad values and the proposed behavior: 1) One of the paramater (at this point in time, only 2 exists) is out of bound that is above INT32_MAX. Behavior: We propose to ignore the cell extension, and fallback to follow the consensus parameters. Keeping the circuit alive and working. The reason for this is because if let say the intro point would close the circuit due to "bad protocol", then the service would open a new circuit to an intro point supporting the extension and it would fail again. Effectively turning the service into a "zombie" and "DoS" weapon itself ;). At this point, there is really no reason on why the service would send bad values since torrc options are validated and then sent to the intro point. But this doesn't protect us from our future-developer-self making coding or protocol mistake ;). 2) A parameter type is unrecognized. This one is mostly about forward compatibility. Behavior: Ignore the parameter type, and continue parsing the cell extension. If all the right parameters are found, apply defenses. 3) None or 1 parameter out of 2 is given. Behavior: This would be considered bad protocol so it would be like (1) where the intro point uses the consensus parameters. 4) <insert whatever case you can think about> So, for (1) and (3), there lies mostly the discussion. There is no way to send feedback to the service if a problem occurred and that the DoS defenses weren't applied due to reason X. If we had that, we could not only try to warn the operator (log or control event) but make tor smarter when an error is returned so it doesn't try to infinity other intro points with values that makes them fail. One avenue there is to pass down such error code into the INTRO_ESTABLISHED cell with probably a new extension. That requires more work and likely either extending prop305 or a new proposal. Thus, what is the minimal viable product here we are ok with? I'm leaning towards not closing the circuit and falling back on the consensus parameters. And at some point in time, we'll be able to implement the INTRO_ESTABLISHED response. In the meantime, there is little chances that tor vanilla start sending bad values since they are validated from the torrc file. Cheers! David -- eHE50zZRZOX3zLNHdPwN5gGQBUvDnfGyOuYr/afK2XY=

3 2

Re: [tor-dev] TBB Memory Allocator choice fingerprint implications
by procmem＠riseup.net 17 Aug '19

17 Aug '19

*On Sat, 17 Aug 2019 at**21:17, Tom Ritter* <tom at ritter.vg <mailto:tor-dev%40lists.torproject.org?Subject=Re%3A%20%5Btor-dev%5D%20TBB%20Memory%20Allocator%20choice%20fingerprint%20implications&In-Reply-To=%3CCA%2BcU71%3DPeZGCAJNsPQy9QpKY9%3Dwz3vPdW8QKruF_ZwyanoyYzQ%40mail.gmail.com%3E>> wrote: > On Sat, 17 Aug 2019 at 15:06, procmem at riseup.net <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev> <procmem at riseup.net <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev>> wrote: > >/Question for the Tor Browser experts. Do you know if it is possible to />/remotely fingerprint the browser based on the memory allocator it is />/using? (via JS or content rendering) / > Fingerprint what aspect of the browser/machine? I'm not really sure (I'm of the opinion it should not matter) and so I'm curious as to what could be affected if anything. Some members of our team are divided about making it the default because of unknown consequences which is what I'm trying to clear up. > >/We are thinking of switching Tor Browser to use the minimalist and />/security oriented hardened_malloc written by Daniel Micay. Thanks. / > I wouldn't advise giving up partitioning for.... what exactly? What > features does this allocator have that 68's jemalloc doesn't? > > -tom So the original suggestion [0] was prompted by past research done by the Tor Browser team for a jemalloc alternative. [1] Hardened_malloc wasn't around back then so it may be a worthy alternative for you guys to switch to too. Hardened_malloc has a partitioned heap among many other defenses implemented if I understand their label correctly (please see "Security properties" section in [2]). Also available on ARM. [0] https://forums.whonix.org/t/hardened-malloc/7474 [1] https://trac.torproject.org/projects/tor/ticket/10281 [2] https://github.com/GrapheneOS/hardened_malloc *** PS. A related debate is on whether we should enable Apparmor and Firejail sandboxing for Tor Browser by default, but again we don't know if restriction to resources and file paths on the machine is something that is remotely detectable as an anomaly or not, ruining the fingerprint in the process. Input is appreciated. related thread: https://forums.whonix.org/t/tor-browser-hardening-hardened-malloc-firejail-…

1 0

24 hours worth of BridgeDB usage metrics
by Philipp Winter 30 Jul '19

30 Jul '19

Over at <https://bugs.torproject.org/9316>, we are working on having BridgeDB export metrics. The patch is almost done and I deployed the work-in-progress code on BridgeDB, so we can take a look at the metrics and think of ways to improve them. The metrics format encodes the approximate number of requests per distribution mechanism per transport per country per success/fail. All numbers are rounded up to the next multiple of 10. The last field, "none", will be used for an anomaly score and is currently unused. For example, the line bridgedb-metric-count email.obfs4.riseup.success.none 10 tells us that there have been 1-10 successful email requests for obfs4 coming from Riseup addresses. I attached 24 hours worth of metrics to this email. Keep the following issues in mind: * My feature branch hasn't been reviewed yet and likely still has bugs, so take all numbers with a grain of salt. * The country codes are based on Debian stretch's geoip-database, which is slightly outdated and uses Maxmind's far-from-perfect GeoLite database. * The country code "??" refers to geo-location failure or lack of IP addresses (in the cast of moat). The country code "zz" refers to a request from a Tor exit relay. Some observations: * Gmail sees much more use than Riseup. That's no surprise. * The email distributor sees more vanilla than obfs4 requests. I wonder to what degree this is caused by the poor UX of the email distributor. * For HTTPS, many countries have a fail and success bucket of 10 each. I would expect this to be at least one user who failed the captcha at least once before finally getting it right. * The captcha success rate for obfs4 over moat is 54%. That's very low and must cause lots of frustration for users. This is a known issue that's tracked in this ticket: <https://bugs.torproject.org/29695> * Ignore the large amount of HTTPS requests from "zz" -- I expect the vast majority of these to be a bot that's interacting with BridgeDB over exit relays. After a cursory look at the numbers, I would like to aggregate the data, to make it easier to compare distributors, transports, and countries. For example: how do moat, email, and HTTPS rank in popularity? I'll improve the patch to keep track of these numbers in separate metrics. Any thoughts or suggestions? Cheers, Philipp

3 4

What hidden services does my relay node know about?
by clive.jenson＠tutanota.com 29 Jul '19

29 Jul '19

I built tor from source and am running it as a relay (not exit node) and also as a directory server. It is my understanding that after a while I should experience V2 hidden services publishing their descriptors to me (each hidden service picks 6 directory servers at random to publish their descriptor to). How can I tell if this is happening? Can I (temporarily, for debugging purposes) view the descriptors being published to me? I'm thinking their might be some useful logging if I enable debug logs (but I can't find it)? Or maybe there is something I can get over the control protocol (but I couldn't find anything obvious in the stem API docs that exposes it)? Or maybe I could make a code change to log this information (I'm not sure where the code is that receives the announcements)?

2 4

Hack
by Pordeshi Pothik 27 Jul '19

27 Jul '19

Hi,I want to learn how to hack facebook.

2 1

Proposal 306: Onion Balance Support for Onion Service v3
by David Goulet 26 Jul '19

26 Jul '19

Greetings! Around 4 months ago, nickm published a proposal draft for OnionBalance to support onion services v3. Due to #29583, it turns out that we can afterall take the easy approach which is basically how OnionBalance is working today for v2 but transposed to v3. See the ticket for the reasons why for now we'll proceed this way. However, we all agreed that #29583 is a "must fix at some point" meaning that OnionBalance v3 will then become much more complicated. In order to not forget about it, I'm reviving nickm's proposal as prop306 so we have the draft in torspec.git. See attachement for the proposal. Cheers! David -- vjZrE+FHHEPpllrbcUukx7LtWFzk066L23yoggvnmso=

3 2

Status of open circuit padding tickets
by George Kadianakis 23 Jul '19

23 Jul '19

Hello Nick and Mike, here is a summary of the current state of open circpad tickets, which I tried to tidy up today. These are all the tickets I had in my radar and I hope I didn't miss any. I will be on leave starting the day after tomorrow (25th) so I wanted to inform you of the status quo: 0.4.1: #31024: Coverity: circpadding: always check circpad_machine_current_state() - [needs_review] - This is done and in needs_review for Mike. #30992: circpadding: Circsetup machines give out warnings when client-side intro gets NACKed - This is still unresolved and in 041. I couldn't figure out by just looking at the logs... Perhaps we could push it in 042 given that it's a pretty rare client behavior. 0.4.2: #30942: [warn] Unexpected INTRODUCE_ACK on circuit 3944288021. - I took a stab at this today since this seems to be a central issue that can cause lots of log warns. It's now in needs_review. #31112: remove specified target_hopnum from relay-side machines - [merge_ready] #31113: Circuitpadding updated comments #31098: transition when we send our first padding packet, not on received - [merge_ready] - These are all Tobias' patches. I made changes files and fixed a few of them and also made a PR. I moved them to 042 since they are not really urgent bugfixes. The only one I would consider backporting to 041 is #31098. #31002: circpadding: Middle node did not accept our padding request - [assigned] - This is still unresolved. Mike took a look during PETS but not sure what's the verdict. I pushed to 042 since it does not seem urgent but we might want to reconsider. #30578: The circuitpadding_circuitsetup_machine test: Re-enable, remove, re-document, or ___? - This is still unresolved but not urgent. I pushed it to 042. 0.4.0: #30649: Every few hours, relays [warn] Received circuit padding stop command - This was hanging on a 040 backport which I just did.

1 0

resolving DNS TXT records?
by nusenu 11 Jul '19

11 Jul '19

Hi, as far as I can tell there is no way for a tor client to ask an exit to resolve a given TXT record and to provide the answer for it. Just wanted to make sure there is even no hack around that limitation. thanks, nusenu https://gitweb.torproject.org/torspec.git/tree/proposals/219-expanded-dns.t… -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

2 1

New revision: Proposal 295: Using ADL for relay cryptography (solving the crypto-tagging attack)
by Nick Mathewson 11 Jul '19

11 Jul '19

Hi! I'm sending a new version of proposal 295 from Tomer Ashur, Orr Dunkelman, and Atul Luykx. It's an updated version of their design for an improved relay cell encryption scheme, to prevent tagging attacks. This proposal is checked into the torspec repository. I'm also linking to a diagram for this scheme (and its latex source) from Atul Luykx: https://people.torproject.org/~nickm/prop295/ Finally, I have a draft python reference implementation for an older version of this proposal. I hope to be updating it soon and sending out a link next week. cheers! -- Nick Filename: 295-relay-crypto-with-adl.txt Title: Using ADL for relay cryptography (solving the crypto-tagging attack) Author: Tomer Ashur, Orr Dunkelman, Atul Luykx Created: 22 Feb 2018 Last-Modified: 1 March 2019 Status: Open 0. Context Although Crypto Tagging Attacks were identified already in the original Tor design, it was not before the rise of the Procyonidae in 2012 that their severity was fully realized. In Proposal 202 (Two improved relay encryption protocols for Tor cells) Nick Mathewson discussed two approaches to stymie tagging attacks and generally improve Tor's cryptography. In Proposal 261 (AEZ for relay cryptography) Mathewson puts forward a concrete approach which uses the tweakable wide-block cipher AEZ. This proposal suggests an alternative approach to Proposal 261 using the notion of Release (of) Unverified Plaintext (RUP) security. It describes an improved algorithm for circuit encryption based on CTR-mode which is already used in Tor, and an additional component for hashing. Incidentally, and similar to Proposal 261, this proposal employs the ENCODE-then-ENCIPHER approach thus it improves Tor's E2E integrity by using (sufficient) redundancy. For more information about the scheme and a security proof for its RUP-security see Tomer Ashur, Orr Dunkelman, Atul Luykx: Boosting Authenticated Encryption Robustness with Minimal Modifications. CRYPTO (3) 2017: 3-33 available online at https://eprint.iacr.org/2017/239 . For authentication between the OP and the edge node we use the PIV scheme: https://eprint.iacr.org/2013/835 2. Preliminaries 2.1 Motivation For motivation, see proposal 202. 2.2. Notation Symbol Meaning ------ ------- M Plaintext C_I Ciphertext CTR Counter Mode N_I A de/encryption nonce (to be used in CTR-mode) T_I A tweak (to be used to de/encrypt the nonce) T'_I A running digest ^ XOR || Concatenation (This is more readable than a single | but must be adapted before integrating the proposal into tor-spec.txt) 2.3. Security parameters HASH_LEN -- The length of the hash function's output, in bytes. PAYLOAD_LEN -- The longest allowable cell payload, in bytes. (509) DIG_KEY_LEN -- The key length used to digest messages (e.g., using GHASH). Since GHASH is only defined for 128-bit keys, we recommend DIG_KEY_LEN = 128. ENC_KEY_LEN -- The key length used for encryption (e.g., AES). We recommend ENC_KEY_LEN = 128. 2.4. Key derivation (replaces Section 5.2.2) For newer KDF needs, Tor uses the key derivation function HKDF from RFC5869, instantiated with SHA256. The generated key material is: K = K_1 | K_2 | K_3 | ... where, if H(x,t) denotes HMAC_SHA256 with value x and key t, and m_expand denotes an arbitrarily chosen value, and INT8(i) is an octet with the value "i", then K_1 = H(m_expand | INT8(1) , KEY_SEED ) and K_(i+1) = H(K_i | m_expand | INT8(i+1) , KEY_SEED ), in RFC5869's vocabulary, this is HKDF-SHA256 with info == m_expand, salt == t_key, and IKM == secret_input. When used in the ntor handshake a string of key material is generated and is used in the following way: Length Purpose Notation ------ ------- -------- HASH_LEN forward digest IV DF * HASH_LEN backward digest IV DB * ENC_KEY_LEN encryption key Kf ENC_KEY_LEN decryption key Kb DIG_KEY_LEN forward digest key Khf DIG_KEY_LEN backward digest key Khb ENC_KEY_LEN forward tweak key Ktf ENC_KEY_LEN backward tweak key Ktb DIGEST_LEN nonce to use in the * hidden service protocol * I am not sure that we need these any longer. Excess bytes from K are discarded. 2.6. Ciphers For hashing(*) we use GHASH with a DIG_KEY_LEN-bit key. We write this as Digest(K,M) where K is the key and M the message to be hashed. We use AES with an ENC_KEY_LEN-bit key. For AES encryption (resp., decryption) we write E(K,X) (resp., D(K,X)) where K is an ENC_KEY_LEN-bit key and X the block to be encrypted (resp., decrypted). For a stream cipher, unless otherwise specified, we use ENC_KEY_LEN-bit AES in counter mode, with a nonce that is generated as explained below. We write this as Encrypt(K,N,X) (resp., Decrypt(K,N,X)) where K is the key, N the nonce, and X the message to be encrypted (resp., decrypted). (*) The terms hash and digest are used interchangeably. 3. Routing relay cells 3.1. Forward Direction The forward direction is the direction that CREATE/CREATE2 cells are sent. 3.1.1. Routing from the Origin Let n denote the integer representing the destination node. For I = 1...n+1, T'_{I} is initialized to the 128-bit string consisting entirely of '0's. When an OP sends a relay cell, they prepare the cell as follows: The OP prepares the authentication part of the message: C_{n+1} = M T_{n+1} = Digest(Khf_n,T'_{n+1}||C_{n+1}) N_{n+1} = T_{n+1} ^ E(Ktf_n,T_{n+1} ^ 0) T'_{n+1} = T_{n+1} Then, the OP prepares the multi-layered encryption: For I=n...1: C_I = Encrypt(Kf_I,N_{I+1},C_{I+1}) T_I = Digest(Khf_I,T'_I||C_I) N_I = T_I ^ E(Ktf_I,T_I ^ N_{I+1}) T'_I = T_I The OP sends C_1 and N_1 to node 1. 3.1.2. Relaying Forward at Onion Routers When a forward relay cell is received by OR I, it decrypts the payload with the stream cipher, as follows: 'Forward' relay cell: T_I = Digest(Khf_I,T'_I||C_I) N_{I+1} = T_I ^ D(Ktf_I,T_I ^ N_I) C_{I+1} = Decrypt(Kf_I,N_{I+1},C_I) T'_I = T_I The OR then decides whether it recognizes the relay cell as described below. If the OR recognizes the cell, it processes the contents of the relay cell. Otherwise, it passes C_{I+1}||N_{I+1} along the circuit if the circuit continues. For more information, see section 4 below. 3.2. Backward Direction The backward direction is the opposite direction from CREATE/CREATE2 cells. 3.2.1. Relaying Backward at Onion Routers When a backward relay cell is received by OR I, it encrypts the payload with the stream cipher, as follows: 'Backward' relay cell: T_I = Digest(Khb_I,T'_I||C_{I+1}) N_I = T_I ^ E(Ktb_I,T_I ^ N_{I+1}) C_I = Encrypt(Kb_I,N_I,C_{I+1}) T'_I = T_I with C_{n+1} = M and N_{n+1}=0. Once encrypted, the node passes C_I and N_I along the circuit towards the OP. 3.2.2. Routing to the Origin When a relay cell arrives at an OP, the OP decrypts the payload with the stream cipher as follows: OP receives relay cell from node 1: For I=1...n, where n is the end node on the circuit: C_{I+1} = Decrypt(Kb_I,N_I,C_I) T_I = Digest(Khb_I,T'_I||C_{I+1}) N_{I+1} = T_I ^ D(Ktb_I,T_I ^ N_I) T'_I = T_I If the payload is recognized (see Section 4.1), then: The sending node is I. Stop, process the payload and authenticate. 4. Application connections and stream management 4.1. Relay cells Within a circuit, the OP and the end node use the contents of RELAY packets to tunnel end-to-end commands and TCP connections ("Streams") across circuits. End-to-end commands can be initiated by either edge; streams are initiated by the OP. The payload of each unencrypted RELAY cell consists of: Relay command [1 byte] 'Recognized' [2 bytes] StreamID [2 bytes] Length [2 bytes] Data [PAYLOAD_LEN-23 bytes] The 'recognized' field is used as a simple indication that the cell is still encrypted. It is an optimization to avoid calculating expensive digests for every cell. When sending cells, the unencrypted 'recognized' MUST be set to zero. When receiving and decrypting cells the 'recognized' will always be zero if we're the endpoint that the cell is destined for. For cells that we should relay, the 'recognized' field will usually be nonzero, but will accidentally be zero with P=2^-16. If the cell is recognized, the node moves to verifying the authenticity of the message as follows(*): forward direction (executed by the end node): T_{n+1} = Digest(Khf_n,T'_{n+1}||C_{n+1}) Tag = T_{n+1} ^ D(Ktf_n,T_{n+1} ^ N_{n+1}) T'_{n+1} = T_{n+1} The message is authenticated (i.e., M = C_{n+1}) if and only if Tag = 0 backward direction (executed by the OP): The message is authenticated (i.e., C_{n+1} = M) if and only if N_{n+1} = 0 The old Digest field is removed since sufficient information for authentication is now included in the nonce part of the payload. (*) we should consider dropping the 'recognized' field altogether and always try to authenticate. Note that this is an optimization question and the crypto works just as well either way. The 'Length' field of a relay cell contains the number of bytes in the relay payload which contain real payload data. The remainder of the payload is padding bytes. 4.2. Appending the encrypted nonce and dealing with version-homogenic and version-heterogenic circuits When a cell is prepared to be routed from the origin (see Section 3.1.1) the encrypted nonce N is appended to the encrypted cell (occupying the last 16 bytes of the cell). If the cell is prepared to be sent to a node supporting the new protocol, S is combined with other sources to generate the layer's nonce. Otherwise, if the node only supports the old protocol, n is still appended to the encrypted cell (so that following nodes can still recover their nonce), but a synchronized nonce (as per the old protocol) is used in CTR-mode. When a cell is sent along the circuit in the 'backward' direction, nodes supporting the new protocol always assume that the last 16 bytes of the input are the nonce used by the previous node, which they process as per Section 3.2.1. If the previous node also supports the new protocol, these cells are indeed the nonce. If the previous node only supports the old protocol, these bytes are either encrypted padding bytes or encrypted data. 5. Security 5.1. Resistance to crypto-tagging attacks A crypto-tagging attack involves a circuit with two colluding nodes and at least one honest node between them. The attack works when one node makes a change to the cell (tagging) in a way that can be undone by the other colluding party. In between, the tagged cell is processed by honest nodes which do not detect the change. The attack is possible due to the malleability property of CTR-mode: a change to a ciphertext bit effects only the respective plaintext bit in a predicatble way. This proposal frustrates the crypto-tagging attack by linking the nonce to the encrypted message such that any change to the ciphertext results in a random nonce and hence, random plaintext. Let us consider the following 3-hop scenario: the entry and end nodes are malicious and colluding and the middle node is honest. 5.1.1. forward direction Suppose that node I tags the ciphertext part of the message (C'_{I+1} != C_{I+1}) then forwards it to the next node (I+1). As per Section 3.1.2. Node I+1 digests C'_{I+1} to generate T_{I+1} and N_{I+2}. Since C'_{I+2} is different than it should be, so are the resulting T_{I+1} and N_{I+2}. Hence, decrypting C'_{I+2} using these values results in a random string for C_{I+2}. Since C_{I+2} is now just a random string, it is decrypted into a random string and cannot be 'recognized' nor authenticated. Furthermore, since C'_{I+1} is different than what it should be, T'_{I+1} (i.e., the running digest of the middle node) is now out of sync with that of the OP, which means that all future cells sent through this node will decrypt into garbage (random strings). Likewise, suppose that instead of tagging the ciphertext, Node I node tags the encrypted nonce N'_{I+1} != N_{I+1}. Now, when Node I+1 digests the payload the tweak T_{I+1} is find, but using it to decrypt N'_{I+1} again results in a random nonce for N_{I+2}. This random nonce is used to decrypt C_{I+1} into a random C'_{I+2} which is not recognized by the end node. Since C_{I+2} is now a random string, the running digest of the end node is now out of sync, which prevents the end node from decrypting further cells. 5.1.2. Backward direction In the backward direction the tagging is done by Node I+2 untagging by the Node I. Suppose first that Node I+2 tags the ciphertext C_{I+2} and sends it to Node I+1. As per Section 3.2.1, Node I+1 first digests C_{I+2} and uses the resulting T_{I+1} to generate a nonce N_{I+1}. From this it is clear that any change introduced by Node I+2 influences the entire payload and cannot be removed by Node I. Unlike in Section 5.1.1., the cell is blindly delivered by Node I to the OP which decrypts it. However, since the payload leaving the end node was modified, the message cannot be authenticated by the OP which can be trusted to tear down the circuit. Suppose now that tagging is done by Node I+2 to the nonce part of the payload, i.e., N_{I+2}. Since this value is encrypted by Node I+1 to generate its own nonce N_{I+1}, again, a random nonce is used which affects the entire keystream of CTR-mode. The cell again cannot be authenticated by the OP and the circuit is torn down. We note that the end node can modify the plain message before ever encrypting it and this cannot be discovered by the Tor protocol. This vulnerability is outside the scope of this proposal and users should always use TLS to make sure that their application data is encrypted before it enters the Tor network. 5.2. End-to-end authentication Similar to the old protocol, this proposal only offers end-to-end authentication rather than per-hop authentication. However, unlike the old protocol, the ADL-construction is non-malleable and hence, once a non-authentic message was processed by an honest node supporting the new protocol, it is effectively destroyed for all nodes further down the circuit. This is because the nonce used to de/encrypt all messages is linked to (a digest of) the payload data. As a result, while honest nodes cannot detect non-authentic messages, such nodes still destroy the message thus invalidating its authentication tag when it is checked by edge nodes. As a result, security against crypto-tagging attacks is ensured as long as an honest node supporting the new protocol processes the message between two dishonest ones. 5.3 The Running Digest Unlike the old protocol, the running digest is now computed as the output of a GHASH call instead of a hash function call (SHA256). Since GHASH does not provide the same type of security guarantees as SHA256, it is worth discussing why security is not lost from computing the running digest differently. The running digets is used to ensure that if the same payload is encrypted twice, then the resulting ciphertext does not remain the same. Therefore, all that is needed is that the digest should repeat with low probability. GHASH is a universal hash function, hence it gives such a guarantee assuming its key is chosen uniformly at random.

3 4

Current plans for 0.4.1.x stable
by Nick Mathewson 09 Jul '19

09 Jul '19

Hi! We're currently on track to get a stable release out on the planned release date (August 15), which would be seriously impressive for us. To do this, we'll need to get a release candidate out by late July. And in order to do _that_, we'll need to prioritize the remaining 0.4.1.x tickets. Here are all the tickets currently labeled with the "041-should" and "041-must" keywords: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… Are any of these tickets items that we must do before 0.4.1.x can be stable? If so, we should label them with 041-must. Please let us know on the ticket if there is any must-do ticket _not_ labelled with 041-must. Additionally, we should mark all the items (typically CI-related) that we can safely merge post-release. best wishes, -- Nick

1 0

exitmap/RESOLVE control command limitations
by nusenu 09 Jul '19

09 Jul '19

Hi, I noticed some unexpected answers in exitmap's [1] dnsenum results and suspected that this has todo with IPv4 vs. IPv6. First I looked at [2] and found that it only lists IPv4 and hostnames as possible answers but then I realized that exitmap might not be using the RESOLVE command? > def resolve(self, domain): > """ > Resolve the given domain using Tor's SOCKS resolution extension. > """ > > domain_len = len(domain) > if domain_len > 255: > raise error.SOCKSv5Error("Domain must not be longer than 255 " > "characters, but %d given." % domain_len) > > # Tor defines a new command value, \x0f, that is used for domain > # resolution. > > self._send_all("\x05\xf0\x00\x03%s%s%s" % > (chr(domain_len), domain, "\x00\x00")) > > resp = self._recv_all(10) > if resp[:2] != "\x05\x00": > raise error.SOCKSv5Error("Invalid server response: 0x%s" % > resp[1].encode("hex")) > > return socket.inet_ntoa(resp[4:8]) Does Tor's SOCKS resolution extension support IPv6 answers or does it only attempt A records? I'm aiming to resolve a hostname and would like to get the IPv4 and if available the IPv6 address. thanks, nusenu [1] https://github.com/NullHypothesis/exitmap [2] https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n1349 -- https://twitter.com/nusenu_

2 4

Fwd: Re: Onion Service - Intropoint DoS Defenses
by juanjo 08 Jul '19

08 Jul '19

-------- Forwarded Message -------- Subject: Re: [tor-dev] Onion Service - Intropoint DoS Defenses Date: Thu, 4 Jul 2019 20:38:48 +0200 From: juanjo <juanjo(a)avanix.es> To: David Goulet <dgoulet(a)torproject.org> These experiments and final note confirm what I thought about this rate limiting feature from the start: it is missing important parts. Ok, you can protect the network a little and the HS, but the general availability is not affected so it actually does not help for that. I wanna make a proposal including many things at the same time, but I don't have much time to follow the guidelines to make a official proposal. Maybe in some weeks? Again, I repeat: things that should be done now: -Authenticated rend signature. This would help a lot I think. -Mid-term: PoW for the client when reaching the 305prop limit instead of denying access? IDK, all always configurable. -Deprecate clients or allow the Hidden Service to configure the IP to allow access for old version clients (not supporting new antiDoS features) or not. If we allow old version without protections, all security measures are useless. And just a new idea: what about make the rotation of IP dynamic based on this prop305 values? + time based rotation: One of the goal for rotation was defending against correlation attacks: if we set a lower limit we have a potential DoS (right now), if we set it high we have a potential correlation attack, bigger surface. What about we join time based rotation (ex. 24 hours) + or limit reached based on the prop305 values. On 3/7/19 20:37, David Goulet wrote: > On 30 May (09:49:26), David Goulet wrote: >> Greetings! > [snip] > > Hi everyone, > > I'm writing here to update on where we are about the introduction rate > limiting at the intro point feature. > > The branch of #15516 (https://trac.torproject.org/15516) is ready to be merged > upstream which implements a simple rate/burst combo for controlling the amount > of INTRODUCE2 cells that are relayed to the service. > > As previously detailed in this thread, the default values are a rate of 25 > introduction per second and a burst of 200 per second. These values can be > controlled by consensus parameters meaning they can be changed network wide. > > We've first asked big service operators, I'm not going to detail the values > they provided us in private, but those defaults are quite large enough to > sustain heavy traffic from what we can tell from what they gave us. > > The second thing we did is do experimental testing to see how CPU usage and > availability is affected. We've tested this with 3 _fast_ introduction points > and then 3 rate limited introduction points. > > The good news is that once the attack stops, the rain of introduction requests > to the service stops very quickly. > > With the default rate/burst values, on a Intel(R) Xeon(R) CPU E5-2650 v4 @ > 2.20GHz (8 cores), the tor service CPU doesn't go above ~60% (on one single > core). And almost drops to 0 as soon as the attack ends. > > The bad news is that availability is _not_ improved. One of the big reasons > for that is because the rate limit defenses, once engaged at the intro point, > will send back a NACK to the client. A vanilla tor client will stop using that > introduction point away for 120 seconds if it gets 3 NACKs from it. This leads > to tor quickly giving up on trying to connect and thus telling the client that > connection is impossible to the .onion. > > We've hacked a tor client to play along and stop ignoring the NACKs to see how > much time it would take to reach it. On average, a client would roughly need > around 70 seconds with more than 40 NACKs on average. > > However, it varied a _lot_ during our experiments with many outliers from 8 > seconds with 1 NACK up to 160 seconds with 88 NACKs. (For this, the > SocksTimeout had to be bumped quite a bit). > > There is an avenue of improvement here to make the intro point sends a > specific NACK reason (like "Under heavy load" or ...) which would make the > client consider it like "I should retry soon-ish" and thus making the client > possibly able to connect after many seconds (or until the SocksTimeout). > > Another bad news there! We can't do that anytime soon because of this bug that > basically crash clients if an unknown status code is sent back (that is a new > NACK value):https://trac.torproject.org/30454. So yeah... quite unfortunate > there but also a superb reason for everyone out there to upgrade :). > > One good news is that it seems that having fast intro points instead of slow > IPs doesn't change much on the overall load on the service so this for now, > our experiment, shows it doesn't matter. > > Overall, this rate limit feature does two things: > > 1. Reduce the overall network load. > > Soaking the introduction requests at the intro point helps avoid the > service creating pointless rendezvous circuits which makes it "less" of an > amplification attack. > > 2. Keep the service usable. > > The tor daemon doesn't go in massive CPU load and thus can be actually used > properly during the attack. > > The problem with (2) is the availability part where for a legit client to > reach the service, it is close to impossible for a vanilla tor without lots of > luck. However, if let say the tor daemon would be configured with 2 .onion > where one is public and the other one is private with client authorization, > then the second .onion would be totally usable due to the tor daemon not being > CPU overloaded. > > As a third thing we did about this. In order to make this feature a bit more > "malleable", we are working onhttps://trac.torproject.org/30924 which is > proposal 305. > > In short, torrc options are added so an operator can change the rate/burst > that the intro points will use. We can do that using the ESTABLISH_INTRO cell > that will have an extension to define the DoS defensavailability > e parameters (proposal > 305). > > That way, a service operator can disable this feature, or turn the knobs on > the rate/burst in order to basically adjust the defenses. > > At this point in time, we don't have a good grasp on what happens in terms of > CPU if the rate or the burst is bumped up or even how availability is > affected. During our experimentation, we did observed a "sort of" linear > progression between CPU usage and rate. But we barely touched the surface > since it was changed from 25 to 50 to 75 and that is it. > > We would require much more experimentation which is something we want to avoid > as much as possible on the real network. > > Finally, many more changes are cooking up. One in particular is > https://trac.torproject.org/projects/tor/ticket/26294 that will make tor to > only rotate its intro points when the number of introduction requests is > between 150k to 300k (random value) which currently is between 16k and 32k. > See the ticket for the benefits here which mostly helps with (1). > > There has been much talk about a client PoW (see the proposal 305 thread on > this list) which in theory would help out with service availability. > > We will also soon merge upstream this tickethttps://trac.torproject.org/24962 > which goes one step further at denying single-hop connections to the > HSDir/Intro in order to try as much as possible to shutdown the Tor2web > connections (or any attacker that speeds things up on their side by single > hoping). > > We are making progress here... This is really a non trivial problem and > solution for service availability are not that simple. Our priority is to > protect the network as much as possible and then move to possible solutions > for availability. > > I'll stop for now. Huge thanks to everyone who provided service logs, ideas, > code review and future testers :). > > Cheers! > David > > > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

2 1

Onion Service - Intropoint DoS Defenses
by David Goulet 05 Jul '19

05 Jul '19

Greetings! As some of you know, a bunch of onion services were or are still under heavy DDoS on the network. More specifically, they are bombarded with introduction requests (INTRODUCE2 cells) which forces them to rendezvous for each of them by creating a ton of circuits. This basically leads to a resource exhaustion attack on the service side with its CPU massively used for path selection, opening new circuits and continously handling INTRODUCE2 cells. Unfortunately, our circuit-level flow control does not apply to the service introduction circuit which means that the intro point is allowed, by the Tor protocol, to send an arbitrary large amount of cells down the circuit. This means for the service that even after the DoS has stopped, it would still receive massive amounts of cells because some are either inflight on the circuit or queued at the intro point ready to be sent (towards the service). That being all said, our short-term goal here is to add INTRODUCE2 rate-limiting (similar to the Guard DoS subsystem deployed early last year) *at* the intro point but much simpler. The goal is to soak up the introduction load directly at the intro points which would help reduce the load on the network overall and thus preserve its health. Please have a look at https://trac.torproject.org/15516 for some discussions and ongoing code work. We are at the point where we have a branch that rate limits INTRODUCE2 cells at the intro point but we need to figure out proper values for the rate per second and the burst allowed. One naive approach is to see how much cells an attack can send towards a service. George and I have conducted experiment where with 10 *modified* tor clients bombarding a service at a much faster rate than 1 per-second (what vanilla tor does if asked to connect a lot), we see in 1 minute ~15000 INTRODUCE2 cells at the service. This varies in the thousands depending on different factors but overall that is a good average of our experiment. This means that 15000/60 = 250 cells per second. Considering that this is an absurd amount of INTRODUCE2 cells (maybe?), we can put a rate per second of let say a fifth meaning 50 and a burst of 200. Over the normal 3 intro points a service has, it means 150 introduction per-second are allowed with a burst of 600 in total. Or in other words, 150 clients can reach the service every second up to a burst of 600 at once. This probably will ring alarms bell for very popular services that probably gets 1000+ users a second so please check next section. I'm not that excited about hardcoded network wide values so this is why the next section is more exciting but much more work for us! One step further: we have not really decided yet if this is something we want nor have time to tackle but an idea here would be for a service to inform the intro point, using the ESTABLISH_INTRO cell payload, on the parameters it wants for its DoS defenses. So let say a very popular .onion with OnionBalance and 10 intro points, could tell to its intro points that it wants much higher values for the DoS defenses (or even put it off). However, it doesn't change the initial building block of being able to rate limit at the introduction point. As a second step, we can add this new type of ESTABLISH_INTRO cell. It is always dicy to introduce a new cell since for instance this would leak information to the intro point that the service is ">= version". Thus, this needs to be done with carefully. Time for your thoughts and help! :) Thanks everyone! David -- g6fXJTHx8+aXYB1ZLPzFft/VxRukF1Td5nborX04XM0=

6 15

Proposal 303: When and how to remove support for protocol versions
by Nick Mathewson 05 Jul '19

05 Jul '19

Filename: 303-protover-removal-policy.txt Title: When and how to remove support for protocol versions Author: Nick Mathewson Created: 21 May 2019 Status: Draft 1. Background With proposal 264, added support for "subprotocol versions" -- a means to declare which features are required for participation in the Tor network. We also created a mechanism (refined later in proposal 297) for telling Tor clients and relays that they cannot participate effectively in the Tor network, and they need to shut down. In this document, we describe a policy according to which these decisions should be made in practice. 2. Recommending features (for clients and relays) A subprotocol version SHOULD become recommended soon after all release series that did not provide it become unsupported (within a month or so). For example, the current oldest LTS release series is 0.2.9; when it becomes unsupported in 2020, the oldest supported release series will be 0.3.5. Suppose that 0.2.9 supports a subprotocol Cupcake=1, and that all stable 0.3.5.x versions support Cupcake=1-3. Around one month after the end of 0.2.9 support, Cupcake=3 should become a _recommended_ protocol for clients and relays. Additionally, a feature can become _recommended_ because of security reasons. If we believe that it is a terrible idea to run an old protocol, we can make it _recommended_ for relays or clients or both. We should not do this lightly, since it will be annoying. 3. Requiring features (for relays) We regularly update the directory authorities to require relays to run certain versions of Tor or later. We generally do this after a short outreach campaign to get as many relays as possible to upgrade. We MAY make a feature required for relays one month after every version without it is obsolete and unsupported, though it is better to wait three months if possible. We SHOULD make a feature required for relays within 12 months after every version without it is obsolete and unsupported. 4. Requiring features (for clients) Clients take the longest time to update, and are often the least able to fetch upgrades. Because of this, we should be very careful about making subprotocol versions required on clients, and should only do so for fairly compelling reasons. We SHOULD NOT make a feature required for clients until it has been _recommended_ for clients for at first 9 months. We SHOULD make a feature required for clients if it has been _recommended_ for clients for at least 18 months.

4 3

Per-peer stream isolation for Bitcoin clients
by Jeremy Rand 02 Jul '19

02 Jul '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Tor-Dev, I'm trying to gauge the consensus (or lack thereof) in the Tor development community on whether it's desirable for Bitcoin clients (e.g. Bitcoin Core) to use stream isolation such that each peer is accessed over a different circuit. Some random thoughts on the matter: 1. Bitcoin Core accesses 8 peers by default, so per-peer stream isolation would use 8 circuits instead of 1. 2. Per-peer stream isolation prevents a single exit relay from feeding the user a chain that's not the longest chain, so it's desirable from a Bitcoin security point of view. 3. Per-peer stream isolation would mean more potential for one of the circuits being deanonymizable, via traffic analysis etc. It's not clear to me whether this amount of increased circuits is harmful, or how it compares to other common usage of Tor such as Tor Browser (which uses first-party stream isolation, so a user with a lot of tabs open may very well have 8 or more circuits in use at once). 4. Per-peer stream isolation puts more load on the Tor network. It's not clear to me whether this increased load (8 circuits instead of 1) is so much that it's harmful. 5. Bitcoin Core does do per-peer stream isolation by default. The relevant PR is https://github.com/bitcoin/bitcoin/pull/5911 6. Whonix's tor-service-defaults-torrc chooses to disable automatic per-peer stream isolation for Bitcoin's SOCKS port, and states "Makes too many connections to different servers. Should not hurt if they get through the same circuit." No citation was given for either claim. 7. The behavior in Bitcoin Core's PR was ACKed by Isis Lovecruft, and an unspecified Tor developer whom Greg Maxwell talked to. So, it sounds like there is apparently some disagreement between the two Tor devs who ACKed this behavior, and the Whonix devs who decided not to enable it. Curious what the general feeling in the community is. (I understand that Isis no longer is active in Tor, so I'm not CC'ing them. I am CC'ing Patrick from Whonix in case he wants to weigh in.) Cheers, - -- - -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmobile(a)airmail.cc Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with OpenPGP. Please don't send me unencrypted messages. My business email jeremy(a)veclabs.net is having technical issues at the moment. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEVB3fdzAraEcoBtkSs/LRZXhtZXAFAl0VKAIACgkQs/LRZXht ZXD3rRAAydyiDv2NVU8rPopr+FkTVclNAA3gM3BKjhZH1EGqya54Xr0OdsTR3VUQ gBMz5HiexbFnE7VTysnB6ePP/PpLRlAlTj1zLXFCT90H+s1kj84WpjxNZJaguLIJ zGOQKhqgId9f1pjv7or8DYDrdzT0bfOzKREFM+Yx5TTgPfvxXC9Ug6U1sx5sp7AA jCAZnrjqWSK+IrNnwrayL2vSPByt+djsK2YPLnq13frKMdonMw+IITVOvT9w5LZt I/MQa2UujG5DU0owI0t5XmJ7ZQxehcHdAuqU/BfZ5OQVjCH3QgVNwRjlGPaaag+f y9wMVG0X4cbuvg5x8sar/n8UCR1sDJmlSuN7C6AwE2/e0RU0g67wfTgNcqFlIHta 9t8ORsFUxN6rDtRkbq0FE7xgSYbT9cDtjDFJMhG8oOc0Ibc9EhIJkGETz1amHNUo GFEBAEircjPJ+KZBsHsQGrLUwpiM6zPbPfkVWwA7dTn4peESSed0Yjwawcn2wpiE X2TMzhhXpzTjtqpBcroSDKRMum5z/VksEZ3d2MyfIj/caYVXXxPZYS1DqOGtKxYc uiDCRpL4b/ouJ1FbT1sxHpwTp5e+62XFnfXsoz3Wa9jkrA75kgnnb2kfcjNW/Fq/ 6HgLhasriz4jg2iya9rScuUnmU1Ewa8st0bNDGK83qYHofCdvCg= =1u2L -----END PGP SIGNATURE-----

4 4

Changed Network Team Meeting Times
by teor 01 Jul '19

01 Jul '19

Hi all, We've moved the first network team meeting of each month to Wednesday 2300 UTC. (It used to be Tuesday.) We have also moved the weekly "patch party" to Wednesday 2300 UTC in the other weeks of the month. The regular team meeting time is still the same, Monday 1700 UTC. Here is our meeting schedule for July: * Wednesday 3 July 2300 UTC - Changed Day! * Monday 8 July at 1700 UTC * (In-person meeting 12-14 July) * Monday 22 July 1700 UTC * Monday 29 July 1700 UTC T -- teor ----------------------------------------------------------------------

1 0

tor writen in golang
by liuyihen 30 Jun '19

30 Jun '19

Hi tor-dev@mailing list, I want to know is there somebody has been re-writing tor in golang? or is there a repo have been opened?

2 1

Release: obfs4proxy-0.0.11
by Yawning Angel 21 Jun '19

21 Jun '19

Hello, I just tagged obfs4proxy-0.0.11. The primary changes are an alteration to how the obfs4 transport handles connections after the handshake failed, based on a report and assistance from Sergey Frolov. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.1… https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.1… Changes in version 0.0.11 - 2019-06-21: - Update my e-mail address. - Change the obfs4 behavior for handling handshake failure to be more uniform. Thanks to Sergey Frolov for assistance. - Bump the version of the utls fork. Regards, -- Yawning Angel

1 0

Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension
by David Goulet 20 Jun '19

20 Jun '19

9 19

Shortcomings of the pluggable transports specification?
by Philipp Winter 20 Jun '19

20 Jun '19

We are working on improving Tor's pluggable transports specification: <https://spec.torproject.org/pt-spec> The goal is to make the spec useful to more people and fix issues that have accumulated over the years. For more context, have a look at the following ticket, which we use to coordinate this effort: <https://bugs.torproject.org/29285> Before changing the spec, we need to understand its shortcomings and what issues implementers have run into. For those of you who have experience with the spec -- either Tor's version 1.0 or version 2.1 maintained by pluggabletransports.info -- please let us know: * What version of the PT specification and what library implementation (if any) are you using? * What has your experience been with the PT specification? * How would you improve the specification? Thanks, Philipp

3 2

User Data Exchange with Network Automata (re: Prop 305, ex energy)
by grarpamp 17 Jun '19

17 Jun '19

> And this is really off topic for this list. General Tor energy bits moved here... https://lists.torproject.org/pipermail/tor-talk/2019-June/045256.html re 305 etc It wouldn't be unusual for an app to pop up some form of captcha, challenge, or data exchange where needed. Some of that model exists in form of onion service authentication config... some helper data that grants access, makes things happen, whether passive or active interrupt. The controller would be the interface. Yet tor currently has no mechanism on platforms to handle such protocols and popups... thus like onion auth, the user has know they need it for something and configure it in advance. Try investigating an ssh-agent like tor tool... preloaded with users Proof-of-*, 2FA, consumables, etc to dole out, even automatically, where needed and permitted.

1 0

Cryptocurrency: Total Energy Analysis - Crypto Uses Less Than Fiat
by grarpamp 17 Jun '19

17 Jun '19

(from tor-dev: PoW DoS defenses Prop 305: INTRO Cell) On 6/16/19, Chelsea Holland Komlo <me(a)chelseakomlo.com> wrote: > Given the significant environmental impact of POW in other distributed > systems (blockchain), we should not implement schemes that solve a > problem for Tor but create problems for people elsewhere (potentially > irreversible environmental damage). > > https://www.theguardian.com/technology/2018/nov/05/energy-cost-of-mining-bi… One must first understand and enumerate the *entirety of all global energy inputs* going into and making up the legacy fiat currency banking systems, from both Government and Corporate sectors, and its results, before attempting to make any claims that cryptocurrency is "worse" [1]. Such cataloging and analysis requires more work, more data, more actual redpill thought, than just simple hashrate/J/$... so of course people take shortcuts in such articles, as do other people in their pronouncements stemming from them. > Other less-destructive schemes exist to prevent DoS attacks. POW is a > method, not a goal in itself. Taking a step back and examining the full > spectrum of available tools would be better. The needs and model for overlay nets, ie tor, will of course be different than those above. And always interesting where tech various ends up being applied. [1] Hint: Cryptocurrency actually consumes less, and further finally forces inefficiency and other undesired things out of Fiat by displacing it... hopefully faster than it can adapt. Some say that has a value, one that many will be quite happy to sink a bit of premium into if need be.

2 1

OTRv4 summit at PETS2019
by Sofia Celi 17 Jun '19

17 Jun '19

Hi, Tor people! My name is Sofía and I'm the person leading the OTRv4 initiative. I don't know if this is the best place to send this, so if it is not, let me know ;) As part of the work on creating the version 4 of the OTR (Off-the-Record) messaging protocol, we are running a summit in Stockholm, Sweden, the 15 of July, in the morning. This summit runs in parallel with the Privacy Enhancing Technology Symposium 2019 (PETS2019, https://petsymposium.org/2019/index.php) It will be a summit around the work done in the field of secure messaging, deniability and privacy on July 15 on the morning (that is, the day before the start of PETS 2019). It will be held at the Royal Institute of Technology (KTH). You can find it on the official PETS2019 programm: https://petsymposium.org/2019/program.php and on the official otr website: http://otr.im/ The OTRv4 summit will feature a mix of a discussions, short talks and presentations which aim to highlight the importance of privacy, security and deniability in a secure messaging setting to researchers, students, activists and developers. The final schedule for the event will be announced closer to the event. The workshop will start at 9 am and end at 12.30 pm. As one of our developers and my current partner, Ola Bini, has been detained in Ecuador with no actual evidence, we will also talk about this. You can read about this in the latest EFF statement: https://www.eff.org/deeplinks/2019/06/eff-ohchr-iachr-cybercrime-law-interc… We will like that you join us there... so let us know if you can! Thank you! The OTRv4 team -- Sofía Celi @claucece Cryptographic research and implementation at CAD: https://autonomia.digital/ EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F

2 2

Proposal 304: Extending SOCKS5 Onion Service Error Codes
by David Goulet 06 Jun '19

06 Jun '19

3 2

Dealing with critical sbws tickets
by teor 05 Jun '19

05 Jun '19

Hi juga, I read your meeting notes from this week's network team meeting: juga(offline): Week of 05/20 (planned) - Add Tor version to the bandwidth file (#30196) Week of 05/20 (actual) Week of 06/03 (plan) - Continue with #30406: Refactor header constants in sbws to use Stem's one For the next few weeks, can you focus on fixing critical sbws bugs, and helping with authority deployments? Here's what I think we could do: I would like us to deploy sbws to 3/6 bandwidth authorities some time in June. We can do this deployment as soon as another directory authority operator is ready. To deploy more than 3 sbws instances, we need to fix these critical sbws bugs: We need sbws to generate bandwidth lines for all relays with results, even if they are not Running in the sbws tor client's current consensus. https://trac.torproject.org/projects/tor/ticket/29710#comment:13 We need sbws to use MaxAdvertisedBandwidth from the latest descriptors: https://trac.torproject.org/projects/tor/ticket/30733 We also need to look for any more critical bugs in sbws. Here are some ways we can check for bugs: We need to check if all sbws instances exclude some relays, to help us find any more bugs in sbws: https://trac.torproject.org/projects/tor/ticket/30735 90% of sbws measurement attempts fail. But these are internal errors, not network errors. So it looks like sbws has a relay selection bug: https://trac.torproject.org/projects/tor/ticket/30719#comment:2 After we do these tasks, we can deploy sbws to 4 bandwidth authorities. What do you think? T

2 2