June 2020 - tor-dev - lists.torproject.org

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

Re: [tor-dev] [RFC] Proposal: A First Take at PoW Over Introduction Circuits
by tevador 25 Sep '20

25 Sep '20

Hi all, I was asked by George to submit my comments about the proposal and to suggest suitable RandomX parameters for this PoW scheme. > For our dynamic PoW system to work, we will need to be able to compare PoW > tokens with each other. To do so we define a function: > unsigned effort(uint8_t *token) > which takes as its argument a hash output token, and returns the number of > leading zero bits on it. This definition makes the effort exponential, i.e. the computational resources required to reach one notch higher effort increase by a factor of 2 each time. I suggest to use linear effort defined as the quotient of dividing a bitstring of 1s by the hash value: == Example A: effort(00000001100010101101) = 11111111111111111111 / 00000001100010101101 or in decimal: effort(6317) = 1048575 / 6317 = 165. This definition of effort has the advantage of directly expressing the expected number of hashes that the client had to calculate to reach the effort. With the exponential definition, we could have an equivalent linear effort of either 128 (7 leading zeroes) or 256 (8 leading zeroes), while the linear definition provides smoother classification of PoW results. > The EXT_FIELD content format is: > > POW_VERSION [1 byte] > POW_NONCE [32 bytes] > I suggest to use a 16-byte nonce value, which is more than sufficient given the target security level and has the benefit of reducing the replay cache size to half. Since we expect the seed to be valid for around 3 hours (as proposed), then even if the service receives 1 million proofs per second and each proof has an effort of 1 million, then the number of submitted nonces from clients will only reach about 10^10. With a 108-bit solution space (subtracting 20 bits as the search space per client), the probability that two clients accidentally submit the same nonce is roughly 10^-13 (see [REF_BIRTHDAY]). Additionally, I suggest to add the client's effort for convenience: The updated EXT_FIELD content format would be: POW_VERSION [1 byte] POW_EFFORT [4 bytes] POW_NONCE [16 bytes] Including the effort has 2 benefits: 1. In case the Intro Priority Queue is full, the service doesn't need to waste time verifying PoW solutions that have effort lower than the last element in the queue. While an attacker can always lie about the actual effort of their nonce value, I think this field can still save some CPU cycles when the service is under heavy load. 2. The service can conveniently verify the reported effort with the following inequality: POW_EFFORT * pow_function(POW_NONCE, SEED) <= MAX_RESULT where MAX_RESULT is the highest possible output from the pow_function. In the case of Example A, that would be: 165 * 6317 = 1042305 <= 1048576 > Similar to how our cell scheduler works, the onion service subsystem will > poll the priority queue every 100ms tick and process the first 20 cells from > the priority queue (if they exist). The service will perform the rendezvous > and the rest of the onion service protocol as normal. I suggest to use a different selection method rather than always taking the first 20 requests. Selecting cells from the front of the queue actually minimizes the effort that an attacker needs to expend to completely block access to the service. The attacker can always submit the minimum effort required to occupy the first 20 slots in each 100 ms window. This can be done by submitting just 200 requests per second and observing how many circuits are successfully open and adjusting the effort until no other request can go through. This is the "Total overwhelm strategy" described in § 5.1.1. See the following examples to show how selecting the first N cells from the queue is unfair. I will use N = 4 for clarity. E denotes some value of effort. == Example B: ATTACKER LEGITIMATE CLIENTS ___________ _________ ____________ ______________ / \ / \ +--------+--------+--------+--------+----+----+----+----+----+----+----+----+ | 2E | 2E | 2E | 2E | E | E | E | E | E | E | E | E | +--------+--------+--------+--------+----+----+----+----+----+----+----+----+ ^ ^ ^ ^ selected selected selected selected Here both the attacker and the legitimate clients have expended a combined effort of 8E. All of the attacker's cells get selected, while none of the other clients get through. Instead, I suggest to use Stochastic universal sampling [REF_SUS], where the probability that a cell gets selected is proportional to its effort. == Example C: Here the total effort in the queue is 16E, so we first select a random value in the interval [0, 4E) and then select 4 evenly spaced cells: ATTACKER LEGITIMATE CLIENTS ___________ _________ ____________ ______________ / \ / \ +--------+--------+--------+--------+----+----+----+----+----+----+----+----+ | 2E | 2E | 2E | 2E | E | E | E | E | E | E | E | E | +--------+--------+--------+--------+----+----+----+----+----+----+----+----+ ^ ^ ^ ^ selected selected selected selected In this case, 2 cells are selected from each group, which is fairer considering that each group expended the same effort. == Example D: Now if the attacker wanted to block access to all legitimate clients, they would need to at least quadruple their total PoW effort (and there would still be a chance that a legitimate client gets selected from the end of the queue): ATTACKER LEGITIMATE CLIENTS __________________________ ______________________ ______________ / \ / \ +--------------+--------------+---------------+--------------+-+-+-+-+-+-+-+-+ | 8E | 8E | 8E | 8E |E|E|E|E|E|E|E|E| +--------------+--------------+--------------+---------------+-+-+-+-+-+-+-+-+ ^ ^ ^ ^ selected selected selected selected Note: With linear effort, the original selection method becomes even worse because the attacker can occupy the front of the queue with an effort of just E+1 per cell rather than 2E. In some cases, Stochastic universal sampling can select a single element multiple times, which is not a problem for genetic algorithms, but we want to avoid it. I suggest to restart the selection algorithm from the beginning of the next cell in those cases and shorten the sampling interval according to the remaining portion of the queue. See the following example. == Example E: +---------------+-------------+--------------+------------+-+-+-+-+-+-+-+-+-+-+ | 16E | 8E | 6E |E|E|E|E|E|E|E|E|E|E| +---------------+-------------+--------------+------------+-+-+-+-+-+-+-+-+-+-+ ^ ^ ^ ^ selected selected selected selected > In particular, the service starts with a default suggested-effort value of 15. > > Everytime the service handles an introduction request from the priority queue > in [HANDLE_QUEUE], the service compares the request's effort to the current > suggested-effort value. If the new request's effort is lower than the > suggested-effort, set the suggested-effort equal to the effort of the new > request. > > Everytime the service trims the priority queue in [HANDLE_QUEUE], the service > compares the request at the trim point against the current suggested-effort > value. If the trimmed request's effort is higher than the suggested-effort, > set the suggested-effort equal to the effort of the new request. I think the default suggested-effort is a bit too high. Assuming each attempt takes around 1 ms to calculate, the client would need, on average, 2^15 ms = 33 seconds to find a solution using 1 CPU core. I suggest to specify a minimum effort instead. Requests with effort < MIN_EFFORT and requests without the PROOF_OF_WORK extension would be treated as having effort = 1 for the purposes of the sampling algorithm. Secondly, the proposed method of calculating the suggested-effort is susceptible to gaming by attackers. Since the service can only update the value in the directory once every 'hs-pow-desc-upload-rate-limit' seconds, they could stop the attack for a little while just before the directory gets updated, which would cause the suggested-effort value to be too low despite an ongoing attack. I suggest to take the median effort of the selected cells during each 100 ms window. For the examples above that would be: Example C: 1.5E Example D: 8E Example E: 7E Then I would take the median of these values over the directory update period. > > 5. Attacker strategies > Additional attacks: 5.1.2 PoW Spam Attack The attacker may try to spam many requests with random values of POW_NONCE, requiring the service to waste cycles verifying the invalid proofs. No such request would make it into the Intro Queue, but it may still be a viable DoS strategy depending on proof verification time and the number of intro requests that can be practically delivered through the network. 5.1.3 Precomputed PoW attack The attacker may precompute many valid PoW nonces and submit them all at once before the current seed expires, overwhelming the service temporarily even using a single computer. > 4.2. Seed expiration issues > > As mentioned in [DESC_POW], the expiration timestamp on the PoW seed can > cause issues with clock skewed clients. Furthermore, even not clock skewed > clients can encounter TOCTOU-style race conditions here. > > The client descriptor refetch logic of [CLIENT_TIMEOUT] should take care of > such seed-expiration issues, since the client will refetch the descriptor. > I suggest to use 2 concurrent seeds, i.e. to accept PoW both from the current and the last seed epoch. We use this approach in Monero. It would however require adding the seed value into the proof of work extension field and also double the memory requirements for verification with RandomX. > The proposal suggests argon2, and Mike has been looking at Randomx. However, > after further consideration and speaking with some people (props to Alex > Biryukov), it seems like those two functions are not well fitted for this > purpose, since they are memory-hard both for the client and the service. And > since we are trying to minimize the verification overhead, so that the > service can do hundreds of verifications per second, they don't seem like > good fits. Asymmetric function like Equihash, Cuckoo cycle [REF_CUCKOO] and MTP have the advantage of being very fast to verify, but they run much faster on GPUs and specialized hardware, so I don't think they are particularly suitable for this purpose. When we designed RandomX to be used as the PoW algorithm by Monero, we selected the parameters very conservatively to maximize the ASIC resistance of the algorithm. That's because it is very difficult to change the PoW algorithm once it's deployed. TOR is not limited by this, so we can be much more aggressive when configuring RandomX. I suggest to use a configuration that gives the fastest possible verification time without completely breaking the algorithm. In particular, the following parameters should be set differently from Monero: RANDOMX_ARGON_SALT = "RandomX-TOR-v1" The unique RandomX salt means we do not need to use a separate salt as PoW input as specified in § 3.2. RANDOMX_ARGON_ITERATIONS = 1 RANDOMX_CACHE_ACCESSES = 4 RANDOMX_DATASET_BASE_SIZE = 1073741824 RANDOMX_DATASET_EXTRA_SIZE = 16777216 These 4 changes reduce the RandomX Dataset size to ~1 GiB, which allows the number of iteration to be reduced from 8 to 4. The combined effect of this is that Dataset initialization becomes 4 times faster, which is needed due to more frequent updates of the seed (Monero updates once per ~3 days). RANDOMX_PROGRAM_COUNT = 2 RANDOMX_SCRATCHPAD_L3 = 1048576 Additionally, reducing the number of programs from 8 to 2 makes the hash calculation about 4 times faster, while still providing resistance against program filtering strategies (see [REF_RANDOMX_PROGRAMS]). Since there are 4 times fewer writes, we also have to reduce the scratchpad size. I suggest to use a 1 MiB scratchpad size as a compromise between scratchpad write density and memory hardness. Most x86 CPUs will perform roughly the same with a 512 KiB and 1024 KiB scratchpad, while the larger size provides higher resistance against specialized hardware, at the cost of possible time-memory tradeoffs (see [REF_RANDOMX_TMTO] for details). Lastly, we reduce the output of RandomX to just 8 bytes: RANDOMX_HASH_SIZE = 8 64-bit preimage security is more than sufficient for proof-of-work and it allows the result to be treated as a little-endian encoded unsigned integer for easy effort calculation. RandomX would be used as follows: The service will select a 32-byte POW_SEED and initialize the cache and the dataset: randomx_init_cache(myCache, POW_SEED, 32); randomx_init_dataset(myDataset, myCache, 0, randomx_dataset_item_count()); randomx_vm *myMachine = randomx_create_vm(flags, NULL, myDataset); Then in order to validate a PoW token, we could use something like this: int validateProof(uint32_t pow_effort, void* pow_nonce) { uint64_t result; randomx_calculate_hash(myMachine, pow_nonce, 16, &result); if (mulh(pow_effort, result) == 0) { return 1; } return 0; } I suggest to set MIN_EFFORT = 10000, which takes about 1 second on my laptop. Requests with pow_effort < MIN_EFFORT would not be validated. I have collected some performance figures for the fast mode with the above RandomX configuration (~1 GiB of memory is required): H/s = hashes per second == CPUs: Intel Core i3-3220 - 1 thread 700 H/s - 3 threads 1400 H/s Intel Xeon (dual core VPS, Sandy Bridge, unknown model) - 1 thread 2000 H/s - 2 threads 4000 H/s Intel Core i5-2500K (stock) - 1 thread 2200 H/s - 4 threads 8200 H/s Intel Core i7-8550U (laptop) - 1 thread 2700 H/s - 8 threads 10000 H/s Intel Core i7-9850H (laptop) - 1 thread 3100 H/s - 12 threads 16000 H/s AMD Ryzen 1700 @ 3300MHz - 1 thread 2300 H/s - 16 threads 23800 H/s AMD Ryzen 3700X @ 3300MHz - 1 thread 2500 H/s - 16 threads 27500 H/s AMD Epyc 7702P - 1 thread 2100 H/s - 128 threads 139000 H/s == GPUs: NVIDIA GeForce GTX 1660 Ti (credits to SChernykh, see [REF_RANDOMX_CUDA]) - 3072 intensity 2600 H/s According to the above results, the time to verify a single hash is around 400-500 μs. A mid-range GPU has a similar performance as a single CPU core. Most CPUs made since 2011 have similar per-core performance except of low-end CPUs without hardware AES support. References: [REF_BIRTHDAY]: https://en.wikipedia.org/wiki/Birthday_attack#Mathematics [REF_SUS]: https://en.wikipedia.org/wiki/Stochastic_universal_sampling [REF_CUCKOO]: https://github.com/tromp/cuckoo [REF_RANDOMX_PROGRAMS]: https://github.com/tevador/RandomX/blob/master/doc/design.md#12-the-easy-pr… [REF_RANDOMX_TMTO]: https://github.com/tevador/RandomX/issues/65 [REF_RANDOMX_CUDA]: https://github.com/SChernykh/RandomX_CUDA

