tor-dev September 2019

tor-dev@lists.torproject.org

23 participants
20 discussions

the consequences of deprecating debian alpha repos with every new major branch
by nusenu 21 Dec '21

21 Dec '21

Hi, tldr: - more outdated relays (that is a claim I'm making and you could easily proof me wrong by recreating the 0.3.3.x alpha repos and ship 0.3.3.7 in them and see how things evolve after a week or so) - more work for the tpo website maintainer - less happy relay operators [3][4] - more work for repo maintainers? (since a new repo needs to be created) When the tor 0.3.4 alpha repos (deb.torproject.org) first appeared on 2018-05-23 I was about to submit a PR for the website to include it in the sources.list generator [1] on tpo but didn't do it because I wanted to wait for a previous PR to be merged first. The outstanding PR got merged eventually (2018-06-28) but I still did not submit a PR to update the repo generator for 0.3.4.x nonetheless and here is why. Recently I was wondering why are there so many relays running tor version 0.3.3.5-rc? (see OrNetStats or Relay Search) (> 3.2% CW fraction) Then I realized that this was the last version the tor-experimental-0.3.3.x-* repos were shipping before they got abandoned due to the new 0.3.4.x-* repos (I can no longer verify it since they got removed by now). Peter made it clear in the past that the current way to have per-major-version debian alpha repos (i.e. tor-experimental-0.3.4.x-jessie) will not change [2]: > If you can't be bothered to change your sources.list once or twice a > year, then you probably should be running stable. but maybe someone else would be willing to invoke a "ln" commands everytime a new new alpha repo is born. tor-alpha-jessie -> tor-experimental-0.3.4.x-jessie once 0.3.5.x repos are created the link would point to tor-alpha-jessie -> tor-experimental-0.3.5.x-jessie It is my opinion that this will help reduce the amount of relays running outdated versions of tor. It will certainly avoid having to update the tpo website, which isn't a big task and could probably be automated but it isn't done currently. "..but that would cause relay operators to jump from i.e. 0.3.3.x to 0.3.4.x alphas (and break setups)!" Yes, and I think that is better than relays stuck on an older version because the former repo no longer exists and operators still can choose the old repos which will not jump to newer major versions. [1] https://www.torproject.org/docs/debian.html.en#ubuntu [2] https://trac.torproject.org/projects/tor/ticket/14997#comment:3 [3] https://lists.torproject.org/pipermail/tor-relays/2018-June/015549.html [4] https://trac.torproject.org/projects/tor/ticket/26474 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

4 7

tor relay process health data for operators (controlport)
by nusenu 16 Nov '20

16 Nov '20

Hi, every now and then I'm in contact with relay operators about the "health" of their relays. Following these 1:1 discussions and the discussion on tor-relays@ I'd like to rise two issues with you (the developers) with the goal to help improve relay operations and end user experience in the long term: 1) DNS (exits only) 2) tor relay health data 1) DNS ------ Current situation: Arthur Edelstein provides public measurements to tor exit relay operators via his page at: https://arthuredelstein.net/exits/ This page is updated once daily. the process to use that data looks like this: - first they watch Arthur's measurement results - if their failure rate is non-zero they try to tweak/improve/change their setup - wait for another 24 hours (next measurement) This is a somewhat suboptimal and slow feedback loop and is probably also less accurate and less valuable data when compared to the data the tor process can provide. Suggestion for improvement: Exposes the following DNS status information via tor's controlport to help debug and detect DNS issues on exit relays: (total numbers since startup) - amount of DNS queries send to the resolver - amount of DNS queries send to the resolver due to a RESOLVE request - DNS queries send to resolver due to a reverse RESOLVE request - amount of queries that did not result in any answer from the resolver - breakdown of number of responses by response code (RCODE) https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-pa… - max amount of DNS queries send per curcuit If this causes a significant performance impact this feature should be disabled by default. 2) general relay health metrics -------------------------------- Compared to other server daemons (webserver, DNS server, ..) tor provides little data for operators to detect operational issues and anomalies. I'd suggest to provide the following stats via the control port: (most of them are already written to logfiles by default but not accessible via the controlport as far as I've seen) - total amount of memory used by the tor process - amount of currently open circuits - circuit handshake stats (TAP / NTor) DoS mitigation stats - amount of circuits killed with too many cells - amount of circuits rejected - marked addresses - amount of connections closed - amount of single hop clients refused - amount of closed/failed circuits broken down by their reason value https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1402 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n1994 - amount of closed/failed OR connections broken down by their reason value https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n2205 If this causes a significant performance impact this feature should be disabled by default. cell stats - extra info cell stats as defined in: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1072 This data should be useful to answer the following questions: - High level questions: Is the tor relay healthy? - is it hitting any resource limits? - is the tor process under unusual load? - why is tor using more memory? - is it slower than usual at handling circuits? - can the DNS resolver handle the amount of DNS queries tor is sending it? This data could help prevent errors from occurring or provide additional data when trying to narrow down issues. When it comes to the question: **Is it "safe" to make this data accessible via the controlport?** I assume it is safe for all information that current versions of tor writes to logfiles or even publishes as part of its extra info descriptor. Should tor provide this or similar data I'm planing to write scripts for operators to make use of that data (for example a munin plugin that connects to tor's controlport). I'm happy to help write updates for control-spec should these features seem reasonable to you. Looking forward to hearing your feedback. nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

