- tor-dev - lists.torproject.org

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 26 Jul '19

26 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 25 Jul '19

25 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