7 21

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

02 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

Implementing an embeddable C++ Tor client, advice requested
by The Paranoia Project 26 Jun '20

26 Jun '20

Hello everyone, I'm a long time user of Tor, first time poster here. Over the last few months, I have been working on a light weight C++ client only implementation of the Tor protocol, intended to be used as an embedded library in other applications. It is now at the stage where it can complete bootstrapping, build circuits, as well as connect to services / host hidden services (v3). I have been building this primarily off the spec documents (which have generally been extremely helpful), and well as the assistance of stepping through the official Tor implementation when needed for troubleshooting and to confirm specifics. Before I release this to the wider world, I'd like to confirm a few points that may not be explicitly stated in the specs. 1. In general, what are the things to look out for when implementing the Tor protocol beyond "making it work" and validating all data (signatures, timestamps, etc)? One thing I'm concerned about is the risk of fingerprinting where the spec does not completely specify behaviour, e.g. the order in which link specifiers are passed in an extend cell, exact criteria for when circuits are explicitly destroyed etc. (I'm very excited to see the proposals around CBOR on this point which would help greatly with knowing that a canonical data representation was used). 2. When it comes to bootstrapping, the official implementation appears to favour accessing directories via plaintext HTTP rather than connecting on the OR port and using create fast / begin dir. What is the motivation for using the plaintext option (and for that matter, having a plaintext http service open at all)?. While the OR will learn just as much about the client regardless, it seems like the default plaintext access to directory information unnecessarily gives away details of how clients engage with the Tor network to third parties. 3. When using bridges and in particular pluggable transports, how is the client intended to safely bootstrap in the cold start case where it does not know up front which bridge/relay it will be connected to (e.g. when using Snowflake)? The RSA identity can be accepted in blind faith based on the Tor handshake, and it's then possible to get the full details with create fast / begin dir, but how does a client know that it has been connected to a bridge that is "blessed" by the Tor network rather than a MITM actor? 4. Finally, if anyone reading has been involved with or close to the development of other unofficial Tor implementations, what are the lessons learned on this front? I'm aware of among others Orchid (updated last in 2016), node-Tor (does not implement ECC) and torpy (does not implement hidden services v3). What makes these fail / stall? Many thanks, P