5 7

DNS-over-HTTPS (DOH) in Firefox/Torbrowser
by nusenu 01 Jul '20

01 Jul '20

Hi, since Mozilla did tests [0] on DOH [1] in Firefox I was wondering if Torbrowser developers have put any thought into that as well? Note: I'm _not_ suggesting to use DOH in torbrowser I'm just asking because the answer probably matters for exit documentation in the relay guide if clients do DNS themselves over TCP connections instead of relying on the exit (even if torbrowser is not the only tor client). thanks, nusenu [0] https://www.ghacks.net/2018/03/20/firefox-dns-over-https-and-a-worrying-shi… [1] https://datatracker.ietf.org/doc/draft-hoffman-dns-over-https/ -- https://mastodon.social/@nusenu twitter: @nusenu_

4 4

Lets give every circuit its own exit IP?
by nusenu 18 Mar '20

18 Mar '20

The unbearable situation with Google's reCAPTCHA motivated this email (but it is not limited to this specific case). This idea came up when seeing a similar functionality in unbound (which has it for a different reason). Assumption: There are systems that block some tor exit IP addresses (most likely the bigger once), but they are not blocked due to the fact that they are tor exits. It just occurred that the IP got flagged because of "automated / malicious" requests and IP reputation systems. What if every circuit had its "own" IP address at the exit relay to avoid causing collateral damage to all users of the exit if one was bad? (until the exit runs out of IPs and starts to recycle previously used IPs again) The goal is to avoid accumulating a bad "reputation" for the single used exit IP address that affects all tor users of that exit. Instead of doing it on the circuit level you could do it based on time. Change the exit IP every 5 minutes (but do _not_ change the exit IPs for _existing_ circuits even if they live longer than 5 minutes). Yes, no one has that many IPv4 addresses but with the increasing availability of IPv6 at exits and destinations, this could be feasible to a certain extend, depending on how many IPv6 addresses the exit operator has. There are exit operators that have entire /48 IPv6 blocks. problems: - will not solve anything since reputation will shift to netblocks as well (How big of a netblock are you willing to block?) - you can tell two tor users easily apart from each other even if they use the same exit (or more generally: you can tell circuits apart). There might be all kinds of bad implications that I'm not thinking off right now. - check.tpo would no longer be feasible - how can do we still provide the list of exit IPs for easy blocking? Exits could signal their used netblock via their descriptor. What if they don't? (that in turn opens new kinds of attacks where an exit claims to be /0 and the target effectively blocks everything) - more state to track and store at the exit -... some random thoughts, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

