July 2019 - tor-dev - lists.torproject.org

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