2 2

Re: [tor-dev] Reproducing #33598 "chutney does not fail on some SOCKS errors"
by c 18 Jun '20

18 Jun '20

On Mon, 15 Jun 2020 14:06:37 -0400 Nick Mathewson <nickm(a)freehaven.net> wrote: > This seems plausible, though 0.0.0.0:x will just be the local computer as well. > > Maybe you could try routing to a known-unassigned address, or one that > Tor simply won't support, like the one from RFC 6666? From my understanding 0.0.0.0/32 is a special address that is not supposed to be routable. But `ping 0.0.0.0` does seem to redirect it to 127.0.0.1 for whatever reason; it might be some odd Linux-specific behaviour. I'll check for other known-unroutable addresses and try one of them. > [...] > > It's in Traffic.py, Source.handle_connect(), in this line: Thanks, I'll take a look at it. Caitlin

1 0

GSOC: Social Media Sharing for OONI
by Krona Emmanuel 18 Jun '20

18 Jun '20

Hi, I'm Krona Emmanuel, working on implementing better Social Media Sharing within OONI Explorer [1]. OONI Explorer allows users to view measurements and visualizations of network interference around the world. This project is aimed at improving OONI Explorer in the following areas: 1. SEO 2. Social media link sharing. 3. Sharing charts So far, I have been working on making prototypes for charts and social media link sharing. I recently finished a PR which improved the meta tags of measurement pages to better indicate the results of the measurement [3]. You can see more details about the project on the GSOC project page [2]. I would be very happy to get any suggestions etc about the project. I'll also send in more updates about the project as I implement features. Regards, Krona Emmanuel 1. https://explorer.ooni.org/ 2. https://summerofcode.withgoogle.com/projects/#4714428131442688 3. https://github.com/ooni/explorer/pull/470