4 6

Optimistic SOCKS Data
by Tom Ritter 15 Oct '19

15 Oct '19

The attached is a draft proposal for allowing tor to lie to an application about the SOCKS connection enabling it to send data optimistically. It's going to need some fleshing out in ways I am not familiar with, but I wanted to get something out to start as we think that this is probably the best path forward for bringing back Tor Browser's optimistic SOCKS behavior. -tom

6 11

Exposing onion service errors to Tor Browser
by George Kadianakis 02 Oct '19

02 Oct '19

Hello list, we've recently been thinking about how to expose onion-service-related errors to Tor Browser so that we can give more useful error pages to users. We currently return "Unable to connect" error pages for any kind of onion service error, and I think we can do better. This is a thread to think about the errors we want to expose, how that should look like, and what options we should give to the users when it happens. Relevant master tickets are #30022, #30025 and #30000. We decided (in #14389) that Tor will export these errors through the SOCKS port, and the relevant spec is proposal 304 [0]. As part of #30090 antonela started making a table of potential errors. I'm gonna use that in this thread and also add a few more. Let's go: = Client-level errors = These are errors on the user side of things: === 1) Typo error on address === This can be detected by Tor using the checksum or if the address is too big or too small. TODO: We will need to add a new error code to prop304. Not sure if the error code should distinguish between checksum fail or length fail. There is no recovery here since the address is busted. The user needs to find the right one. === 2) Missing Client Authorization === This is prop304's 'F4' error (see #30382), and it means that we can't decrypt the descriptor because it requires client auth, but we don't have it configured. The recovery here is the whole point of #30237 where we make a dialog for the user to insert their client auth credentials. === 3) Wrong Client Authorization === This is prop304's 'F5' error, and it means that there client auth credentials configured for this onion are wrong. The user recovery here is unclear but it might be that they need to change their client auth credentials. IMO, we should not try to make the perfect UX here, and we should just go with something super simple. = Service-level errors = These are errors on the onion service side: === 4) Service Descriptor Can Not be Found === This is prop304's 'F0' error, and it means that we could not find the descriptor of the service on the directory servers. This means that the service is not up right now (or, more unlikely, that some bug has happened somewhere). The user recovery here is unclear. The user can try to reconnect in case the service got up in the meanwhile, but this is not so likely in a small period of time. Perhaps we can give the user the option to reconnect every 10 seconds or so? Does this make sense from a UX PoV? Again this equivalent to a "Remote host is down" error and we should use it as such. = Network-level errors = These are errors caused by the network (directory servers, intro points, rendezvous points) or even the service itself. It's kinda unclear given all the hops involved. === 5) Onion Service Descriptor Is Invalid === This is prop304's 'F1' error and it means that we got a descriptor back from the directory but it's corrupted. This is very unlikely to happen since directory servers do not keep corrupted descriptors, so it usually means that some bug happened somewhere (or that the directory is bad or confused). In terms of recovery and error page, this is kinda an "Oops. Internal error." situation where this is rare and weird and hence we don't know what's the best recovery option. We can give the option to reconnect but it's likely not gonna help much. Again this should never really appear, so let's not stress too much over it. === 6) Onion Service Introduction Failed === This is prop304's 'F2' error and it means that for some reason the introduction did not complete. This could be because the onion service is not up anymore, or it could be because the network is screwed in some way (e.g. the service is DoSed). The recovery here might be some 'reconnect' button which could be helpful in case of a DoS situation, but it would not help much if the service is not up anymore. === 7) Onion Service Rendezvous Failed === This is prop304's 'F3' error and it means that the rendezvous did not complete. This usually means that the service is having a bad time, and is either DoSed or it generally cannot cope. The recovery again here is some 'reconnect' button, since if we did the introduction successfuly, the service is up, and reconnecting might work at some point. This one and (6) are very related and perhaps they can be handlded identically, since exposing terms like "intro" and "rend" to users will not be nice. Still we might want to expose a technical error value somewhere for debugging purposes when users come to us. ======================================================================= I think the above set of errors will satisfy all our needs. In particular: - #30022 (typos ticket) needs error (1) from above. - #30025 (client errors ticket) needs errors (4), (5), (6), (7) from above. - #30000 (client auth) needs errors (2) and (3) from above. In terms of error page, I'm not sure how it should look like. Perhaps along with the error description and the recovery path, we should provide some education about onion services to the users? In terms of unsafe paths, I don't see any of these errors being dangerous in terms of causing security issues if you attempt to reconnect or anything. The Tor protocol takes care of this in the layer below. The worst thing you can do is slightly damage the network from too many reconnects, but I think that's OK since people who use the TB are legitimate users and not DoS attackers. === Hope this was useful! [0]: https://github.com/torproject/torspec/blob/master/proposals/304-socks5-exte…

3 3

(no subject)
by vignesh kannan 26 Sep '19

26 Sep '19

Please sent me a video that how to get dark web please

3 3

(no subject)
by vignesh kannan 26 Sep '19

26 Sep '19

What should I do

1 0

(no subject)
by vignesh kannan 26 Sep '19

26 Sep '19

Okay

1 0

Counter Galois Onion: A New Proposal for Forward-Secure Relay Cryptography
by Jean Paul Degabriele 23 Sep '19

23 Sep '19

Hello tor-devs, Martijn Stam and myself have previously worked on analysing the security of proposal 261. Together with Martijn's PhD student, Alessandro Melloni, we have now written a proposal for an onion encryption scheme as an alternative to Proposals 261 and 295. It builds on the GCM-RUP construction from [ADL17] but it offers a number of improvements over proposal 295. In addition to addressing the issues described below we expect it to offer better performance. We are currently working on a security proof and potential efficiency optimisations for this scheme. In the meantime, we would be very happy to hear what you think and any feedback you may have. If something is unclear, please let us know. Best, Martijn, Alessandro, and Jean Paul --------------------- In our assessment of proposal 295 we identified the following issues: a) Improper use of the universal hash function. The proposal suggested using GHASH, a universal hash function, to compute the digest. Universal hash functions require their input to be independent of the hash key for security to hold. This is also a basic requirement in the tweakable block cipher construction, underlying the PIV and RUP constructions. However, the construction requires feeding back the digest (which is key-dependent) back into the input of the hash. Note that such feedback was not present in [ADL17] and the security proof breaks down with this modification. b) Lack of Forward Security for any type of hash function that is used. If instantiated with GHASH, proposal 295 does not provide forward security (as it is easy to invert given the hash key). The designers suggested (on the Tor dev mailing list) that forward security could be achieved by instantiating the hash function with SHA2 or SHAKE instead. Clearly this degrades the efficiency of the scheme but, as we argue below, it still does not suffice to achieve forward security Specifically, even if the hash function is instantiated with an ideal hash function (a random oracle), the construction succumbs to the following attack. Assume that the last OR in a circuit of length n has already processed some cells and that its current state is (Kf_n, Kb_n, Ktf_n, Ktb_n, Khf_n, Khb_n, Tf'_n, Tf'_{n+1}, Tb'_n, Tb'_{n+1}). An adversary, who has collected previous ciphertexts and nonces (C, N), then corrupts it. The adversary has enough information to recover the last message received by OR_n, which it computes as follows: N_{n+1} = Tf'_n ^ D(Ktf_n, Tf'_n ^ N_n) M = Decrypt(Kf_n, N_{n+1}, C_n). Clearly this breaks forward security, and it is enabled by the fact that the current digest needs to be saved for computing the next digest for when another ciphertext is received. [ADL17] Tomer Ashur, Orr Dunkelman, Atul Luykx, "Boosting Authenticated Encryption Robustness with Minimal Modifications", CRYPTO 2017.

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev September 2019