1 0

Onion Client Auth on v3 descriptor via Control port
by Miguel Jacq 17 Jun '20

17 Jun '20

Hi, I'm one of the OnionShare developers, looking at what can be done to support Client Auth with v3 onions. OnionShare depends on Stem for all its interaction setting up ephemeral onions, so we need Stem to support that fierst. So I have been working on adding support for ONION_CLIENT_AUTH_ADD to Stem. I actually have it working as far as getting a 250 OK back from the controller! Nice. But I'm puzzled, because despite successfully adding the client auth, I can access my onion service *without* auth in Tor Browser. Here is a link to a PoC script. Note that it doesn't do the ONION_CLIENT_AUTH_ADD via Stem here yet. I have that working locally, but this issue isn't with my Stem implementation I don't think... https://gist.github.com/mig5/2e95a3fbe157e1f78764f7a718bf93b9 Here's the output if I run the script with python3 create-v3-service-and-keys.py user@onionshare:~$ python3 create-v3-service-and-keys.py http service: http://127.0.0.1:8080/ starting onion service with: key_type='NEW', key_content='ED25519-V3' http://4sa6jhqf2atg7edi2nzqun4o5kyughmwvjyrb7sfxe7d6ypqyh7f6nqd.onion/ private base64: wkiyM1bQN2dI43PvobZnbD87cNBl/KFyrc8baZzJOv0= public base32: WJJTONEA5SRZKVHHAYY2EHIF5LNF3526RCLYSC7ZZRCPVPIFA6PA==== private base32: YJELEM2W2A3WOSHDOPX2DNTHNQ7TW4GQMX6KC4VNZ4NWTHGJHL6Q==== Now, if in another terminal I telnet to the control port and manually add the onion auth, I get a 250, I can view the auth etc: user@onionshare:~/git/stem$ sudo -u debian-tor telnet 127.0.0.1 9051 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. Authenticate "" 250 OK ONION_CLIENT_AUTH_ADD 4sa6jhqf2atg7edi2nzqun4o5kyughmwvjyrb7sfxe7d6ypqyh7f6nqd x25519:wkiyM1bQN2dI43PvobZnbD87cNBl/KFyrc8baZzJOv0= 250 OK ONION_CLIENT_AUTH_VIEW 4sa6jhqf2atg7edi2nzqun4o5kyughmwvjyrb7sfxe7d6ypqyh7f6nqd 250-ONION_CLIENT_AUTH_VIEW 4sa6jhqf2atg7edi2nzqun4o5kyughmwvjyrb7sfxe7d6ypqyh7f6nqd 250-CLIENT 4sa6jhqf2atg7edi2nzqun4o5kyughmwvjyrb7sfxe7d6ypqyh7f6nqd x25519:wkiyM1bQN2dI43PvobZnbD87cNBl/KFyrc8baZzJOv0= 250 OK So that all looks good. But what is weird, is if I go to http://gmdo3idszymnvfbuf2fm6miepearldgwbo7qfc4lsrw2kact2ka77kqd.onion/ , I see my 'hello world', I never had to add any client auth to Tor Browser. What am I doing wrong? How do I make the onion auth actually be 'required' since I succeeded at adding it? I was under the impression that as soon as I ran ONION_CLIENT_AUTH_ADD and got a success, from that point on, client auth would be *needed*. Maybe it's a problem with how I'm generating the keys? I had a bit of trouble figuring out how to send the base64 encoded private key. Even so, it accepts the private key, and yet it allows access without auth, which surprised me... It's probably really obvious but I've been working on this a while so I'm tired :) Time to embarass myself on a public mailing list.. Thanks in advance! Mig

2 3

Onion Service v2 Deprecation Timeline
by David Goulet 16 Jun '20

16 Jun '20

Greetings everyone! I will try to make this quick. Deprecation of v2 has already been discussed on this list [0] and so this is not about re-creating this discussion but rather giving you the Tor Project timeline for v2 deprecation. To very quickly summarize why we are deprecating, in one word: Safety. Onion service v2 uses RSA1024 and 80 bit SHA1 (truncated) addresses [1]. It also still uses the TAP [2] handshake which has been entirely removed from Tor for many years now _except_ v2 services. Its simplistic directory system exposes it to a variety of enumeration and location-prediction attacks that give HSDir relays too much power to enumerate or even block v2 services. Finally, v2 services are not being developed nor maintained anymore. Only the most severe security issues are being addressed. That being said, the deprecation timeline is now quite simple because v3 has reached a good maturity level: * v3 has been the default since Tor 0.3.5.1-alpha. * v3 is feature parity with v2. * v3 now has Onion Balance support [3] * Entire network supports v3 since the End-of-Life of 0.2.9.x series earlier this year. The deprecation to obsolescence timeline: 1) September 15th, 2020 0.4.4.x: Tor will start warning onion service operators and clients that v2 is deprecated and will be obsolete in version 0.4.6 2) July 15th, 2021 0.4.6.x: Tor will no longer support v2 and will be removed from the code base. 3) October 15th, 2021 We will release new stable versions for all supported series that will disable v2. This effectively means that from _today_ (June 11th 2020), the Internet has around 15 months to migrate from v2 to v3 once and for all. We plan to publish a blog post in the coming days/weeks about this deprecation, in order to inform as many users as possible. It will include the reasons why, how to migrate and the timeline. We'll probably run into some difficulties here; no matter how prepared we think we are, we find that there are always more surprises. Nonetheless, we'll do our best to fix problems as they come up, and try to make this process as smooth as possible. Good Luck! The tor maintainers. [0] https://lists.torproject.org/pipermail/tor-dev/2018-April/013097.html [1] https://shattered.io/ [2] https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1084 [3] https://blog.torproject.org/cooking-onions-reclaiming-onionbalance -- 262Gy/4o+HGG/7ELoDp1drRojN33l7AZaBoRHN6mjXY=

5 6

Reproducing #33598 "chutney does not fail on some SOCKS errors"
by c 15 Jun '20

15 Jun '20

I asked on ticket https://bugs.torproject.org/33598 how to reliably reproduce SOCKS errors so that it would be easier to determine when the underlying issue is properly fixed, rather than running into the possibility of race conditions (as the current workaround depends on "waiting long enough" for connections to succeed most of the time). In #tor-dev I believe it was arma who pointed me toward the right direction, but that still leaves me with unresolved questions. It was suggested that I can attempt SOCKS connections to an invalid host/port versus a valid one, in order to have a reliable failure case for testing. But in the context of Chutney I believe we only want to attempt local connections, correct? So either attempting connection to 127.0.0.0/8 on a known-closed port, or perhaps more simply 0.0.0.0 on any port, would be a reliable case to use, correct? Also from my comment on #33598: > Assuming workaround is at Traffic.py:441? I see the timeout was > adjusted in 95ce144c which has more changes than just that line. and > will decreasing the timeout back to 0.2 be enough to encourage > failure? Last question: I looked for a bit, but where is Chutney actually initiating SOCKS connections to Tor during tests? I still find it hard to follow especially when I am going in blind for much of this. Caitlin

2 1